* Re: r8169 driver crashes in 2.6.32.43
From: Francois Romieu @ 2011-07-28 14:47 UTC (permalink / raw)
To: Kasper Dupont; +Cc: ivecera, hayeswang, gregkh, netdev
In-Reply-To: <20110728125437.GA24876@colin.search.kasperd.net>
Kasper Dupont <kasperd@cpvhh.24.jul.2011.kasperd.net> :
> On 28/07/11 14.45, Kasper Dupont wrote:
> > On 28/07/11 14.23, Francois Romieu wrote:
> > > You can replace them with plain printk(KERN_{INFO/ERR} "S: ...).
> >
> > Then it compiles, will let you know shortly how it works out.
>
> The last 24 lines before network stopped working:
[...]
> S: 000000c0
> FEmp
> S: 000000c0
> FEmp
> S: 00000040
> S: 000000c4
> S: 00000044
> S: 00000040
Can you revert the last patch and apply the one below ?
Network traffic capture at the remote end of the link would be welcome,
especially ethernet MAC control frames.
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 7d9c650..b79fa86 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -287,6 +287,7 @@ enum rtl_registers {
/* Unlimited maximum PCI burst. */
#define RX_DMA_BURST (7 << RXCFG_DMA_SHIFT)
+ TimerCount = 0x48,
RxMissed = 0x4c,
Cfg9346 = 0x50,
Config0 = 0x51,
@@ -395,6 +396,7 @@ enum rtl_register_content {
/* InterruptStatusBits */
SYSErr = 0x8000,
PCSTimeout = 0x4000,
+ RxFIFOEmpty = 0x0200, /* 816x something only ? */
SWInt = 0x0100,
TxDescUnavail = 0x0080,
RxFIFOOver = 0x0040,
@@ -5110,8 +5112,9 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
tp->cur_tx += frags + 1;
- wmb();
+ mmiowb();
+ RTL_W32(TimerCount, 12500);
RTL_W8(TxPoll, NPQ);
if (TX_BUFFS_AVAIL(tp) < MAX_SKB_FRAGS) {
@@ -5222,15 +5225,6 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
(TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) {
netif_wake_queue(dev);
}
- /*
- * 8168 hack: TxPoll requests are lost when the Tx packets are
- * too close. Let's kick an extra TxPoll request when a burst
- * of start_xmit activity is detected (if it is not detected,
- * it is slow enough). -- FR
- */
- smp_rmb();
- if (tp->cur_tx != dirty_tx)
- RTL_W8(TxPoll, NPQ);
}
}
@@ -5379,11 +5373,21 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
break;
}
+ if (unlikely(status & PCSTimeout)) {
+ printk(KERN_INFO "%08lx %08x %08x %08x %08x %08x\n",
+ jiffies, status, tp->cur_rx, tp->dirty_rx,
+ tp->cur_tx, tp->dirty_tx);
+ smp_rmb();
+ if (tp->cur_tx != tp->dirty_tx)
+ RTL_W8(TxPoll, NPQ);
+ }
+
if (unlikely(status & RxFIFOOver)) {
switch (tp->mac_version) {
+ int i;
+
/* Work around for rx fifo overflow */
case RTL_GIGA_MAC_VER_11:
- case RTL_GIGA_MAC_VER_22:
case RTL_GIGA_MAC_VER_26:
netif_stop_queue(dev);
rtl8169_tx_timeout(dev);
@@ -5399,6 +5403,21 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
case RTL_GIGA_MAC_VER_28:
case RTL_GIGA_MAC_VER_31:
/* Experimental science. Pktgen proof. */
+ case RTL_GIGA_MAC_VER_22:
+ printk(KERN_INFO "%08lx %08x %08x %08x %08x %08x\n",
+ jiffies, status,
+ tp->cur_rx, tp->dirty_rx,
+ tp->cur_tx, tp->dirty_tx);
+ for (i = 0; i < 4000000; i++) {
+ if (RTL_R16(IntrStatus) & RxFIFOEmpty) {
+ RTL_W16(IntrStatus, RxFIFOOver);
+ printk(KERN_INFO "FEmp %d\n", i);
+ break;
+ }
+ udelay(10);
+ }
+ if (i >= 4000000)
+ printk(KERN_ERR "no FEmp\n");
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_25:
if (status == RxFIFOOver)
^ permalink raw reply related
* Re: [RFC net-next PATCH 1/4] pci: Add flag indicating device has been assigned by KVM
From: Ian Campbell @ 2011-07-28 15:11 UTC (permalink / raw)
To: Greg Rose, Konrad Rzeszutek Wilk
Cc: netdev, davem, bhutchings, jeffrey.t.kirsher, Jesse Barnes,
linux-pci
In-Reply-To: <20110727221749.8435.19000.stgit@gitlad.jf.intel.com>
On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> Device drivers that create and destroy SR-IOV virtual functions via
> calls to pci_enable_sriov() and pci_disable_sriov can cause catastrophic
> failures if they attempt to destroy VFs while they are assigned to
> guest virtual machines. By adding a flag for use by the KVM module
> to indicate that a device is assigned a device driver can check that
> flag and avoid destroying VFs while they are assigned and avoid system
> failures.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> ---
>
> include/linux/pci.h | 2 ++
I added Jesse and linux-pci to CC.
> virt/kvm/assigned-dev.c | 2 ++
> virt/kvm/iommu.c | 4 ++++
> 3 files changed, 8 insertions(+), 0 deletions(-)
I suppose this would also be useful in Xen's pciback or any other system
which does passthrough? (Konrad CC'd for pciback)
Is there some common lower layer we could hook this in to? (does
iommu_attach/detach_device make sense?) Or shall we just add the flag
manipulations to pciback as well?
Ian.
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 2d29218..a297ca2 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -174,6 +174,8 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG = (__force pci_dev_flags_t) 1,
> /* Device configuration is irrevocably lost if disabled into D3 */
> PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
> + /* Provide indication device is assigned by KVM */
> + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> };
>
> enum pci_irq_reroute_variant {
> diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
> index 6cc4b97..f401de1 100644
> --- a/virt/kvm/assigned-dev.c
> +++ b/virt/kvm/assigned-dev.c
> @@ -205,6 +205,8 @@ static void kvm_free_assigned_device(struct kvm *kvm,
> else
> pci_restore_state(assigned_dev->dev);
>
> + assigned_dev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> +
> pci_release_regions(assigned_dev->dev);
> pci_disable_device(assigned_dev->dev);
> pci_dev_put(assigned_dev->dev);
> diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
> index 62a9caf..cffc530 100644
> --- a/virt/kvm/iommu.c
> +++ b/virt/kvm/iommu.c
> @@ -181,6 +181,8 @@ int kvm_assign_device(struct kvm *kvm,
> goto out_unmap;
> }
>
> + pdev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> +
> printk(KERN_DEBUG "assign device %x:%x:%x.%x\n",
> assigned_dev->host_segnr,
> assigned_dev->host_busnr,
> @@ -209,6 +211,8 @@ int kvm_deassign_device(struct kvm *kvm,
>
> iommu_detach_device(domain, &pdev->dev);
>
> + pdev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> +
> printk(KERN_DEBUG "deassign device %x:%x:%x.%x\n",
> assigned_dev->host_segnr,
> assigned_dev->host_busnr,
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ian Campbell
All progress is based upon a universal innate desire of every organism
to live beyond its income.
-- Samuel Butler, "Notebooks"
^ permalink raw reply
* Re: [PATCH 2/2] ASIX: Use only 11 bits of header for data size
From: Greg KH @ 2011-07-28 15:18 UTC (permalink / raw)
To: Marek Vasut; +Cc: David Miller, linux-kernel, netdev, linux-usb, gregkh
In-Reply-To: <201107280806.18813.marek.vasut@gmail.com>
On Thu, Jul 28, 2011 at 08:06:18AM +0200, Marek Vasut wrote:
> On Thursday, July 28, 2011 07:40:29 AM David Miller wrote:
> > From: Marek Vasut <marek.vasut@gmail.com>
> > Date: Wed, 27 Jul 2011 04:44:47 +0200
> >
> > > The AX88772B uses only 11 bits of the header for the actual size. The
> > > other bits
> > >
> > > are used for something else. This causes dmesg full of messages:
> > > asix_rx_fixup() Bad Header Length
> > >
> > > This patch trims the check to only 11 bits. I believe on older chips, the
> > > remaining 5 top bits are unused.
> > >
> > > Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> >
> > Applied.
>
> Hi, did you test it ?
>
> I left NOTEs outside the commit message:
>
> NOTE: If possible, can someone test/verify this patch with other ASIX chips ?
> NOTE2: If Ack-ed, Greg, can you get this into -stable?
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* Fw: [Bug 40132] New: kernel BUG at mm/slab.c:501, when in kfree from ipv4_frags_exit_net
From: Stephen Hemminger @ 2011-07-28 15:35 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Tue, 26 Jul 2011 13:49:14 GMT
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 40132] New: kernel BUG at mm/slab.c:501, when in kfree from ipv4_frags_exit_net
https://bugzilla.kernel.org/show_bug.cgi?id=40132
Summary: kernel BUG at mm/slab.c:501, when in kfree from
ipv4_frags_exit_net
Product: Networking
Version: 2.5
Kernel Version: 3.0.0-03370-gb6844e8
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: baryluk@smp.if.uj.edu.pl
Regression: No
Created an attachment (id=66702)
--> (https://bugzilla.kernel.org/attachment.cgi?id=66702)
Kernel config
Happens 16.3% of times. gcc 4.4.5. i386. Debian GNU/Linux stable (squeeze).
It is probably one of the most rearly tested cleanup routines in kernel. I
discovered it by incident because of the bug in kdevtmpfs initialization.
[ 9.802917] BUG: unable to handle kernel paging request at 61203a73
[ 9.803237] IP: [<c115ed37>] path_init+0xc7/0x3b0
[ 9.803584] *pdpt = 0000000000000000 *pde = 0000000000000000
[ 9.803940] Oops: 0000 [#1] PREEMPT SMP
[ 9.804223] Modules linked in:
[ 9.804434]
[ 9.804615] Pid: 13, comm: kdevtmpfs Not tainted 3.0.0-t43-03370-gb6844e8
#22 Bochs Bochs
[ 9.804980] EIP: 0060:[<c115ed37>] EFLAGS: 00000246 CPU: 0
[ 9.805223] EIP is at path_init+0xc7/0x3b0
[ 9.805402] EAX: ffffff9c EBX: c78e1e90 ECX: 00000050 EDX: 00001050
[ 9.805643] ESI: 61203a73 EDI: 61203a73 EBP: c78e1e20 ESP: c78e1df8
[ 9.805888] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 9.806119] Process kdevtmpfs (pid: 13, ti=c78e0000 task=c78de1a0
task.ti=c78e0000)
[ 9.806407] Stack:
[ 9.806528] c78e1e00 00000e44 00000000 c78e1e14 00000e44 c78e1e14 c109446d
c78e1e90
[ 9.806998] c78e1f44 61203a73 c78e1e68 c115ff21 c78e1e90 c78e1e58 c17a9da7
c78ba0e0
[ 9.807432] c78e1e48 00000006 00000050 c78de1a0 c78e1e58 c10985c1 c7d47d00
c1a787e0
[ 9.807882] Call Trace:
[ 9.808047] [<c109446d>] ? put_lock_stats+0xd/0x30
[ 9.808263] [<c115ff21>] path_lookupat+0x31/0x5d0
[ 9.808469] [<c17a9da7>] ? _raw_spin_unlock_irq+0x27/0x60
[ 9.808697] [<c10985c1>] ? trace_hardirqs_on_caller+0x61/0xa0
[ 9.808938] [<c11604ec>] do_path_lookup+0x2c/0xb0
[ 9.809150] [<c1160656>] kern_path_create+0x26/0xe0
[ 9.809360] [<c17a69aa>] ? schedule+0x3a/0x770
[ 9.809562] [<c1094482>] ? put_lock_stats+0x22/0x30
[ 9.809776] [<c1413531>] handle_create+0x31/0x100
[ 9.809985] [<c17a7462>] ? preempt_schedule+0x32/0x50
[ 9.810146] [<c17a9d74>] ? _raw_spin_unlock_irqrestore+0x74/0x80
[ 9.810146] [<c104749b>] ? complete+0x4b/0x60
[ 9.810146] [<c14139b5>] devtmpfsd+0xf5/0x150
[ 9.810146] [<c14138c0>] ? handle_remove+0x200/0x200
[ 9.810146] [<c107dac4>] kthread+0x74/0x80
[ 9.810146] [<c107da50>] ? __init_kthread_worker+0x60/0x60
[ 9.810146] [<c17b0e7a>] kernel_thread_helper+0x6/0x10
[ 9.810146] Code: f3 ff 8b 53 04 8b 42 04 a8 01 0f 85 b5 02 00 00 89 43 24
31 ff 89 f8 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d c3 c7 43 14 00 00 00 00
[ 9.810146] 3e 2f 0f 84 c8 00 00 00 83 f8 9c 74 5b 8d 55 f0 bf f7 ff ff
[ 9.810146] EIP: [<c115ed37>] path_init+0xc7/0x3b0 SS:ESP 0068:c78e1df8
[ 9.810146] CR2: 0000000061203a73
[ 9.815606] kobject: 'hpet' (c7b77220): kobject_add_internal: parent:
'drivers', set: 'drivers'
[ 9.816880] kobject: 'hpet' (c7b77220): kobject_uevent_env
[ 9.817122] kobject: 'hpet' (c7b77220): fill_kobj_path: path =
'/bus/acpi/drivers/hpet'
[ 9.818518] kobject: 'nvram' (c7b6dc08): kobject_add_internal: parent:
'misc', set: 'devices'
[ 9.819257] ---[ end trace b8a3675a10c16a9a ]---
[ 9.819558] kdevtmpfs used greatest stack depth: 6172 bytes left
[ 9.872251] kobject: 'rx-0' (c798c9a8): kobject_cleanup
[ 9.872471] kobject: 'rx-0' (c798c9a8): auto cleanup 'remove' event
[ 9.872705] kobject: 'rx-0' (c798c9a8): kobject_uevent_env
[ 9.872930] kobject: 'rx-0' (c798c9a8): fill_kobj_path: path =
'/devices/virtual/net/lo/queues/rx-0'
[ 9.874037] kobject: 'rx-0' (c798c9a8): auto cleanup kobject_del
[ 9.874359] kobject: 'rx-0' (c798c9a8): calling ktype release
[ 9.874608] kobject: 'rx-0': free name
[ 9.874795] kobject: 'tx-0' (c798b950): kobject_cleanup
[ 9.874996] kobject: 'tx-0' (c798b950): auto cleanup 'remove' event
[ 9.875227] kobject: 'tx-0' (c798b950): kobject_uevent_env
[ 9.875469] kobject: 'tx-0' (c798b950): fill_kobj_path: path =
'/devices/virtual/net/lo/queues/tx-0'
[ 9.876721] kobject: 'tx-0' (c798b950): auto cleanup kobject_del
[ 9.880057] kobject: 'tx-0' (c798b950): calling ktype release
[ 9.881695] kobject: 'tx-0': free name
[ 9.881878] kobject: 'queues' (c798b870): kobject_cleanup
[ 9.882082] kobject: 'queues' (c798b870): auto cleanup kobject_del
[ 9.882349] kobject: 'queues' (c798b870): calling ktype release
[ 9.882579] kobject: 'queues' (c798b870): kset_release
[ 9.882789] kobject: 'queues': free name
[ 9.884069] kobject: 'lo' (c7996acc): kobject_uevent_env
[ 9.884287] kobject: 'lo' (c7996acc): fill_kobj_path: path =
'/devices/virtual/net/lo'
[ 9.885368] kobject: 'net' (c798c960): kobject_cleanup
[ 9.885573] kobject: 'net' (c798c960): auto cleanup kobject_del
[ 9.885834] kobject: 'net' (c798c960): calling ktype release
[ 9.886061] kobject: 'net': free name
[ 9.892232] kobject: 'lo' (c7996acc): kobject_cleanup
[ 9.892552] kobject: 'lo' (c7996acc): calling ktype release
[ 9.892914] kobject: 'lo': free name
[ 9.893865] ------------[ cut here ]------------
[ 9.894234] WARNING: at fs/proc/generic.c:850
remove_proc_entry+0x26a/0x270()
[ 9.894548] Hardware name: Bochs
[ 9.894730] remove_proc_entry: removing non-empty directory 'net/rpc',
leaking at least 'nfs'
[ 9.895070] Modules linked in:
[ 9.895384] Pid: 14, comm: kworker/u:1 Tainted: G D
3.0.0-t43-03370-gb6844e8 #22
[ 9.895733] Call Trace:
[ 9.895943] [<c105bb52>] warn_slowpath_common+0x72/0xa0
[ 9.896205] [<c11ab88a>] ? remove_proc_entry+0x26a/0x270
[ 9.896450] [<c11ab88a>] ? remove_proc_entry+0x26a/0x270
[ 9.896705] [<c105bc23>] warn_slowpath_fmt+0x33/0x40
[ 9.896943] [<c11ab88a>] remove_proc_entry+0x26a/0x270
[ 9.897233] [<c1140265>] ? kfree+0xc5/0x280
[ 9.897457] [<c16fa2a7>] ? ip_map_cache_destroy+0x97/0xb0
[ 9.897708] [<c1098579>] ? trace_hardirqs_on_caller+0x19/0xa0
[ 9.897966] [<c109860b>] ? trace_hardirqs_on+0xb/0x10
[ 9.898206] [<c17a9cdc>] ? _raw_spin_unlock+0x2c/0x50
[ 9.898446] [<c17006cd>] ? sunrpc_destroy_cache_detail+0x6d/0xc0
[ 9.898719] [<c16fec48>] ? remove_cache_proc_entries+0x68/0xf0
[ 9.898993] [<c1704b54>] rpc_proc_exit+0x24/0x40
[ 9.899217] [<c16fe0a7>] sunrpc_exit_net+0x17/0x20
[ 9.899450] [<c159eaef>] ops_exit_list+0x2f/0x50
[ 9.899676] [<c159f369>] cleanup_net+0xd9/0x170
[ 9.899905] [<c10778d8>] process_one_work+0x1d8/0x4c0
[ 9.905162] [<c107785c>] ? process_one_work+0x15c/0x4c0
[ 9.905439] [<c159f290>] ? register_pernet_subsys+0x40/0x40
[ 9.905678] [<c1078b70>] worker_thread+0x140/0x3a0
[ 9.905886] [<c17a7462>] ? preempt_schedule+0x32/0x50
[ 9.906104] [<c1078a30>] ? manage_workers+0x110/0x110
[ 9.906317] [<c107dac4>] kthread+0x74/0x80
[ 9.906509] [<c107da50>] ? __init_kthread_worker+0x60/0x60
[ 9.906740] [<c17b0e7a>] kernel_thread_helper+0x6/0x10
[ 9.906981] ---[ end trace b8a3675a10c16a9b ]---
[ 9.907540] ------------[ cut here ]------------
[ 9.907738] kernel BUG at mm/slab.c:501!
[ 9.907909] invalid opcode: 0000 [#2] PREEMPT SMP
[ 9.908150] Modules linked in:
[ 9.908296]
[ 9.908385] Pid: 14, comm: kworker/u:1 Tainted: G D W
3.0.0-t43-03370-gb6844e8 #22 Bochs Bochs
[ 9.908755] EIP: 0060:[<c1140383>] EFLAGS: 00000046 CPU: 0
[ 9.908971] EIP is at kfree+0x1e3/0x280
[ 9.909136] EAX: 40000400 EBX: c7f31920 ECX: c11401df EDX: c87fd000
[ 9.909370] ESI: c1ac9b60 EDI: c15f5f39 EBP: c78edebc ESP: c78ede90
[ 9.909604] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 9.909813] Process kworker/u:1 (pid: 14, ti=c78ec000 task=c78ea1c0
task.ti=c78ec000)
[ 9.910117] Stack:
[ 9.910220] c7abdbc0 c7a234e0 c251b2c0 00000282 c780e800 00000286 c19fcd82
c1ac9b60
[ 9.910477] c251b2c0 c1ac9b60 c78edee8 c78edecc c15f5f39 c1ac9b40 c251b2c0
c78edee0
[ 9.910477] c159eaef c78edee8 c1ac9b40 c1ac3428 c78edf04 c159f369 c251b300
c251b300
[ 9.910477] Call Trace:
[ 9.910477] [<c15f5f39>] ipv4_frags_exit_net+0x29/0x50
[ 9.910477] [<c159eaef>] ops_exit_list+0x2f/0x50
[ 9.910477] [<c159f369>] cleanup_net+0xd9/0x170
[ 9.910477] [<c10778d8>] process_one_work+0x1d8/0x4c0
[ 9.910477] [<c107785c>] ? process_one_work+0x15c/0x4c0
[ 9.910477] [<c159f290>] ? register_pernet_subsys+0x40/0x40
[ 9.910477] [<c1078b70>] worker_thread+0x140/0x3a0
[ 9.910477] [<c17a7462>] ? preempt_schedule+0x32/0x50
[ 9.910477] [<c1078a30>] ? manage_workers+0x110/0x110
[ 9.910477] [<c107dac4>] kthread+0x74/0x80
[ 9.910477] [<c107da50>] ? __init_kthread_worker+0x60/0x60
[ 9.910477] [<c17b0e7a>] kernel_thread_helper+0x6/0x10
[ 9.910477] Code: e9 fa fe ff ff 8b 55 ec 89 f1 89 d8 83 c2 38 89 55 e4 c7
04 24 00 00 00 00 e8 da fc ff ff 89 f1 c1 e1 02 89 75 e0 89 4d dc eb 9f <0f> 0b
eb fe 8b 5b 0c e9 86 fe ff ff 8b 5b 0c e9 6e fe ff ff 89
[ 9.910477] EIP: [<c1140383>] kfree+0x1e3/0x280 SS:ESP 0068:c78ede90
[ 9.910477] ---[ end trace b8a3675a10c16a9c ]---
[ 9.918123] BUG: unable to handle kernel paging request at fffffffc
[ 9.918410] IP: [<c107d61f>] kthread_data+0xf/0x20
[ 9.918630] *pdpt = 0000000001ce7001 *pde = 0000000001cec067 *pte =
0000000000000000
[ 9.918990] Oops: 0000 [#3] PREEMPT SMP
[ 9.919197] Modules linked in:
[ 9.919339]
[ 9.919426] Pid: 14, comm: kworker/u:1 Tainted: G D W
3.0.0-t43-03370-gb6844e8 #22 Bochs Bochs
[ 9.919791] EIP: 0060:[<c107d61f>] EFLAGS: 00000002 CPU: 0
[ 9.920005] EIP is at kthread_data+0xf/0x20
[ 9.920206] EAX: 00000000 EBX: 00000000 ECX: c1cddd00 EDX: 00000000
[ 9.920468] ESI: 00000000 EDI: c1cddd00 EBP: c78edcac ESP: c78edca0
[ 9.920718] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 9.920942] Process kworker/u:1 (pid: 14, ti=c78ec000 task=c78ea1c0
task.ti=c78ec000)
[ 9.921247] Stack:
[ 9.921348] c10767b1 c78ea1c0 00000000 c78edd3c c17a6ef9 00000000 c1a6cb90
c2426f80
[ 9.921822] c10cc943 c78edcec 00000004 c1cddd00 c1cddd00 c1cddd00 c7d433a0
c78edce4
[ 9.922295] c7d47d00 c78ea1c0 00000202 00000001 00000202 c78ea1c0 c78ea1c0
00000001
[ 9.922878] Call Trace:
[ 9.923018] [<c10767b1>] ? wq_worker_sleeping+0x11/0x80
[ 9.923257] [<c17a6ef9>] schedule+0x589/0x770
[ 9.923466] [<c10cc943>] ? __call_rcu+0xd3/0x190
[ 9.923687] [<c10cca12>] ? call_rcu+0x12/0x20
[ 9.923894] [<c1085b35>] ? creds_are_invalid+0x25/0x60
[ 9.924127] [<c1085bdd>] ? __validate_process_creds+0x6d/0xd0
[ 9.924394] [<c10963be>] ? print_held_locks_bug+0xe/0x80
[ 9.924636] [<c105fb2d>] do_exit+0x20d/0x3e0
[ 9.924843] [<c17ab2e5>] oops_end+0x95/0xd0
[ 9.925056] [<c1015e04>] die+0x54/0x80
[ 9.925243] [<c17aa9f6>] do_trap+0x96/0xd0
[ 9.925443] [<c1013e30>] ? do_coprocessor_segment_overrun+0x90/0x90
[ 9.925716] [<c1013ebc>] do_invalid_op+0x8c/0xb0
[ 9.925935] [<c1140383>] ? kfree+0x1e3/0x280
[ 9.926141] [<c17a9d65>] ? _raw_spin_unlock_irqrestore+0x65/0x80
[ 9.926404] [<c1098579>] ? trace_hardirqs_on_caller+0x19/0xa0
[ 9.926661] [<c17a9d44>] ? _raw_spin_unlock_irqrestore+0x44/0x80
[ 9.926925] [<c134c0ae>] ? debug_object_active_state+0xde/0x120
[ 9.927187] [<c17aa7ab>] ? error_code+0x5b/0x64
[ 9.927398] [<c1013e30>] ? do_coprocessor_segment_overrun+0x90/0x90
[ 9.927467] [<c1094540>] ? trace_hardirqs_off_caller+0x20/0x130
[ 9.927467] [<c133904c>] ? trace_hardirqs_off_thunk+0xc/0x10
[ 9.927467] [<c17aa7af>] error_code+0x5f/0x64
[ 9.927467] [<c11401df>] ? kfree+0x3f/0x280
[ 9.927467] [<c15f5f39>] ? ipv4_frags_exit_net+0x29/0x50
[ 9.927467] [<c1013e30>] ? do_coprocessor_segment_overrun+0x90/0x90
[ 9.927467] [<c1140383>] ? kfree+0x1e3/0x280
[ 9.927467] [<c15f5f39>] ipv4_frags_exit_net+0x29/0x50
[ 9.927467] [<c159eaef>] ops_exit_list+0x2f/0x50
[ 9.927467] [<c159f369>] cleanup_net+0xd9/0x170
[ 9.927467] [<c10778d8>] process_one_work+0x1d8/0x4c0
[ 9.927467] [<c107785c>] ? process_one_work+0x15c/0x4c0
[ 9.927467] [<c159f290>] ? register_pernet_subsys+0x40/0x40
[ 9.927467] [<c1078b70>] worker_thread+0x140/0x3a0
[ 9.927467] [<c17a7462>] ? preempt_schedule+0x32/0x50
[ 9.927467] [<c1078a30>] ? manage_workers+0x110/0x110
[ 9.927467] [<c107dac4>] kthread+0x74/0x80
[ 9.927467] [<c107da50>] ? __init_kthread_worker+0x60/0x60
[ 9.927467] [<c17b0e7a>] kernel_thread_helper+0x6/0x10
[ 9.927467] Code: 8d 74 26 00 64 a1 ac 7d b9 c1 8b 80 6c 02 00 00 5d 8b 40
f8 c3 8d b4 26 00 00 00 00 55 89 e5 3e 8d 74 26 00 8b 80 6c 02 00 00 5d <8b> 40
fc c3 8d b6 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 3e
[ 9.927467] EIP: [<c107d61f>] kthread_data+0xf/0x20 SS:ESP 0068:c78edca0
[ 9.927467] CR2: 00000000fffffffc
[ 9.927467] ---[ end trace b8a3675a10c16a9d ]---
[ 9.927467] Fixing recursive fault but reboot is needed!
No further messages. Kernel freezes.
On 100/1000 of cases, there is line:
[ 5.843059] remove_proc_entry: removing non-empty directory 'net/rpc',
leaking at least 'auth.unix.gid'
And on 63/1000 of cases, there is instead:
[ 9.972779] remove_proc_entry: removing non-empty directory 'net/rpc',
leaking at least 'nfs'
Full kernel message from serial line in qemu attached and config.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast groups
From: Stephen Hemminger @ 2011-07-28 15:41 UTC (permalink / raw)
To: David Lamparter; +Cc: Nick Carter, netdev, Michał Mirosław, davem
In-Reply-To: <20110727111714.GA2027462@jupiter.n2.diac24.net>
On Wed, 27 Jul 2011 13:17:15 +0200
David Lamparter <equinox@diac24.net> wrote:
> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> > > > On 12 July 2011 12:36, David Lamparter <equinox@diac24.net> wrote:
> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> > > > >> I am still undecided on this. Understand the need, but don't like idea
> > > > >> of bridge behaving in non-conforming manner. Will see if IEEE 802 committee
> > > > >> has any input.
> > > > >
> > > > > The patch doesn't make the bridge behave nonconformant. The default mask
> > > > > is 0, which just keeps the old behaviour.
> >
> > P.S.: I'd like to once more stress this. In my opinion the patch should
> > be merged because it provides desireable functionality at a small cost
> > (one test, one knob) and __does not change any default behaviour__.
>
> Stephen, anything new on this?
No.
Don't like adding yet another hack user visible API which will have
to be maintained for too long. But on the other hand I don't have
a better solution at my finger tips. If better idea doesn't come
along, then we can go with yours.
^ permalink raw reply
* RE: [RFC net-next PATCH 2/4] ixgbe: Reconfigure SR-IOV Init
From: Rose, Gregory V @ 2011-07-28 15:44 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
Kirsher, Jeffrey T
In-Reply-To: <20110727.222653.1937782529626247279.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, July 27, 2011 10:27 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 2/4] ixgbe: Reconfigure SR-IOV Init
>
> From: Greg Rose <gregory.v.rose@intel.com>
> Date: Wed, 27 Jul 2011 15:17:54 -0700
>
> > + int i;
> > + for (i = 0; i < adapter->num_vfs; i++) {
> > + if (adapter->vfinfo[i].vfdev->dev_flags &
> > + PCI_DEV_FLAGS_ASSIGNED) {
> > + return true;
> > + }
> > + }
>
> Bad formatting and indentation, please fix this.
Will do.
>
> > + pvfdev = pci_get_device(IXGBE_INTEL_VENDOR_ID, device_id,
> NULL);
> > + while (pvfdev) {
> > + if (pvfdev->devfn == thisvf_devfn)
> > + break;
> > + pvfdev = pci_get_device(IXGBE_INTEL_VENDOR_ID,
> > + device_id, pvfdev);
> > + }
> > + if (pvfdev)
> > + adapter->vfinfo[vfn].vfdev = pvfdev;
>
> pci_get_*() grabs a reference to any non-NULL pci device object
> returned, where does this reference get released? I scanned
> all uses of x.vfdev and x->vfdev and could not find the necessary
> release.
I was ignorant of this behavior. I'll fix it.
- Greg
^ permalink raw reply
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 15:51 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
Kirsher, Jeffrey T
In-Reply-To: <20110727.222749.1654973220321763098.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, July 27, 2011 10:28 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> From: Greg Rose <gregory.v.rose@intel.com>
> Date: Wed, 27 Jul 2011 15:17:59 -0700
>
> > Add new set commands to configure the number of SR-IOV VFs, the
> > number of VM queues and spoof checking on/off switch.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > ---
> >
> > include/linux/ethtool.h | 11 ++++++++++-
> > 1 files changed, 10 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > index c6e427a..c4972ba 100644
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> > __u8 mdio_support;
> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > + __u32 num_vfs; /* Enable SR-IOV VFs */
> > + __u32 num_vmqs; /* Set number of queues for VMDq */
>
> You can't change the layout of this datastructure in this way without
> breaking every ethtool binary out there.
>
> You have to find another place to add these knobs.
Perhaps at the end of the ethtool_cmd structure? Something like this:
/* This should work for both 32 and 64 bit userland. */
struct ethtool_cmd {
__u32 cmd;
__u32 supported; /* Features this interface supports */
__u32 advertising; /* Features this interface advertises */
__u16 speed; /* The forced speed (lower bits) in
* Mbps. Please use
* ethtool_cmd_speed()/_set() to
* access it */
__u8 duplex; /* Duplex, half or full */
__u8 port; /* Which connector port */
__u8 phy_address;
__u8 transceiver; /* Which transceiver to use */
__u8 autoneg; /* Enable or disable autonegotiation */
__u8 mdio_support;
__u32 maxtxpkt; /* Tx pkts before generating tx int */
__u32 maxrxpkt; /* Rx pkts before generating rx int */
__u16 speed_hi; /* The forced speed (upper
* bits) in Mbps. Please use
* ethtool_cmd_speed()/_set() to
* access it */
__u8 eth_tp_mdix;
__u8 spoof_check; /* Enable/Disable anti-spoofing */
__u32 lp_advertising; /* Features the link partner advertises */
__u32 reserved[2];
__u32 num_vfs; /* Enable SR-IOV VFs */
__u32 num_vmqs; /* Set number of queues for VMDq */
};
- Greg
^ permalink raw reply
* RE: [RFC net-next PATCH 4/4] ixgbe: Add support for new ethtool settings
From: Rose, Gregory V @ 2011-07-28 15:52 UTC (permalink / raw)
To: Michał Mirosław
Cc: netdev@vger.kernel.org, davem@davemloft.net,
bhutchings@solarflare.com, Kirsher, Jeffrey T
In-Reply-To: <CAHXqBFJ30LLV=dgWuSK73rhxYLt5xoVFVwHdU3cWFmr_Yxs5pg@mail.gmail.com>
> -----Original Message-----
> From: Michał Mirosław [mailto:mirqus@gmail.com]
> Sent: Thursday, July 28, 2011 4:54 AM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; davem@davemloft.net;
> bhutchings@solarflare.com; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 4/4] ixgbe: Add support for new ethtool
> settings
>
> 2011/7/28 Greg Rose <gregory.v.rose@intel.com>:
> > Adds ixgbe driver support for new ethtool settings for SR-IOV re-init,
> > number of VM queues and anti-spoofing ON/OFF switch.
> [...]
> > +static int ixgbe_reinit_sriov(struct net_device *netdev, int new_vfs)
> > +{
> [...]
> > + if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED) {
> > + adapter->flags &= ~(IXGBE_FLAG_RSS_ENABLED |
> > + IXGBE_FLAG_DCB_ENABLED);
> > + netdev->features &= ~NETIF_F_RXHASH;
> > + } else {
> > + adapter->flags |= IXGBE_FLAG_RSS_ENABLED;
> > + netdev->features |= NETIF_F_RXHASH;
> > + }
>
> Please use ndo_fix_features/ndo_set_features callbacks for this.
OK, sure. I'll add a separate patch to do that.
- Greg
^ permalink raw reply
* RE: [RFC net-next PATCH 1/4] pci: Add flag indicating device has been assigned by KVM
From: Rose, Gregory V @ 2011-07-28 15:58 UTC (permalink / raw)
To: Ian Campbell, Konrad Rzeszutek Wilk
Cc: netdev@vger.kernel.org, davem@davemloft.net,
bhutchings@solarflare.com, Kirsher, Jeffrey T, Jesse Barnes,
linux-pci@vger.kernel.org
In-Reply-To: <1311865877.24408.144.camel@cthulhu.hellion.org.uk>
> -----Original Message-----
> From: Ian Campbell [mailto:ijc@hellion.org.uk]
> Sent: Thursday, July 28, 2011 8:11 AM
> To: Rose, Gregory V; Konrad Rzeszutek Wilk
> Cc: netdev@vger.kernel.org; davem@davemloft.net;
> bhutchings@solarflare.com; Kirsher, Jeffrey T; Jesse Barnes; linux-
> pci@vger.kernel.org
> Subject: Re: [RFC net-next PATCH 1/4] pci: Add flag indicating device has
> been assigned by KVM
>
> On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > Device drivers that create and destroy SR-IOV virtual functions via
> > calls to pci_enable_sriov() and pci_disable_sriov can cause catastrophic
> > failures if they attempt to destroy VFs while they are assigned to
> > guest virtual machines. By adding a flag for use by the KVM module
> > to indicate that a device is assigned a device driver can check that
> > flag and avoid destroying VFs while they are assigned and avoid system
> > failures.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > ---
> >
> > include/linux/pci.h | 2 ++
>
> I added Jesse and linux-pci to CC.
>
> > virt/kvm/assigned-dev.c | 2 ++
> > virt/kvm/iommu.c | 4 ++++
> > 3 files changed, 8 insertions(+), 0 deletions(-)
>
> I suppose this would also be useful in Xen's pciback or any other system
> which does passthrough? (Konrad CC'd for pciback)
Definitely yes. Xen experiences the same issues when the PF driver is removed while VFs are assigned to guests.
>
> Is there some common lower layer we could hook this in to? (does
> iommu_attach/detach_device make sense?) Or shall we just add the flag
> manipulations to pciback as well?
[Greg Rose]
I was unaware of any common lower layers, i.e I didn't know that Xen also uses the iommu_attach/detach_device calls. It took me a week of digging around in the KVM module code just to find these hooks. Generally I stick to Ethernet device drivers and I'm not that familiar with device pass through code. I was just confronted with a problem and looking for some way to fix it.
;^)
That sounds like a good idea, let me have a look at it.
- Greg
^ permalink raw reply
* Re: [Bug 40132] New: kernel BUG at mm/slab.c:501, when in kfree from ipv4_frags_exit_net
From: David Miller @ 2011-07-28 16:13 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20110728083526.6f55bee9@nehalam.ftrdhcpuser.net>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Thu, 28 Jul 2011 08:35:26 -0700
>
>
> Begin forwarded message:
I think the first OOPS in path_init() potentially corrupts his memory,
and then all bets are off.
There's a lot of SUNRPC failures in these traces too.
Close this and tell the reporter to reopen the bug if it persists after
getting rid of the initial crashes that happen first.
^ permalink raw reply
* Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: David Miller @ 2011-07-28 16:14 UTC (permalink / raw)
To: gregory.v.rose; +Cc: netdev, bhutchings, jeffrey.t.kirsher
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019414D509@orsmsx508.amr.corp.intel.com>
From: "Rose, Gregory V" <gregory.v.rose@intel.com>
Date: Thu, 28 Jul 2011 08:51:05 -0700
>> -----Original Message-----
>> From: David Miller [mailto:davem@davemloft.net]
>> Sent: Wednesday, July 27, 2011 10:28 PM
>> To: Rose, Gregory V
>> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
>> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>>
>> From: Greg Rose <gregory.v.rose@intel.com>
>> Date: Wed, 27 Jul 2011 15:17:59 -0700
>>
>> > Add new set commands to configure the number of SR-IOV VFs, the
>> > number of VM queues and spoof checking on/off switch.
>> >
>> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
>> > ---
>> >
>> > include/linux/ethtool.h | 11 ++++++++++-
>> > 1 files changed, 10 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> > index c6e427a..c4972ba 100644
>> > --- a/include/linux/ethtool.h
>> > +++ b/include/linux/ethtool.h
>> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
>> > __u8 mdio_support;
>> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
>> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
>> > + __u32 num_vfs; /* Enable SR-IOV VFs */
>> > + __u32 num_vmqs; /* Set number of queues for VMDq */
>>
>> You can't change the layout of this datastructure in this way without
>> breaking every ethtool binary out there.
>>
>> You have to find another place to add these knobs.
>
> Perhaps at the end of the ethtool_cmd structure? Something like this:
Either use the two reserved u32's we have there, or create a new
ethtool command and control structure.
^ permalink raw reply
* Re: [PATCH 2/2] ASIX: Use only 11 bits of header for data size
From: Marek Vasut @ 2011-07-28 16:17 UTC (permalink / raw)
To: Greg KH
Cc: David Miller, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-l3A5Bk7waGM
In-Reply-To: <20110728151806.GB22202-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Thursday, July 28, 2011 05:18:06 PM Greg KH wrote:
> On Thu, Jul 28, 2011 at 08:06:18AM +0200, Marek Vasut wrote:
> > On Thursday, July 28, 2011 07:40:29 AM David Miller wrote:
> > > From: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > Date: Wed, 27 Jul 2011 04:44:47 +0200
> > >
> > > > The AX88772B uses only 11 bits of the header for the actual size. The
> > > > other bits
> > > >
> > > > are used for something else. This causes dmesg full of messages:
> > > > asix_rx_fixup() Bad Header Length
> > > >
> > > > This patch trims the check to only 11 bits. I believe on older chips,
> > > > the remaining 5 top bits are unused.
> > > >
> > > > Signed-off-by: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > >
> > > Applied.
> >
> > Hi, did you test it ?
> >
> > I left NOTEs outside the commit message:
> >
> > NOTE: If possible, can someone test/verify this patch with other ASIX
> > chips ? NOTE2: If Ack-ed, Greg, can you get this into -stable?
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
Yea I know ... I'm just so very tired (read dead). Sorry
>
> </formletter>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] sis190: Rx filter init is needed for MAC address change.
From: Francois Romieu @ 2011-07-28 16:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Klement Fish
From: Klement Fish <klement2@azet.sk>
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=34552
Signed-off-by: Klement Fish <klement2@azet.sk>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/sis190.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index 8ad7bfb..3c0f131 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -1825,6 +1825,16 @@ static int sis190_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
generic_mii_ioctl(&tp->mii_if, if_mii(ifr), cmd, NULL);
}
+static int sis190_mac_addr(struct net_device *dev, void *p)
+{
+ int rc;
+
+ rc = eth_mac_addr(dev, p);
+ if (!rc)
+ sis190_init_rxfilter(dev);
+ return rc;
+}
+
static const struct net_device_ops sis190_netdev_ops = {
.ndo_open = sis190_open,
.ndo_stop = sis190_close,
@@ -1833,7 +1843,7 @@ static const struct net_device_ops sis190_netdev_ops = {
.ndo_tx_timeout = sis190_tx_timeout,
.ndo_set_multicast_list = sis190_set_rx_mode,
.ndo_change_mtu = eth_change_mtu,
- .ndo_set_mac_address = eth_mac_addr,
+ .ndo_set_mac_address = sis190_mac_addr,
.ndo_validate_addr = eth_validate_addr,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = sis190_netpoll,
--
1.7.4.4
^ permalink raw reply related
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 16:21 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
Kirsher, Jeffrey T
In-Reply-To: <20110728.091448.548423057039764289.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, July 28, 2011 9:15 AM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> From: "Rose, Gregory V" <gregory.v.rose@intel.com>
> Date: Thu, 28 Jul 2011 08:51:05 -0700
>
> >> -----Original Message-----
> >> From: David Miller [mailto:davem@davemloft.net]
> >> Sent: Wednesday, July 27, 2011 10:28 PM
> >> To: Rose, Gregory V
> >> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey
> T
> >> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> >>
> >> From: Greg Rose <gregory.v.rose@intel.com>
> >> Date: Wed, 27 Jul 2011 15:17:59 -0700
> >>
> >> > Add new set commands to configure the number of SR-IOV VFs, the
> >> > number of VM queues and spoof checking on/off switch.
> >> >
> >> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> >> > ---
> >> >
> >> > include/linux/ethtool.h | 11 ++++++++++-
> >> > 1 files changed, 10 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> >> > index c6e427a..c4972ba 100644
> >> > --- a/include/linux/ethtool.h
> >> > +++ b/include/linux/ethtool.h
> >> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> >> > __u8 mdio_support;
> >> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> >> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> >> > + __u32 num_vfs; /* Enable SR-IOV VFs */
> >> > + __u32 num_vmqs; /* Set number of queues for VMDq */
> >>
> >> You can't change the layout of this datastructure in this way without
> >> breaking every ethtool binary out there.
> >>
> >> You have to find another place to add these knobs.
> >
> > Perhaps at the end of the ethtool_cmd structure? Something like this:
>
> Either use the two reserved u32's we have there, or create a new
> ethtool command and control structure.
OK, I see what you're saying. The size of the structure can never be changed. I'm slow sometimes but I do eventually get there. I didn't want to use the reserved u32's because I didn't know what they were reserved for. The num_vfs and num_vmqs values will actually never exceed 8 bits. I'll stuff them into the space used by one of the u32's and then add padding to align and keep the same structure size.
Thanks for the feedback and help. I'll address this and the other feedback I've gotten and come back later with V2 of the RFC.
- Greg
^ permalink raw reply
* RE: [RFC net-next PATCH 1/4] pci: Add flag indicating device has been assigned by KVM
From: Ian Campbell @ 2011-07-28 16:27 UTC (permalink / raw)
To: Rose, Gregory V
Cc: Konrad Rzeszutek Wilk, netdev@vger.kernel.org,
davem@davemloft.net, bhutchings@solarflare.com,
Kirsher, Jeffrey T, Jesse Barnes, linux-pci@vger.kernel.org
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019414D525@orsmsx508.amr.corp.intel.com>
On Thu, 2011-07-28 at 08:58 -0700, Rose, Gregory V wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > Sent: Thursday, July 28, 2011 8:11 AM
> > To: Rose, Gregory V; Konrad Rzeszutek Wilk
> > Cc: netdev@vger.kernel.org; davem@davemloft.net;
> > bhutchings@solarflare.com; Kirsher, Jeffrey T; Jesse Barnes; linux-
> > pci@vger.kernel.org
> > Subject: Re: [RFC net-next PATCH 1/4] pci: Add flag indicating device has
> > been assigned by KVM
> >
> > On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > > Device drivers that create and destroy SR-IOV virtual functions via
> > > calls to pci_enable_sriov() and pci_disable_sriov can cause catastrophic
> > > failures if they attempt to destroy VFs while they are assigned to
> > > guest virtual machines. By adding a flag for use by the KVM module
> > > to indicate that a device is assigned a device driver can check that
> > > flag and avoid destroying VFs while they are assigned and avoid system
> > > failures.
> > >
> > > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > > ---
> > >
> > > include/linux/pci.h | 2 ++
> >
> > I added Jesse and linux-pci to CC.
> >
> > > virt/kvm/assigned-dev.c | 2 ++
> > > virt/kvm/iommu.c | 4 ++++
> > > 3 files changed, 8 insertions(+), 0 deletions(-)
> >
> > I suppose this would also be useful in Xen's pciback or any other system
> > which does passthrough? (Konrad CC'd for pciback)
>
> Definitely yes. Xen experiences the same issues when the PF driver is
> removed while VFs are assigned to guests.
>
> >
> > Is there some common lower layer we could hook this in to? (does
> > iommu_attach/detach_device make sense?) Or shall we just add the flag
> > manipulations to pciback as well?
> [Greg Rose]
>
> I was unaware of any common lower layers, i.e I didn't know that Xen
> also uses the iommu_attach/detach_device calls.
my mistake -- under Xen the iommu is driver by the hypervisor and not
the domain 0 kernel so there is no iommu_* in pciback.
> It took me a week of digging around in the KVM module code just to
> find these hooks.
I'm not actually sure where in pciback the right place to put this would
be is, perhaps Konrad has an idea.
> Generally I stick to Ethernet device drivers and I'm not that
> familiar with device pass through code. I was just confronted with a
> problem and looking for some way to fix it.
>
> ;^)
>
> That sounds like a good idea, let me have a look at it.
>
> - Greg
>
--
Ian Campbell
Traffic signals in New York are just rough guidelines.
-- David Letterman
^ permalink raw reply
* Re: strange behaviour of MC7700 with sierra_net
From: Phil Sutter @ 2011-07-28 16:32 UTC (permalink / raw)
To: Dan Williams
Cc: Elina Pasheva, dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Rory Filer
In-Reply-To: <1311795643.17655.13.camel-wKZy7rqYPVb5EHUCmHmTqw@public.gmane.org>
Dan,
Thanks for the quick reply!
On Wed, Jul 27, 2011 at 02:40:40PM -0500, Dan Williams wrote:
> I wonder if the firmware changed and Sierra hasn't updated the driver
> yet. I've got a usb306 which also uses sierra_net which doesn't have
> this problem. It looks like the driver tries to sync with the firmware
> right after binding to the net interface, so that means at least a
> couple of SYNC requests have already happened by the time you start
> getting errors. My first thought here is simply that the firmware on
> the MC7700 doesn't work like the rest of the devices that sierra_net
> expects, and for that you'd have to get Sierra to weigh in on the
> required changes :(
That's exactly the case. My printf-debugging shows that ~30 calls to
sierra_net_dosync() sycceed before it starts failing. Why the heck does
that work if I set the interface up? When doing so, the driver
immediately receives a whole bunch of restart-messages. Looks
like the number matches the number of successfully sent sync-messages.
This looks like the turned down interface is holding something back, but
looking with usbmon I see communication (this is the point when the
sync-messages start to fail):
| da9ebc40 74.842086 S Co:1:035:0 s 21 00 0000 0007 0004 4 = 00002000
| da9ebc40 74.842971 C Co:1:035:0 0 4 >
| da9ebc40 76.848151 S Co:1:035:0 s 21 00 0000 0007 0004 4 = 00002000
| da9ebc40 76.848835 C Co:1:035:0 -32 4 >
But maybe something should be done in the beginning that's done when the
interface comes up. The capture in that situation is this:
| da9ebc40 88.898257 S Co:1:035:0 s 21 00 0000 0007 0004 4 = 00002000
| da9ebc40 88.898860 C Co:1:035:0 -32 4 >
| dbe29dc0 90.548212 S Ii:1:035:8 -:64 64 <
| da9ebc40 90.548619 S Bi:1:035:9 - 8192 <
| dbe29c40 90.548632 S Bi:1:035:9 - 8192 <
| daab45c0 90.548639 S Bi:1:035:9 - 8192 <
| daac3640 90.548645 S Bi:1:035:9 - 8192 <
| da9cce40 90.548651 S Bi:1:035:9 - 8192 <
| dbe6b7c0 90.548657 S Bi:1:035:9 - 8192 <
| dab0ae40 90.548663 S Bi:1:035:9 - 8192 <
| dbe29640 90.548669 S Bi:1:035:9 - 8192 <
| dbe29340 90.548675 S Bi:1:035:9 - 8192 <
| dbe6b540 90.548681 S Bi:1:035:9 - 8192 <
| dbe6b0c0 90.548688 S Bi:1:035:9 - 8192 <
| dbe29dc0 90.550814 C Ii:1:035:8 0:64 8 = a1010000 07000000
| dbe29dc0 90.550868 S Ii:1:035:8 -:64 64 <
| daac3540 90.550980 S Ci:1:035:0 s a1 01 0000 0007 0400 1024 <
| daac3540 90.551694 C Ci:1:035:0 0 68 = 00406200 53574939 32303058 5f30332e 30302e30 322e3030 41502052 32303332
| dbe29dc0 90.558801 C Ii:1:035:8 0:64 8 = a1010000 07000000
| dbe29dc0 90.558960 S Ii:1:035:8 -:64 64 <
| daac3540 90.559054 S Ci:1:035:0 s a1 01 0000 0007 0400 1024 <
| daac3540 90.559544 C Ci:1:035:0 0 68 = 00406200 53574939 32303058 5f30332e 30302e30 322e3030 41502052 32303332
| dbe29dc0 90.566798 C Ii:1:035:8 0:64 8 = a1010000 07000000
The kernel log output of the above timeframe:
| Jul 28 17:55:36 (none) user.debug kernel: [266833.170570] usb 1-1: sierra_net_send_sync
| Jul 28 17:55:36 (none) user.info kernel: [266833.170590] sierra_net_send_sync: netif is not running
| Jul 28 17:55:36 (none) user.err kernel: [266833.171515] sierra_net 1-1:1.7: wwan0: Submit SYNC failed -32
| Jul 28 17:55:36 (none) user.err kernel: [266833.174713] sierra_net 1-1:1.7: wwan0: Send SYNC failed, status -32
| Jul 28 17:55:38 (none) user.debug kernel: [266834.823421] usb 1-1: sierra_net_status
| Jul 28 17:55:38 (none) user.debug kernel: [266834.824316] usb 1-1: sierra_net_kevent: Received status message, 0044 bytes
| Jul 28 17:55:38 (none) user.debug kernel: [266834.824475] usb 1-1: Restart reported: 0, stopping sync timer
| Jul 28 17:55:38 (none) user.debug kernel: [266834.831400] usb 1-1: sierra_net_status
| Jul 28 17:55:38 (none) user.debug kernel: [266834.832268] usb 1-1: sierra_net_kevent: Received status message, 0044 bytes
| Jul 28 17:55:38 (none) user.debug kernel: [266834.832426] usb 1-1: Restart reported: 0, stopping sync timer
> Since the MC7700 is an LTE module it's 100% likely the firmware is
> different, or at least significantly rebased, from the existing Sierra
> HSPA/EVDO parts that use sierra_net and thus I wouldn't necessarily
> expect it to work out of the box.
Well, it's obviously not that bad. Setting wwan0 up as a workaround,
everything's quite fine. Also, if I'm fast enough initialising the modem
via AT-commands before the control-tty dies, I can dial in even with
wwan0 being down, set it up and receive an address via DHCP.
Since the MC7700 has the same USB product and vendor IDs as any other
direct-IP device (1199:68a3), Sierra may indeed have meant this device
to act identical to the other ones. Or their driver-developers are just
a little bit masochistic. ;)
Hopefully Elina Pasheva can provide some helpful insights here.
Greetings, Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [RFC net-next PATCH 1/4] pci: Add flag indicating device has been assigned by KVM
From: Rose, Gregory V @ 2011-07-28 16:42 UTC (permalink / raw)
To: Ian Campbell
Cc: Konrad Rzeszutek Wilk, netdev@vger.kernel.org,
davem@davemloft.net, bhutchings@solarflare.com,
Kirsher, Jeffrey T, Jesse Barnes, linux-pci@vger.kernel.org
In-Reply-To: <1311870459.24408.151.camel@cthulhu.hellion.org.uk>
> -----Original Message-----
> From: Ian Campbell [mailto:ijc@hellion.org.uk]
> Sent: Thursday, July 28, 2011 9:28 AM
> To: Rose, Gregory V
> Cc: Konrad Rzeszutek Wilk; netdev@vger.kernel.org; davem@davemloft.net;
> bhutchings@solarflare.com; Kirsher, Jeffrey T; Jesse Barnes; linux-
> pci@vger.kernel.org
> Subject: RE: [RFC net-next PATCH 1/4] pci: Add flag indicating device has
> been assigned by KVM
>
> On Thu, 2011-07-28 at 08:58 -0700, Rose, Gregory V wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > Sent: Thursday, July 28, 2011 8:11 AM
> > > To: Rose, Gregory V; Konrad Rzeszutek Wilk
> > > Cc: netdev@vger.kernel.org; davem@davemloft.net;
> > > bhutchings@solarflare.com; Kirsher, Jeffrey T; Jesse Barnes; linux-
> > > pci@vger.kernel.org
> > > Subject: Re: [RFC net-next PATCH 1/4] pci: Add flag indicating device
> has
> > > been assigned by KVM
> > >
> > > On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > > > Device drivers that create and destroy SR-IOV virtual functions via
> > > > calls to pci_enable_sriov() and pci_disable_sriov can cause
> catastrophic
> > > > failures if they attempt to destroy VFs while they are assigned to
> > > > guest virtual machines. By adding a flag for use by the KVM module
> > > > to indicate that a device is assigned a device driver can check that
> > > > flag and avoid destroying VFs while they are assigned and avoid
> system
> > > > failures.
> > > >
> > > > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > > > ---
> > > >
> > > > include/linux/pci.h | 2 ++
> > >
> > > I added Jesse and linux-pci to CC.
> > >
> > > > virt/kvm/assigned-dev.c | 2 ++
> > > > virt/kvm/iommu.c | 4 ++++
> > > > 3 files changed, 8 insertions(+), 0 deletions(-)
> > >
> > > I suppose this would also be useful in Xen's pciback or any other
> system
> > > which does passthrough? (Konrad CC'd for pciback)
> >
> > Definitely yes. Xen experiences the same issues when the PF driver is
> > removed while VFs are assigned to guests.
> >
> > >
> > > Is there some common lower layer we could hook this in to? (does
> > > iommu_attach/detach_device make sense?) Or shall we just add the flag
> > > manipulations to pciback as well?
> > [Greg Rose]
> >
> > I was unaware of any common lower layers, i.e I didn't know that Xen
> > also uses the iommu_attach/detach_device calls.
>
> my mistake -- under Xen the iommu is driver by the hypervisor and not
> the domain 0 kernel so there is no iommu_* in pciback.
>
> > It took me a week of digging around in the KVM module code just to
> > find these hooks.
>
> I'm not actually sure where in pciback the right place to put this would
> be is, perhaps Konrad has an idea.
OK, but I hope Xen can still use the dev_flag assignment bit.
Thanks,
- Greg
^ permalink raw reply
* [PATCH] net: fix new sunrpc kernel-doc warning
From: Randy Dunlap @ 2011-07-28 16:54 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <rdunlap@xenotime.net>
Fix new kernel-doc warning in sunrpc:
Warning(net/sunrpc/xprt.c:196): No description found for parameter 'xprt'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
net/sunrpc/xprt.c | 1 +
1 file changed, 1 insertion(+)
--- linux-3.0-git10.orig/net/sunrpc/xprt.c
+++ linux-3.0-git10/net/sunrpc/xprt.c
@@ -187,6 +187,7 @@ EXPORT_SYMBOL_GPL(xprt_load_transport);
/**
* xprt_reserve_xprt - serialize write access to transports
* @task: task that is requesting access to the transport
+ * @xprt: pointer to the target transport
*
* This prevents mixing the payload of separate requests, and prevents
* transport connects from colliding with writes. No congestion control
^ permalink raw reply
* [PATCH] sunrpc: use better NUMA affinities
From: Eric Dumazet @ 2011-07-28 18:04 UTC (permalink / raw)
To: Trond Myklebust
Cc: J. Bruce Fields, Neil Brown, David Miller, linux-nfs, netdev,
linux-kernel
Use NUMA aware allocations to reduce latencies and increase throughput.
sunrpc kthreads can use kthread_create_on_node() if pool_mode is
"percpu" or "pernode", and svc_prepare_thread()/svc_init_buffer() can
also take into account NUMA node affinity for memory allocations.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: "J. Bruce Fields" <bfields@fieldses.org>
CC: Neil Brown <neilb@suse.de>
CC: David Miller <davem@davemloft.net>
---
fs/lockd/svc.c | 2 +-
fs/nfs/callback.c | 2 +-
include/linux/sunrpc/svc.h | 2 +-
net/sunrpc/svc.c | 33 ++++++++++++++++++++++++---------
4 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index abfff9d..c061b9a 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -282,7 +282,7 @@ int lockd_up(void)
/*
* Create the kernel thread and wait for it to start.
*/
- nlmsvc_rqst = svc_prepare_thread(serv, &serv->sv_pools[0]);
+ nlmsvc_rqst = svc_prepare_thread(serv, &serv->sv_pools[0], NUMA_NO_NODE);
if (IS_ERR(nlmsvc_rqst)) {
error = PTR_ERR(nlmsvc_rqst);
nlmsvc_rqst = NULL;
diff --git a/fs/nfs/callback.c b/fs/nfs/callback.c
index e3d2942..ce620b5 100644
--- a/fs/nfs/callback.c
+++ b/fs/nfs/callback.c
@@ -125,7 +125,7 @@ nfs4_callback_up(struct svc_serv *serv)
else
goto out_err;
- return svc_prepare_thread(serv, &serv->sv_pools[0]);
+ return svc_prepare_thread(serv, &serv->sv_pools[0], NUMA_NO_NODE);
out_err:
if (ret == 0)
diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
index 223588a..a78a51e 100644
--- a/include/linux/sunrpc/svc.h
+++ b/include/linux/sunrpc/svc.h
@@ -404,7 +404,7 @@ struct svc_procedure {
struct svc_serv *svc_create(struct svc_program *, unsigned int,
void (*shutdown)(struct svc_serv *));
struct svc_rqst *svc_prepare_thread(struct svc_serv *serv,
- struct svc_pool *pool);
+ struct svc_pool *pool, int node);
void svc_exit_thread(struct svc_rqst *);
struct svc_serv * svc_create_pooled(struct svc_program *, unsigned int,
void (*shutdown)(struct svc_serv *),
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index 6a69a11..30d70ab 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -295,6 +295,18 @@ svc_pool_map_put(void)
}
+static int svc_pool_map_get_node(unsigned int pidx)
+{
+ const struct svc_pool_map *m = &svc_pool_map;
+
+ if (m->count) {
+ if (m->mode == SVC_POOL_PERCPU)
+ return cpu_to_node(m->pool_to[pidx]);
+ if (m->mode == SVC_POOL_PERNODE)
+ return m->pool_to[pidx];
+ }
+ return NUMA_NO_NODE;
+}
/*
* Set the given thread's cpus_allowed mask so that it
* will only run on cpus in the given pool.
@@ -499,7 +511,7 @@ EXPORT_SYMBOL_GPL(svc_destroy);
* We allocate pages and place them in rq_argpages.
*/
static int
-svc_init_buffer(struct svc_rqst *rqstp, unsigned int size)
+svc_init_buffer(struct svc_rqst *rqstp, unsigned int size, int node)
{
unsigned int pages, arghi;
@@ -513,7 +525,7 @@ svc_init_buffer(struct svc_rqst *rqstp, unsigned int size)
arghi = 0;
BUG_ON(pages > RPCSVC_MAXPAGES);
while (pages) {
- struct page *p = alloc_page(GFP_KERNEL);
+ struct page *p = alloc_pages_node(node, GFP_KERNEL, 0);
if (!p)
break;
rqstp->rq_pages[arghi++] = p;
@@ -536,11 +548,11 @@ svc_release_buffer(struct svc_rqst *rqstp)
}
struct svc_rqst *
-svc_prepare_thread(struct svc_serv *serv, struct svc_pool *pool)
+svc_prepare_thread(struct svc_serv *serv, struct svc_pool *pool, int node)
{
struct svc_rqst *rqstp;
- rqstp = kzalloc(sizeof(*rqstp), GFP_KERNEL);
+ rqstp = kzalloc_node(sizeof(*rqstp), GFP_KERNEL, node);
if (!rqstp)
goto out_enomem;
@@ -554,15 +566,15 @@ svc_prepare_thread(struct svc_serv *serv, struct svc_pool *pool)
rqstp->rq_server = serv;
rqstp->rq_pool = pool;
- rqstp->rq_argp = kmalloc(serv->sv_xdrsize, GFP_KERNEL);
+ rqstp->rq_argp = kmalloc_node(serv->sv_xdrsize, GFP_KERNEL, node);
if (!rqstp->rq_argp)
goto out_thread;
- rqstp->rq_resp = kmalloc(serv->sv_xdrsize, GFP_KERNEL);
+ rqstp->rq_resp = kmalloc_node(serv->sv_xdrsize, GFP_KERNEL, node);
if (!rqstp->rq_resp)
goto out_thread;
- if (!svc_init_buffer(rqstp, serv->sv_max_mesg))
+ if (!svc_init_buffer(rqstp, serv->sv_max_mesg, node))
goto out_thread;
return rqstp;
@@ -647,6 +659,7 @@ svc_set_num_threads(struct svc_serv *serv, struct svc_pool *pool, int nrservs)
struct svc_pool *chosen_pool;
int error = 0;
unsigned int state = serv->sv_nrthreads-1;
+ int node;
if (pool == NULL) {
/* The -1 assumes caller has done a svc_get() */
@@ -662,14 +675,16 @@ svc_set_num_threads(struct svc_serv *serv, struct svc_pool *pool, int nrservs)
nrservs--;
chosen_pool = choose_pool(serv, pool, &state);
- rqstp = svc_prepare_thread(serv, chosen_pool);
+ node = svc_pool_map_get_node(chosen_pool->sp_id);
+ rqstp = svc_prepare_thread(serv, chosen_pool, node);
if (IS_ERR(rqstp)) {
error = PTR_ERR(rqstp);
break;
}
__module_get(serv->sv_module);
- task = kthread_create(serv->sv_function, rqstp, serv->sv_name);
+ task = kthread_create_on_node(serv->sv_function, rqstp,
+ node, serv->sv_name);
if (IS_ERR(task)) {
error = PTR_ERR(task);
module_put(serv->sv_module);
^ permalink raw reply related
* RE: [PATCH 0/8] bna: Driver Fixes and Support for Re-architecture
From: Rasesh Mody @ 2011-07-28 19:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Adapter Linux Open SRC Team
In-Reply-To: <20110727.223231.1088299143542685793.davem@davemloft.net>
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, July 27, 2011 10:33 PM
>
>From: Rasesh Mody <rmody@brocade.com>
>Date: Tue, 26 Jul 2011 19:10:40 -0700
>
>> This patch-set consists of few fixes, HW reg consolidation and adds
>support
>> for re-architecture and re-organisation of the driver.
>
>Please do not mix bug fixes and feature changes.
>
>If you do this, I can't put the bug fixes into the current release.
>
>Seperate out the real pure bug fixes into a seperate series against
>the main 'net' GIT tree.
>
>Then you can submit your feature changes and cleanups seperately for
>'net-next'
We will submit the bug fixes and the feature changes separately.
Thanks,
Rasesh
^ permalink raw reply
* Re: special handling before ndo_start_xmit() been invoked
From: Jiri Pirko @ 2011-07-28 19:37 UTC (permalink / raw)
To: jiangtao.jit; +Cc: netdev
In-Reply-To: <201107271848349537853@gmail.com>
What would you want to achieve with that?
Wed, Jul 27, 2011 at 12:48:37PM CEST, jiangtao.jit@gmail.com wrote:
>Hi all:
>
>in struct net_device
>there is a function pointer rx_handler_func_t __rcu *rx_handler
>it's very convenient to register a function in an externel module
>and do some special handlings
>
>so i think what about to add an tx_handler_func
>before ndo_start_xmit() been invoked
>and do some special things before transmit
>
>is it necessary or there is already some other better methods to achieve this goal ?
>Thank you all
>
>-------
>2011-07-27
>jiangtao.jit
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Dead code in Starfire driver (set_vlan_mode())
From: Jesper Juhl @ 2011-07-28 20:35 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Alexey Dobriyan, Ben Hutchings, FUJITA Tomonori,
Akinobu Mita, David S. Miller, Ion Badulescu, becker
In drivers/net/starfire.c::set_vlan_mode() there is this code:
...
if (vlan_count == 32) {
ret |= PerfectFilterVlan;
while (vlan_count < 32) {
...
We've just tested 'vlan_count' as being equal to '32', so it's a bit silly
to follow that up with a loop that's conditioned on the variable being
less than that - it will never execute.
Now I don't know this code at all, so I have no idea what the proper fix
is (just remove the loop? change the loop condition? something else?), but
I do know that the current code makes little sense ;-)
Just for your information.
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 20:38 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: David Miller, netdev, Ben Hutchings, Kirsher, Jeffrey T
In-Reply-To: <539DF151-E442-4375-8777-19676B95059B@qlogic.com>
> From: Anirban Chakraborty [mailto:anirban.chakraborty@qlogic.com]
> Sent: Thursday, July 28, 2011 12:04 PM
> To: Rose, Gregory V
> Cc: David Miller; netdev; Ben Hutchings; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
>
> On Jul 28, 2011, at 8:51 AM, Rose, Gregory V wrote:
>
>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, July 27, 2011 10:28 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> From: Greg Rose <gregory.v.rose@intel.com>
> Date: Wed, 27 Jul 2011 15:17:59 -0700
>
> Add new set commands to configure the number of SR-IOV VFs, the
> number of VM queues and spoof checking on/off switch.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> ---
>
> include/linux/ethtool.h | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index c6e427a..c4972ba 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -36,12 +36,14 @@ struct ethtool_cmd {
> __u8 mdio_support;
> __u32 maxtxpkt; /* Tx pkts before generating tx int */
> __u32 maxrxpkt; /* Rx pkts before generating rx int */
> + __u32 num_vfs; /* Enable SR-IOV VFs */
> + __u32 num_vmqs; /* Set number of queues for VMDq */
>
> You can't change the layout of this datastructure in this way without
> breaking every ethtool binary out there.
>
> You have to find another place to add these knobs.
>
> Perhaps at the end of the ethtool_cmd structure? Something like this:
>
> /* This should work for both 32 and 64 bit userland. */
> struct ethtool_cmd {
> __u32 cmd;
> __u32 supported; /* Features this interface supports */
> __u32 advertising; /* Features this interface advertises */
> __u16 speed; /* The forced speed (lower bits) in
> * Mbps. Please use
> * ethtool_cmd_speed()/_set() to
> * access it */
> __u8 duplex; /* Duplex, half or full */
> __u8 port; /* Which connector port */
> __u8 phy_address;
> __u8 transceiver; /* Which transceiver to use */
> __u8 autoneg; /* Enable or disable autonegotiation */
> __u8 mdio_support;
> __u32 maxtxpkt; /* Tx pkts before generating tx int */
> __u32 maxrxpkt; /* Rx pkts before generating rx int */
> __u16 speed_hi; /* The forced speed (upper
> * bits) in Mbps. Please use
> * ethtool_cmd_speed()/_set() to
> * access it */
> __u8 eth_tp_mdix;
> __u8 spoof_check; /* Enable/Disable anti-spoofing */
> __u32 lp_advertising; /* Features the link partner advertises */
> __u32 reserved[2];
> __u32 num_vfs; /* Enable SR-IOV VFs */
> __u32 num_vmqs; /* Set number of queues for VMDq */
> };
>
> If I understood it correctly, you are trying to set/unset spoofing on per
> eth interface, which could be a PF on the hypervisor or a pci passthru-ed
> VF in the linux guest. There are other security features that one could set
> for a port on the VF (lets call it vport), e.g. setting a port VLAN ID for
> a VF and specifying if the VF (VM) is allowed to send tagged/untagged
> packets, setting a vport in port mirroring mode so that the PF can monitor
> the traffic on a VF, setting a vport in promiscuous mode etc.
>
> Does it make sense to try to use ip link util to specify all these parameters,
> since ip link already does the job of setting VF properties and VF port
> profile?
>
> Any thoughts?
>
Sure, that's a possibility too. I was considering ethtool for this since MAC addresses and VLANs are fairly specific to Ethernet whereas netlink might apply to other types of physical networks. At least that's my understanding.
However, I have no strong feelings about it and if community consensus is to use ip link instead then that's fine by me.
Of course, patches implementing such would be quite welcome also.
;^)
- Greg
^ permalink raw reply
* [PATCH] xfrm: Fix key lengths for rfc3686(ctr(aes))
From: Tushar Gohad @ 2011-07-28 20:36 UTC (permalink / raw)
To: Joy Latten, Herbert Xu; +Cc: netdev, tgohad
Fix the min and max bit lengths for AES-CTR (RFC3686) keys.
The number of bits in key spec is the key length (128/256)
plus 32 bits of nonce.
This change takes care of the "Invalid key length" errors
reported by setkey when specifying 288 bit keys for aes-ctr.
Signed-off-by: Tushar Gohad <tgohad@mvista.com>
---
net/xfrm/xfrm_algo.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index 58064d9..791ab2e 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -462,8 +462,8 @@ static struct xfrm_algo_desc ealg_list[] = {
.desc = {
.sadb_alg_id = SADB_X_EALG_AESCTR,
.sadb_alg_ivlen = 8,
- .sadb_alg_minbits = 128,
- .sadb_alg_maxbits = 256
+ .sadb_alg_minbits = 160,
+ .sadb_alg_maxbits = 288
}
},
};
--
1.6.3.3.202.g91879
^ permalink raw reply related
* [patch 1/2] MAINTAINERS: orphan FrameRelay DLCI
From: akpm @ 2011-07-28 20:54 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, joe, shemminger
From: Joe Perches <joe@perches.com>
Mike McLagan hasn't contributed in many years and his email bounces.
Signed-off-by: Joe Perches <joe@perches.com>
Cc: David Miller <davem@davemloft.net>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -puN MAINTAINERS~maintainers-orphan-framerelay-dlci MAINTAINERS
--- a/MAINTAINERS~maintainers-orphan-framerelay-dlci
+++ a/MAINTAINERS
@@ -2643,9 +2643,8 @@ S: Maintained
F: arch/x86/math-emu/
FRAME RELAY DLCI/FRAD (Sangoma drivers too)
-M: Mike McLagan <mike.mclagan@linux.org>
L: netdev@vger.kernel.org
-S: Maintained
+S: Orphan
F: drivers/net/wan/dlci.c
F: drivers/net/wan/sdla.c
_
^ 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