Bug#660425: [squeeze domU] alignment check trap on high network load
Hi,
Radu Spineanu wrote:
> Since a couple of days ago on high loads a domU is constantly
> rebooting itself after a kernel panic.
Sorry to have missed this before. What are the xen and dom0 versions?
How reproducible is this? (100%? 50%?) Can you say a little more
about the nature of the load? Does "dmesg" or "xm dmesg" from the
dom0 say anything interesting when this happens? Is the backtrace
always the same? Which CPU? (A copy of /proc/cpuinfo would be
interesting.) Any other relevant observations?
> [ 58.806593] alignment check: 0000 [#1] SMP
> [ 58.806610] last sysfs file: /sys/module/x_tables/initstate
[...]
> [ 58.806673] RIP: e030:[<ffffffff81270c0b>] [<ffffffff81270c0b>] eth_type_trans+0x3d/0xae
[...]
> [ 58.807061] Code: 87 d8 00 00 00 2b 87 d0 00 00 00 be 0e 00 00 00 89 87 c4 00 00 00 e8 68 48 fe ff 8b 8b c4 00 00 00 48 03 8b d0 00 00 00 f6 01 01 <48> 8b 11 74 20 48 33 95 40 02 00 00 8a 43 7d 48 c1 e2 10 75 08
This trace is of net/ethernet/eth.c, after "eth = eth_hdr(skb);":
10: 89 87 c4 00 00 00 mov %eax,0xc4(%rdi)
16: e8 68 48 fe ff callq 0xfffffffffffe4883
1b: 8b 8b c4 00 00 00 mov 0xc4(%rbx),%ecx
21: 48 03 8b d0 00 00 00 add 0xd0(%rbx),%rcx
28: f6 01 01 testb $0x1,(%rcx)
2b:* 48 8b 11 mov (%rcx),%rdx <-- trapping instruction
2e: 74 20 je 0x50
The "if" is
if (unlikely(is_multicast_ether_addr(eth->h_dest))) {
Linux loads the six bytes of eth->h_dest and two (irrelevant) bytes of
the next field because it will be comparing to another address soon.
The address of *eth (in %rcx) is as well aligned as we could hope
(16-bit aligned).
> [ 58.806690] RSP: e02b:ffff8801cd07f988 EFLAGS: 00050246
> [ 58.806695] RAX: ffff8801fb29ecfc RBX: ffff8801fbb44ce8 RCX: ffff8801fb29ecee
The guest is not supposed to be able to set EFLAGS.AC, so this feels
like a silicon or supervisor bug.
Compare:
http://thread.gmane.org/gmane.comp.emulators.xen.devel/100514
https://bugzilla.kernel.org/show_bug.cgi?id=25182
http://thread.gmane.org/gmane.comp.emulators.xen.devel/80223
Hope that helps,
Jonathan
Reply to: