I'm currently testing proxmox with kernel 3.10 from pvetest repository.
When trying to use MTU 9000 on my bridged + bonded network interfaces the kernel crashes with the following Call Trace:
Call Trace:
[<ffffffff81612270>] dump_stack+0x19/0x1b
[<ffffffff8160c0ad>] __schedule_bug+0x4d/0x5b
[<ffffffff81617832>] __schedule+0x622/0x7f0
[<ffffffff8109189a>] __cond_resched+0x2a/0x40
[<ffffffff81617a7f>] _cond_resched+0x2f/0x40
[<ffffffff8118e628>] kmem_cache_alloc_node+0x38/0x200
[<ffffffff814e324c>] ? __alloc_skb+0x4c/0x290
[<ffffffff814e324c>] __alloc_skb+0x4c/0x290
[<ffffffff81501122>] rtmsg_ifinfo+0x52/0x100
[<ffffffff815011f1>] rtnetlink_event+0x21/0x40
[<ffffffff8161dbad>] notifier_call_chain+0x4d/0x70
[<ffffffff81088c3e>] __raw_notifier_call_chain+0xe/0x10
[<ffffffff81088c56>] raw_notifier_call_chain+0x16/0x20
[<ffffffff814ec0c6>] call_netdevice_notifiers+0x36/0x60
[<ffffffff814ec286>] netdev_features_change+0x16/0x20
[<ffffffff814f3472>] netdev_update_features+0x22/0x30
[<ffffffffa04d4965>] tg3_change_mtu+0x1e5/0x3e0 [tg3]
[<ffffffff814ec1e8>] dev_set_mtu+0x38/0x90
[<ffffffff8150430c>] dev_ifsioc+0x32c/0x3a0
[<ffffffff81615e7d>] ? mutex_lock+0x1d/0x41
[<ffffffff81504547>] dev_ioctl+0x137/0x550
[<ffffffff814d60fd>] sock_do_ioctl+0x5d/0x70
[<ffffffff814d63e6>] sock_ioctl+0x76/0x2a0
[<ffffffff811bc3c0>] do_vfs_ioctl+0x90/0x530
[<ffffffff811c6d83>] ? __alloc_fd+0xd3/0x120
[<ffffffff811b52a6>] ? final_putname+0x26/0x50
[<ffffffff811bc8f1>] SyS_ioctl+0x91/0xb0
[<ffffffff81622399>] system_call_fastpath+0x16/0x1b
And then CPU goes into lockup.
kernel: [ 124.404951] BUG: soft lockup - CPU#4 stuck for 22s!
Call Trace:
tg3_get_stats64+0x39/0x90 [tg3]
dev_get_stats+0x6e/0x130
bond_get_stats+0xb3/0x1e0 [bonding]
dev_get_stats+0x6e/0x130
dev_seq_printf_stats+0x28/0x100
? mntput_no_expire+0x49/0x130
? mntput+0x26/0x40
dev_seq_show+0x14/0x30
seq_read+0x220/0x380
proc_reg_read+0x3d/0x80
vfs_read+0xa9/0x180
SyS_read+0x52/0xa0
system_call_fastpath+0x16/0x1b
The exact same configuration is working fine in kernel 2.6.
Some googling leads me to this patch which looks very related:
https://lkml.org/lkml/2014/5/11/441
Is this patch incorporated in the 3.10 kernel?
I can find it was added to the 3.13 stable kernel: https://lkml.org/lkml/2014/3/7/56
But I can't find anything about 3.10
When trying to use MTU 9000 on my bridged + bonded network interfaces the kernel crashes with the following Call Trace:
Call Trace:
[<ffffffff81612270>] dump_stack+0x19/0x1b
[<ffffffff8160c0ad>] __schedule_bug+0x4d/0x5b
[<ffffffff81617832>] __schedule+0x622/0x7f0
[<ffffffff8109189a>] __cond_resched+0x2a/0x40
[<ffffffff81617a7f>] _cond_resched+0x2f/0x40
[<ffffffff8118e628>] kmem_cache_alloc_node+0x38/0x200
[<ffffffff814e324c>] ? __alloc_skb+0x4c/0x290
[<ffffffff814e324c>] __alloc_skb+0x4c/0x290
[<ffffffff81501122>] rtmsg_ifinfo+0x52/0x100
[<ffffffff815011f1>] rtnetlink_event+0x21/0x40
[<ffffffff8161dbad>] notifier_call_chain+0x4d/0x70
[<ffffffff81088c3e>] __raw_notifier_call_chain+0xe/0x10
[<ffffffff81088c56>] raw_notifier_call_chain+0x16/0x20
[<ffffffff814ec0c6>] call_netdevice_notifiers+0x36/0x60
[<ffffffff814ec286>] netdev_features_change+0x16/0x20
[<ffffffff814f3472>] netdev_update_features+0x22/0x30
[<ffffffffa04d4965>] tg3_change_mtu+0x1e5/0x3e0 [tg3]
[<ffffffff814ec1e8>] dev_set_mtu+0x38/0x90
[<ffffffff8150430c>] dev_ifsioc+0x32c/0x3a0
[<ffffffff81615e7d>] ? mutex_lock+0x1d/0x41
[<ffffffff81504547>] dev_ioctl+0x137/0x550
[<ffffffff814d60fd>] sock_do_ioctl+0x5d/0x70
[<ffffffff814d63e6>] sock_ioctl+0x76/0x2a0
[<ffffffff811bc3c0>] do_vfs_ioctl+0x90/0x530
[<ffffffff811c6d83>] ? __alloc_fd+0xd3/0x120
[<ffffffff811b52a6>] ? final_putname+0x26/0x50
[<ffffffff811bc8f1>] SyS_ioctl+0x91/0xb0
[<ffffffff81622399>] system_call_fastpath+0x16/0x1b
And then CPU goes into lockup.
kernel: [ 124.404951] BUG: soft lockup - CPU#4 stuck for 22s!
Call Trace:
tg3_get_stats64+0x39/0x90 [tg3]
dev_get_stats+0x6e/0x130
bond_get_stats+0xb3/0x1e0 [bonding]
dev_get_stats+0x6e/0x130
dev_seq_printf_stats+0x28/0x100
? mntput_no_expire+0x49/0x130
? mntput+0x26/0x40
dev_seq_show+0x14/0x30
seq_read+0x220/0x380
proc_reg_read+0x3d/0x80
vfs_read+0xa9/0x180
SyS_read+0x52/0xa0
system_call_fastpath+0x16/0x1b
The exact same configuration is working fine in kernel 2.6.
Some googling leads me to this patch which looks very related:
https://lkml.org/lkml/2014/5/11/441
Is this patch incorporated in the 3.10 kernel?
I can find it was added to the 3.13 stable kernel: https://lkml.org/lkml/2014/3/7/56
But I can't find anything about 3.10