On Wed, 1 Apr 2009 02:23:41 +0400 If you are doing this you will never get sky2 vpd pci access, but that is not a big loss. I worry that other thing could break if devices are getting initialized before sysfs. Drivers that create sysfs entries (like the 10G drivers) could also break? But this is okay as a provisional step, the sysfs startup order needs to be fixed. Acked-by: Stephen Hemminger <shemminger@vyatta.com> --

From: Kyle McMartin <kyle@mcmartin.ca> I would prefer the RDS folks simply fix this properly. --

From: Kyle McMartin <kyle@redhat.com> set_64bit doesn't exist anywhere but x86 right now, so either BITS_PER_LONG needs to be 64, or we need to be on x86, in order to build this module. Signed-off-by: Kyle McMartin <kyle@redhat.com> --- diff --git a/net/rds/Kconfig b/net/rds/Kconfig index 796773b..84df275 100644 --- a/net/rds/Kconfig +++ b/net/rds/Kconfig @@ -1,7 +1,7 @@ config RDS tristate "Reliable Datagram Sockets (RDS) (EXPERIMENTAL)" - depends on INET && INFINIBAND_IPOIB && ...

From: Kyle McMartin <kyle@redhat.com> Didn't see this in your patch queue, fixes build on Fedora, though we'll probably end up turning on CONFIG_COMPAT_NET_DEV_OPS for now anyway. Signed-off-by: Kyle McMartin <kyle@redhat.com> --- diff --git a/drivers/staging/at76_usb/at76_usb.c b/drivers/staging/at76_usb/at76_usb.c index c8e4d31..59071e6 100644 --- a/drivers/staging/at76_usb/at76_usb.c +++ b/drivers/staging/at76_usb/at76_usb.c @@ -5259,6 +5259,18 @@ static int at76_alloc_urbs(struct ...

From: Ben Hutchings <bhutchings@solarflare.com> Applied, thanks. --

The driver kaweth yields a -EBUSY error when starting, and a -ETIME error when shutting down. These errors are avoided, and the RX status is further checked for other potential errors. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> --- Jeff, As the listed authors of this driver have not touched it in several years, I have taken the liberty of sending it to you as networking drivers maintainer. I hope this is OK. Larry --- Index: ...

From: Oliver Neukum <oliver@neukum.org> Please be specific, what is this "it" you are referring to? Larry's patch modifies the locking many functions, and you didn't quote the kernel locking error message if that provides the context of your comment. --

Here you enable interrupts. Are you sure ndo_start_xmit is never called with interrupts disabled? Regards Oliver --

From: Oliver Neukum <oliver@neukum.org> It must never be invoked that way, this would break so many drivers. On the other hand, all of these driver paths never execute in a real hardware interrupt context, the deepest it gets into is software interrupts. So spin_*lock*_bh() might be more appropriate. --

On an SMP system, the following message is printed. The patch below gets fixes the problem. ================================= [ INFO: inconsistent lock state ] 2.6.29-Linus-05093-gc31f403 #57 --------------------------------- inconsistent {hardirq-on-W} -> {in-hardirq-W} usage. bash/4105 [HC1[1]:SC0[0]:HE0:SE1] takes: (&kaweth->device_lock){+...}, at: [<ffffffffa01aa286>] kaweth_usb_receive+0x77/0x1af [kaw eth] {hardirq-on-W} state was registered at: [<ffffffff80260503>] ...

We need to get hotswap events in environments which cannot use existing facilities (e.g. inotify). So we add a notifier-chain to allow client callbacks whenever an interface is {un}registered. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- include/linux/vbus.h | 15 +++++++++++++ kernel/vbus/core.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++ kernel/vbus/vbus.h | 1 + 3 files changed, 75 insertions(+), 0 deletions(-) diff --git a/include/linux/vbus.h ...

Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- drivers/vbus/devices/venet-tap.c | 236 +++++++++++++++++++++++++++++++++++++- 1 files changed, 229 insertions(+), 7 deletions(-) diff --git a/drivers/vbus/devices/venet-tap.c b/drivers/vbus/devices/venet-tap.c index ccce58e..0ccb7ed 100644 --- a/drivers/vbus/devices/venet-tap.c +++ b/drivers/vbus/devices/venet-tap.c @@ -80,6 +80,13 @@ enum { TX_IOQ_CONGESTED, }; +struct venettap; + +struct venettap_rx_ops { + int ...

See Documentation/vbus.txt for details Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- Documentation/vbus.txt | 386 +++++++++++++++++++++++++++++ arch/x86/Kconfig | 2 fs/proc/base.c | 96 +++++++ include/linux/sched.h | 4 include/linux/vbus.h | 147 +++++++++++ include/linux/vbus_device.h | 416 ++++++++++++++++++++++++++++++++ kernel/Makefile | 1 kernel/exit.c | 2 kernel/fork.c ...

Yeah, good idea. What is the official way to do this these days? Are Totally agreed. If you look, most of the ABI has a type of "NEGCAP" (negotiate capabilities) feature. The version number is a contingency plan in case I still have to break it for whatever reason. I will always opt for the feature bits over bumping the version when its This is still somewhat of a immature part of the design. Its supposed to be used so that by default, its a panic. But on the host side, we can do ...

These points are all valid, and I really struggled with this particular part of the design. The entire vbus design only requires one IRQ for the entire guest, so its conceivable that I could present a simple "dummy" PCI device with some "VBUS" type PCI-ID, just to piggy back on the IRQ routing logic. Then userspace could simply pass the IRQ routing info down to the kernel with an ioctl, or something similar. Ultimately I wasn't sure whether I wanted all that goo just to get an IRQ ...

Its needed for the kvm-connector patches later in the series, so it was included intentionally. On that topic, I probably should have had a TOC of some kind. Hmm..let me hack one together now: Patch 1: Stand-alone "shared-memory signal" construct, used by various components in vbus/venet Patches 2-5: Basic vbus infrastructure Patches 6-7: IOQ construct, similar to virtio-ring. Used to overlay ring-like behavior over the shm interface in vbus Patches 8-12: virtual-ethernet front and ...

This patch adds support for guest access to a VBUS assigned to the same context as the VM. It utilizes a IOQ+IRQ to move events from host->guest, and provides a hypercall interface to move events guest->host. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- arch/x86/include/asm/kvm_para.h | 1 arch/x86/kvm/Kconfig | 9 arch/x86/kvm/Makefile | 3 arch/x86/kvm/x86.c | 6 arch/x86/kvm/x86.h | 12 include/linux/kvm.h ...

Hmm..you know I hadnt really thought of it that way, but you have a point. To clarify, my design actually uses one IRQ per "eventq", where we can have an arbitrary number of eventq's defined (note: today I only define one eventq, however). An eventq is actually a shm-ring construct where I can pass events up to the host like "device added" or "ring X signaled". Each individual device based virtio-ring would then aggregates "signal" events onto this eventq mechanism to actually inject events to ...

We expect to have various types of connection-clients (e.g. userspace, kvm, etc), each of which is likely to have common access patterns and marshalling duties. Therefore we create a "client" API to simplify client development by helping with mundane tasks such as handle-2-pointer translation, etc. Special thanks to Pat Mullaney for suggesting the optimization to pass a cookie object down during DEVICESHM operations to save lookup overhead on the event channel. Signed-off-by: Gregory ...

Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- drivers/net/Kconfig | 13 + drivers/net/Makefile | 1 drivers/net/vbus-enet.c | 706 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 720 insertions(+), 0 deletions(-) create mode 100644 drivers/net/vbus-enet.c diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 62d732a..ac9dabd 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -3099,4 +3099,17 @@ config VIRTIO_NET This is ...

It will be common to map an IOQ over the VBUS shared-memory interfaces, so lets generalize their setup so we can reuse the pattern. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- include/linux/vbus_device.h | 7 +++ include/linux/vbus_driver.h | 7 +++ kernel/vbus/Kconfig | 2 + kernel/vbus/Makefile | 1 kernel/vbus/proxy.c | 64 +++++++++++++++++++++++++++++++ kernel/vbus/shm-ioq.c | 89 +++++++++++++++++++++++++++++++++++++++++++ 6 ...

Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- drivers/net/vbus-enet.c | 249 +++++++++++++++++++++++++++++++++++++++++++++-- include/linux/venet.h | 39 +++++++ 2 files changed, 275 insertions(+), 13 deletions(-) diff --git a/drivers/net/vbus-enet.c b/drivers/net/vbus-enet.c index e698b3f..8e96c9c 100644 --- a/drivers/net/vbus-enet.c +++ b/drivers/net/vbus-enet.c @@ -42,6 +42,8 @@ static int rx_ringlen = 256; module_param(rx_ringlen, int, 0444); static int tx_ringlen = ...

Best would be not to detect it; it's tying global events into a device. Instead, have a reset command for your device and have the driver issue it on load and unload. btw, reset itself would be better controlled from userspace; qemu knows about resets and can reset vbus devices directly instead of relying on kvm to reset them. This decouples the two code bases a bit. This is what virtio does. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow ...

On Tue, 31 Mar 2009 14:43:34 -0400 Please consider adding basic set of ethtool_ops to allow controlling offload, etc. --

How do you handle the case of a guest calling kexec to load a new kernel? Or is that not important for your use case? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --

Yes, good point. This is doable within the existing infrastructure, but it would have to be declared in each devices ABI definition. I could make it more formal and add it to the list of low-level bus-verbs, like In a way, this is what I have done (note to self: post the userspace patches) The detection is done by userspace, and it invokes an ioctl. The kernel based devices then react if they are interested. In my case, vbus registers for reset-notification, and it acts as if the guest ...

A major disadvantage of dynirq is that it will only work on guests which have been ported to it. So this will only be useful on newer Linux, and will likely never work with Windows guests. Why is having an emulated PCI device so bad? We found that it has several advantages: - works with all guests - supports hotplug/hotunplug, udev, sysfs, module autoloading, ... - supported in all OSes - someone else maintains it See also the kvm irq routing work, merged into 2.6.30, which does ...

The question came up when profiling Quagga... a performance issue occurs because it's iterating over a linked list of interface structures... and this person is using 2000 interfaces for ADSL PPPoE server. It's an interesting use case. There are 2 options to make the interface lookup in quagga scale: array or hash. My first thought was array, but it seems that ifindex can get sparse, that is, the largest ifindex can be much bigger (eg 408589) the number of max number of interfaces. So ...

Please use a hash...I'm sure someone will have a use-case with more than 64k interfaces sometime soon. Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com --

Now that the driver is exclusively an of_platform driver we no longer use the structs and #defines in fsl_devices.h Signed-off-by: Kumar Gala <galak@kernel.crashing.org> --- drivers/net/ucc_geth.c | 1 - drivers/net/ucc_geth.h | 1 - drivers/net/ucc_geth_ethtool.c | 1 - 3 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c index 933fcfb..a124615 100644 --- a/drivers/net/ucc_geth.c +++ ...

This is a fix to get cs89x0 network driver working on i.MX31ADS Signed-off-by: Alan Carvalho de Assis <acassis@gmail.com> --- drivers/net/cs89x0.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c index ff64976..8ccc8f7 100644 --- a/drivers/net/cs89x0.c +++ b/drivers/net/cs89x0.c @@ -190,6 +190,7 @@ static unsigned int cs8900_irq_map[] = {IRQ_IXDP2X01_CS8900, 0, 0, 0}; static unsigned int netcard_portlist[] __used ...

On Tue, 31 Mar 2009 12:44:15 +0200 What about change_mtu? Don't you want: .ndo_change_mtu = eth_change_mtu, --

Fix fec_mpc52xx driver to use net_device_ops and to be careful not to dereference phy_device if a phy has not yet been connected. Signed-off-by: Henk Stegeman <henk.stegeman@gmail.com> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c index cd8e98b..ca76b95 100644 --- a/drivers/net/fec_mpc52xx.c +++ b/drivers/net/fec_mpc52xx.c @@ -847,24 +847,40 @@ static void mpc52xx_fec_get_drvinfo(struct net_device *dev, static int mpc52xx_fec_get_settings(struct net_device *dev, ...

From: Grant Likely <grant.likely@secretlab.ca> This patch simplifies the driver by making use of more common code. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- drivers/net/fsl_pq_mdio.c | 53 +++------------------------------------------ 1 files changed, 4 insertions(+), 49 deletions(-) diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c index b3079a5..83a98f4 100644 --- a/drivers/net/fsl_pq_mdio.c +++ b/drivers/net/fsl_pq_mdio.c @@ -34,6 +34,7 @@ ...

From: Grant Likely <grant.likely@secretlab.ca> of_parse_phandle() is a helper function to read and parse a phandle property and return a pointer to the resulting device_node. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> CC: Michael Ellerman <michael@ellerman.id.au> --- drivers/of/base.c | 24 ++++++++++++++++++++++++ include/linux/of.h | 3 +++ 2 files changed, 27 insertions(+), 0 deletions(-) diff --git a/drivers/of/base.c b/drivers/of/base.c index cd17092..104b8c0 ...

From: Grant Likely <grant.likely@secretlab.ca> This patch simplifies the driver by making use of more common code. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- drivers/net/fs_enet/fs_enet-main.c | 69 ++++++------------------------------ drivers/net/fs_enet/mii-bitbang.c | 29 +-------------- drivers/net/fs_enet/mii-fec.c | 26 +------------- include/linux/fs_enet_pd.h | 6 +-- 4 files changed, 16 insertions(+), 114 deletions(-) diff --git ...

From: Grant Likely <grant.likely@secretlab.ca> This patch adds support for the Xilinx ll_temac 10/100/1000 Ethernet device. The ll_temac ipcore is typically used on Xilinx Virtex and Spartan designs attached to either a PowerPC 4xx or Microblaze processor. At the present moment, this driver only works with Virtex5 PowerPC designs because it assumes DCR is used to access the DMA registers. However, the low level access to DMA registers is abstracted and it should be easy to adapt for the ...

From: Grant Likely <grant.likely@secretlab.ca> The FEC Ethernet device isn't always attached to a phy. Be careful not to dereference phy_device if it is NULL. Reported-by: Henk Stegeman <henk.stegeman@gmail.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- drivers/net/fec_mpc52xx.c | 22 ++++++++++++---------- 1 files changed, 12 insertions(+), 10 deletions(-) diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c index 75d0569..e10eb2c 100644 --- ...

It's been out there on the list since before the merge window, getting tested by more than just me. This is not series which has simply dropped out of thin air. I've been working hard to address issues reported by others (Thanks Olof!) and to keep it building and applying Since when has sitting in a -next tree been a requirement for merging when the series has been kept up to date and tested? I purposefully kept it out of -next to ensure that when it was applied for real to a -next tree it ...

From: Grant Likely <grant.likely@secretlab.ca> This patch simplifies the driver by making use of more common code. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- drivers/net/gianfar.c | 103 ++++++++++++++++++------------------------------- drivers/net/gianfar.h | 3 + 2 files changed, 40 insertions(+), 66 deletions(-) diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 65f5587..c22eba9 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ ...

From: Grant Likely <grant.likely@secretlab.ca> This patch modifies the bitbanged MDIO driver in the ep8248e platform code to use the common of_mdio infrastructure. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- arch/powerpc/platforms/82xx/ep8248e.c | 9 +++------ 1 files changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/platforms/82xx/ep8248e.c b/arch/powerpc/platforms/82xx/ep8248e.c index 0eb6d7f..51fcae4 100644 --- ...

From: Grant Likely <grant.likely@secretlab.ca> This patch makes changes in preparation for supporting open firmware device tree descriptions of MDIO busses. Changes include: - Cleanup handling of phy_map[] entries; they are already NULLed when registering and so don't need to be re-cleared, and it is good practice to clear them out when unregistering. - Split phy_device registration out into a new function so that the OF helpers can do two stage registration (separate allocation and ...

From: Wei Yongjun <yjwei@cn.fujitsu.com> Applied, thanks. --

From: Grant Likely <grant.likely@secretlab.ca> The driver triggers a BUG_ON() when allocating DMA buffers if the arch/powerpc dma_ops from the of_platform device are not copied into net_device structure. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- Becky, does this look better to you? g. drivers/net/fec_mpc52xx.c | 19 ++++++++++++------- 1 files changed, 12 insertions(+), 7 deletions(-) diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c index ...

Reviewed-by: Becky Bruce <beckyb@kernel.crashing.org> I think this is OK now, and Kumar agrees.... Thanks! --

> - if (0 <= ret && (unsigned) ret < nr_pages) { > + if (ret > 0 && (unsigned) ret < nr_pages) { This is not an equivalent transformation -- the original code is true if ret == 0, while the new code is false. Also it seems you don't need the unsigned cast here, since the clause before just checked that ret is positive? - R. --

From: Andrew Grover <andy.grover@gmail.com> Andy, also please resubmit only the real honest-to-goodness bug fixes in this patch series. I don't want to see cleanups, or optimizations like the transformation over to using get_user_pages_fast(). You could have sent that kind of stuff to me weeks ago. Thanks. --

From: Rami Rosen <ramirose@gmail.com> Applied. --

Doc: Fix spelling in RCU/rculist_nulls.txt. Trival spelling fixes in RCU/rculist_nulls.txt. Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> --- Documentation/RCU/rculist_nulls.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt index 239f542..6389dec 100644 --- a/Documentation/RCU/rculist_nulls.txt +++ ...

Hmm... still "reviewing", and maybe it's only me, but can't apply... (v1 works OK.) --

Do you get something with sysrq-t ? Regards Oliver --

No. The rest of the system was still functioning; however, the driver needed to be unloaded and reloaded before continuing. There were no log entries until the driver was unloaded. Larry --

This sounds like kaweth_tx_timeout() should have been called. Did you enable enough logging to see dev_warn(&net->dev, "%s: Tx timed out. Resetting.\n", net->name); Regards Oliver --

The machine hanged again this night and I took two pictures: http://www.mypicx.com/uploadimg/1055813374_03302009_2.jpg http://www.mypicx.com/uploadimg/1543678904_03302009_1.jpg But this time there was no tcp related warning in the logs. I then pulled the lateset git changes, rebuild, rebooted and setup the workload again. The machine was still up and running in the morning (~4 hours uptime). So it may well be that the issue was fixed with the latest changes. If it ever occurs again I will ...

It happend again. In this case it took ~10 minutes from the warning to the final crash. I'm pretty sure there must be some kind of relation between the two. How else could one explain that the machine crashes just minutes after _each_ instance of that WARNING? (Unfortunately I was in X again, because I thought this problem was solved) ------------[ cut here ]------------ WARNING: at net/ipv4/tcp_input.c:2927 tcp_ack+0xd5b/0x19a6() Hardware name: To Be Filled By O.E.M. Pid: 0, comm: ...

I noticed that in gianfar these memory access is not protected by "volatile". Can this be the reason why the compiler did some unwanted optimization? - Leo --

On Tue, Mar 31, 2009 at 5:07 PM, Joakim Tjernlund 1 and 3 are the same. All of them use cacheable memory as we have a hardware coherency module to take care of the cache coherency problem. However it might be better to use dma_alloc_coherent() for the code to be more readible. Thanks. - Leo --

My idea as a user, having configured some servers: with kernel point of view, there should be no preference. If users the problem here is the monotonic increasing order. I never rename ethX back to the monotonic ethX numbering. IMHO, renaming eth0 to eth1 sounds redundant. I rename ethx to lan, wan, wlan, remote, lan0, lan1, ... --

Usually lock internal locks still get lockdep coverage. Let see if we can find a way for this to be true even here. I suspect the below to There you acquire the table while holding the spinlock, generating: sysctl_lock -> table_lock, however you then release the sysctl_lock and re-acquire it, generating table_lock -> sysctl_lock. Indeed, just checking. --

That is an artifact of sysctl_lock being used to implement table_lock as best as I can tell. The case you point out I could probably play with where I claim the lock is acquired and make it work. __sysctl_head_next on the read side is trickier. We come in with table_lock held for read. We grab sysctl_lock. We release table_lock (aka the reference count is decremented) We grab table_lock on the next table (aka the reference count is incremented) We release sysctl_lock If we generate ...

Ah, I was under the impression they weren't quite finished yet, apparently I was mistaken. Eric, didn't you need recursive locks fixed and such? Let me have a look at them. --

You can add: Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> James --

I should have reported that these were taken in. I will report it from the next time. Best regards, Nobuhiro --

So far so good. In the last week my watchdog (cannot reach the default gateway) triggered once, but since there were no "PCI Memory Mapped IO Disabled!!!!" messages in the logfile I assume that was a real network problem. Since the box ran fine for months initially and the first two occurances of this issue were two weeks apart I cannot say for sure, but it definitely feels better than the "once in two days" in the end. Bernhard --

Agreed - once SR-IOV support ships in Linux and Xen, using X3100 Multi-function mode becomes optional and the device can/will be used in SR IOV mode. In other hypervisors, transition to SR IOV will take longer time and Multi-function mode will be used for a while. Enabling SR IOV mode should be transparent to vxge driver - the driver has no SR IOV specific code, and we plan to use the same netdev driver in both Linux and DomU Linux guest. Also (an optional) Xen Dom0 privileged vxge driver ...

The patch checks out. I tested suspend/resume (including WOL) and kexec. There is only a small issue with warning on compile when CONFIG_PM is disabled: diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c index 13fe162..0a4f8f4 100644 --- a/drivers/net/igb/igb_main.c +++ b/drivers/net/igb/igb_main.c @@ -135,8 +135,8 @@ static inline int igb_set_vf_rlpml(struct igb_adapter *, int, int); static int igb_set_vf_mac(struct igb_adapter *adapter, int, unsigned char *); static void ...

On Tue, Mar 31, 2009 at 12:14 PM, Tantilov, Emil S Rafael - Based on Emil's testing, I will modify the patch with Emil's suggestion and push to Dave, ok? -- Cheers, Jeff --

On Mon, 30 Mar 2009, Eric Dumazet wrote: > Jesper Dangaard Brouer a

warning, because on my machine, cpu0 is on physical id 0, core 0 cpu1 is on physical id 1, core 0 cpu2 is on physical id 0, core 1 cpu3 is on physical id 1, core 1 cpu3 is on physical id 0, core 2 cpu4 is on physical id 1, core 2 cpu5 is on physical id 0, core 3 cpu6 is on physical id 1, core 3 So -T 0,1 might not do what you think... $ netperf -T 0,1 -l 120 -H localhost TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : cpu ...