From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Natalie Protasevich <protasnb@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Alignment check on domU (2.6.32)
Date: Tue, 30 Mar 2010 09:53:49 -0700 [thread overview]
Message-ID: <4BB22C9D.7030502@goop.org> (raw)
In-Reply-To: <32209efe1003292008y5880e9bfib238c089377b4ba7@mail.gmail.com>
On 03/29/2010 08:08 PM, Natalie Protasevich wrote:
> Hello,
> We are getting alignment check with 2.6.32 kernel running as a domU on
> an AMD system,
Which 2.6.32 is it? Is it stock kernel.org, from xen.git, a distro,
elsewhere?
> while dom0 is a 2.6.18 kernel.
> As far as I know we should not have run into such problem, since this
> is x86_64 kernel. I am aware of the fact that for alignment check trap
> AC bit needs to be set in eflags and AM should be set in CR0. I
> tracked cr0 and AM was getting set, and problem was occurring when
> something was setting AC flag at the time of calling memcpy_c(). I
> cheated and cleared the AM flag in cr0 (as one can see in this trace)
> but this didn't help. I haven't figured out what sets the AM flag...
Do you have any other domains running at the time?
What CPU is this?
Does it run the same kernel native OK?
J
>
> Here is the trace:
>
> [ 80.342300] alignment check: 0000 [#1] SMP
> [ 80.342323] last sysfs file: /sys/devices/virtual/vc/vcsa7/dev
> [ 80.342330] CPU 1
> [ 80.342339] Pid: 3875, comm: loas_check Not tainted
> 2.6.32.10+drm33.1 #12
> [ 80.342347] RIP: e030:[<ffffffff813eb2bb>] [<ffffffff813eb2bb>]
> memcpy_c+0xb/0x20
> [ 80.342365] RSP: e02b:ffff88015556d9b0 EFLAGS: 00050246
> [ 80.342371] RAX: ffff88017360cc8c RBX: ffff880176d91900 RCX:
> 0000000000000002
> [ 80.342379] RDX: 0000000000000000 RSI: ffff880176d91958 RDI:
> ffff88017360cc8c
> [ 80.342388] RBP: ffff88015556d9e8 R08: ffffffff81570260 R09:
> ffffffff81ae8840
> [ 80.342395] R10: 0000000000000000 R11: 0000000000000000 R12:
> 0000000000000000
> [ 80.342403] R13: 000000000000000e R14: ffff880173f3fc00 R15:
> ffff880176d91958
> [ 80.342417] FS: 00007f0f4dafd6e0(0000) GS:ffff880028047000(0000)
> knlGS:0000000000000000
> [ 80.342425] CS: e033 DS: 002b ES: 002b CR0: 000000008001003b
> [ 80.342432] CR2: 00007f0f4db1a000 CR3: 000000017362d000 CR4:
> 0000000000000660
> [ 80.342440] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 80.342448] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000000
> [ 80.342457] Process loas_check (pid: 3875, threadinfo
> ffff88015556c000, task ffff8801556cada0)
> [ 80.342465] Stack:
> [ 80.342469] ffffffff8157038f ffffffff81ae8840 ffff880173f3fc00
> 0000000000000000
> [ 80.342483] <0> ffff880173f3fc00 ffff880161a36400 0000000000000000
> ffff88015556da08
> [ 80.342500] <0> ffffffff815705d6 ffff880180000000 ffff880173f3fc00
> ffff88015556da28
> [ 80.342518] Call Trace:
> [ 80.342528] [<ffffffff8157038f>] ? ip_finish_output+0x12f/0x2f0
> [ 80.342538] [<ffffffff815705d6>] ip_output+0x86/0xd0
> [ 80.342546] [<ffffffff8156f600>] ip_local_out+0x20/0x30
> [ 80.342555] [<ffffffff8156fed3>] ip_queue_xmit+0x223/0x3f0
> [ 80.342565] [<ffffffff81584214>] ? tcp_send_active_reset+0x24/0x180
> [ 80.342576] [<ffffffff8100dcfd>] ? xen_force_evtchn_callback+0xd/0x10
> [ 80.342586] [<ffffffff8100e532>] ? check_events+0x12/0x20
> [ 80.342595] [<ffffffff81583dd2>] tcp_transmit_skb+0x402/0x780
> [ 80.342604] [<ffffffff81584279>] tcp_send_active_reset+0x89/0x180
> [ 80.342614] [<ffffffff815770bc>] tcp_disconnect+0x6c/0x3c0
> [ 80.342622] [<ffffffff81576e34>] tcp_close+0x3e4/0x480
> [ 80.342632] [<ffffffff81598b92>] inet_release+0x42/0x70
> [ 80.342643] [<ffffffff814ce5d8>] sock_release+0x18/0x60
> [ 80.342652] [<ffffffff814ceab2>] sock_close+0x12/0x30
> [ 80.342663] [<ffffffff8110e28e>] __fput+0xee/0x200
> [ 80.342671] [<ffffffff8100dcfd>] ? xen_force_evtchn_callback+0xd/0x10
> [ 80.342681] [<ffffffff8110e3b7>] fput+0x17/0x20
> [ 80.342690] [<ffffffff8110a378>] filp_close+0x58/0x90
> [ 80.342698] [<ffffffff8100e51f>] ? xen_restore_fl_direct_end+0x0/0x1
> [ 80.342709] [<ffffffff8105691c>] put_files_struct+0xcc/0xe0
> [ 80.342718] [<ffffffff81056980>] exit_files+0x50/0x60
> [ 80.342726] [<ffffffff81058587>] do_exit+0x1b7/0x7f0
> [ 80.342735] [<ffffffff81065cb6>] ? __dequeue_signal+0x16/0x160
> [ 80.342745] [<ffffffff81058bfc>] do_group_exit+0x3c/0xa0
> [ 80.342754] [<ffffffff81068328>] get_signal_to_deliver+0x1b8/0x380
> [ 80.342764] [<ffffffff810106a9>] do_notify_resume+0xc9/0x8a0
> [ 80.342775] [<ffffffff8100b8bb>] ? xen_mc_flush+0x11b/0x1d0
> [ 80.342786] [<ffffffff8102cb52>] ?
> paravirt_end_context_switch+0x12/0x30
> [ 80.342798] [<ffffffff81047afb>] ? finish_task_switch+0x5b/0xb0
> [ 80.342808] [<ffffffff8101134e>] int_signal+0x12/0x17
> [ 80.342815] Code: 81 ea d8 1f 00 00 48 3b 42 20 73 07 48 8b 50 f9
> 31 c0 c3 31 d2 48 c7 c0 f2 ff ff ff c3 90 90 90 48 89 f8 89 d1 c1 e9
> 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 66 66 66 2e 0f 1f 84 00 00 00
> 00 00
> [ 80.342952] RIP [<ffffffff813eb2bb>] memcpy_c+0xb/0x20
> [ 80.342962] RSP <ffff88015556d9b0>
> [ 80.342969] ---[ end trace 1442aa6e9e3d337d ]---
> [ 80.342976] Fixing recursive fault but reboot is needed!
>
> This happens 2 out of 3 times.
> I don't seem to find any similar recent reports and relevant commits
> so far, and we haven't had such problem running 2.6.24 domU (Ubuntu
> hardy) on the 2.6.18 dom0. I'm hoping someone can give a hand.
> Thanks,
> --Natalie
> P.S. Just in case - here is the "original" trace before I tried to
> modify the cr0:
>
> [ 64.544616] alignment check: 0000 [#1] SMP
> [ 64.544640] last sysfs file: /sys/devices/virtual/vc/vcsa7/dev
> [ 64.544647] CPU 1
> [ 64.544655] Pid: 3737, comm: loas_check Not tainted
> 2.6.32.10+drm33.1 #8
> [ 64.544663] RIP: e030:[<ffffffff813eb23b>] [<ffffffff813eb23b>]
> memcpy_c+0xb/0x20
> [ 64.544681] RSP: e02b:ffff880152e7d9b0 EFLAGS: 00050246
> [ 64.544687] RAX: ffff8801731e4c8c RBX: ffff880178185400 RCX:
> 0000000000000002
> [ 64.544696] RDX: 0000000000000000 RSI: ffff880178185458 RDI:
> ffff8801731e4c8c
> [ 64.544703] RBP: ffff880152e7d9e8 R08: ffffffff81570110 R09:
> ffffffff81ae6840
> [ 64.544711] R10: 0000000000000000 R11: 0000000000000000 R12:
> 0000000000000000
> [ 64.544718] R13: 000000000000000e R14: ffff88017332d800 R15:
> ffff880178185458
> [ 64.544732] FS: 00007fa8de9336e0(0000) GS:ffff880028047000(0000)
> knlGS:0000000000000000
> [ 64.544741] CS: e033 DS: 002b ES: 002b CR0: 000000008005003b
> [ 64.544748] CR2: 00000000081f1320 CR3: 0000000001001000 CR4:
> 0000000000000660
> [ 64.544756] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 64.544764] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000000
> [ 64.544772] Process loas_check (pid: 3737, threadinfo
> ffff880152e7c000, task ffff880152e72da0)
> [ 64.544781] Stack:
> [ 64.544785] ffffffff81570214 ffffffff81ae6840 ffff88017332d800
> 0000000000000000
> [ 64.544798] <0> ffff88017332d800 ffff880152e13200 0000000000000000
> ffff880152e7da08
> [ 64.544814] <0> ffffffff81570486 ffff880180000000 ffff88017332d800
> ffff880152e7da28
> [ 64.544832] Call Trace:
> [ 64.544842] [<ffffffff81570214>] ? ip_finish_output+0x104/0x2f0
> [ 64.544853] [<ffffffff81570486>] ip_output+0x86/0xd0
> [ 64.544862] [<ffffffff8156f4b0>] ip_local_out+0x20/0x30
> [ 64.544870] [<ffffffff8156fd83>] ip_queue_xmit+0x223/0x3f0
> [ 64.544880] [<ffffffff8100dcfd>] ? xen_force_evtchn_callback+0xd/0x10
> [ 64.544889] [<ffffffff8100e532>] ? check_events+0x12/0x20
> [ 64.544900] [<ffffffff81583c82>] tcp_transmit_skb+0x402/0x780
> [ 64.544909] [<ffffffff81584129>] tcp_send_active_reset+0x89/0x180
> [ 64.544920] [<ffffffff8111e16a>] ? __d_free+0x3a/0x60
> [ 64.544929] [<ffffffff81576f6c>] tcp_disconnect+0x6c/0x3c0
> [ 64.544938] [<ffffffff81576ce4>] tcp_close+0x3e4/0x480
> [ 64.544946] [<ffffffff81598a42>] inet_release+0x42/0x70
> [ 64.544956] [<ffffffff814ce558>] sock_release+0x18/0x60
> [ 64.544964] [<ffffffff814cea32>] sock_close+0x12/0x30
> [ 64.544974] [<ffffffff8110e20e>] __fput+0xee/0x200
> [ 64.544982] [<ffffffff8100dcfd>] ? xen_force_evtchn_callback+0xd/0x10
> [ 64.544991] [<ffffffff8110e337>] fput+0x17/0x20
> [ 64.545000] [<ffffffff8110a2f8>] filp_close+0x58/0x90
> [ 64.545009] [<ffffffff8100e51f>] ? xen_restore_fl_direct_end+0x0/0x1
> [ 64.545019] [<ffffffff8105689c>] put_files_struct+0xcc/0xe0
> [ 64.545028] [<ffffffff81056900>] exit_files+0x50/0x60
> [ 64.545036] [<ffffffff81058507>] do_exit+0x1b7/0x7f0
> [ 64.545046] [<ffffffff81065c36>] ? __dequeue_signal+0x16/0x160
> [ 64.545055] [<ffffffff81058b7c>] do_group_exit+0x3c/0xa0
> [ 64.545064] [<ffffffff810682a8>] get_signal_to_deliver+0x1b8/0x380
> [ 64.545073] [<ffffffff81010649>] do_notify_resume+0xc9/0x880
> [ 64.545084] [<ffffffff8100b8bb>] ? xen_mc_flush+0x11b/0x1d0
> [ 64.545095] [<ffffffff8102cad2>] ?
> paravirt_end_context_switch+0x12/0x30
> [ 64.545106] [<ffffffff81047a7b>] ? finish_task_switch+0x5b/0xb0
> [ 64.545115] [<ffffffff810112ce>] int_signal+0x12/0x17
> [ 64.545121] Code: 81 ea d8 1f 00 00 48 3b 42 20 73 07 48 8b 50 f9
> 31 c0 c3 31 d2 48 c7 c0 f2 ff ff ff c3 90 90 90 48 89 f8 89 d1 c1 e9
> 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 66 66 66 2e 0f 1f 84 00 00 00
> 00 00
> [ 64.545252] RIP [<ffffffff813eb23b>] memcpy_c+0xb/0x20
> [ 64.545262] RSP <ffff880152e7d9b0>
> [ 64.545269] ---[ end trace 11cf940a2c626919 ]---
> [ 64.545276] Fixing recursive fault but reboot is needed!
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
next prev parent reply other threads:[~2010-03-30 16:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-30 3:08 Alignment check on domU (2.6.32) Natalie Protasevich
2010-03-30 8:06 ` Jan Beulich
2010-03-30 11:34 ` Natalie Protasevich
2010-03-30 16:53 ` Jeremy Fitzhardinge [this message]
2010-03-30 17:32 ` Natalie Protasevich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BB22C9D.7030502@goop.org \
--to=jeremy@goop.org \
--cc=protasnb@gmail.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.