Sander Eikelenboom
2011-May-20 17:57 UTC
[Xen-devel] 2.6.39 dom0 xen power management test
Hi Konrad / Yu Ke, I have tried konrad''s master tree: commit 329408d788f62629131ea28c112e973878d52c9e Merge: e370fe2 773f8cf Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Thu May 19 14:37:32 2011 -0400 Merge branch ''linux-next'' With a xen-4.1.0 hypervisor, on my AMD x6 phenom. Curious if Xen Power Management would work... Output of all xenpm get* commands is attached, prefix 32 is with a stable working 2.6.32.35 kernel from jeremy''s tree with working xenpm. prefix 39 is with the kernel from the tree mentoined above. There are differences in cpu-idle-states (C0 and C1 state are not reported on .39) and cpu-freq-states/para (which fails entirely on .39) But it doesn''t crash .. just fails .. so that''s positive ! :-) Of course i''m willing to give any more information or test additional patches. Will let it run for the night on 2.6.39 to see how blkback works ! -- Sander _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-May-20 18:09 UTC
[Xen-devel] Re: 2.6.39 dom0 xen power management test
On Fri, May 20, 2011 at 07:57:47PM +0200, Sander Eikelenboom wrote:> Hi Konrad / Yu Ke, > > I have tried konrad''s master tree:Might want to try devel/next-2.6.39. It has the CPU freq and S3 patches in it. I am still working through them, but they do seem to work (I can suspend and resume a machine). The #master has the ones that have been cleaned up and are slowly going to make their path through the maintainers. The ACPI/S#/CPU freq aren''t there yet.> > commit 329408d788f62629131ea28c112e973878d52c9e > Merge: e370fe2 773f8cf > Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Date: Thu May 19 14:37:32 2011 -0400 > > Merge branch ''linux-next'' > > > With a xen-4.1.0 hypervisor, on my AMD x6 phenom. > Curious if Xen Power Management would work... > > Output of all xenpm get* commands is attached, prefix 32 is with a stable working 2.6.32.35 kernel from jeremy''s tree with working xenpm. > prefix 39 is with the kernel from the tree mentoined above. > > There are differences in cpu-idle-states (C0 and C1 state are not reported on .39) > and cpu-freq-states/para (which fails entirely on .39) > > But it doesn''t crash .. just fails .. so that''s positive ! :-)HA!> Of course i''m willing to give any more information or test additional patches. > > > Will let it run for the night on 2.6.39 to see how blkback works !Excellent. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sander Eikelenboom
2011-May-20 22:19 UTC
[Xen-devel] Re: 2.6.39 dom0 xen power management test
Friday, May 20, 2011, 8:09:05 PM, you wrote:> On Fri, May 20, 2011 at 07:57:47PM +0200, Sander Eikelenboom wrote: >> Hi Konrad / Yu Ke, >> >> I have tried konrad''s master tree:> Might want to try devel/next-2.6.39. It has the CPU freq and S3 patches in it. > I am still working through them, but they do seem to work (I can suspend > and resume a machine).> The #master has the ones that have been cleaned up and are slowly going > to make their path through the maintainers. The ACPI/S#/CPU freq aren''t there > yet.how stupid, some how i convinced myself the patches were also in the master branch .. Anyhow, compiled the devel/next-2.6.39 branch .. and everything seems to work OK both blkback and xenpm :-) Time for a goodnight sleep and hope that everything still works in the morning. Thx for the quick pointer to my mistake ! -- Sander>> >> commit 329408d788f62629131ea28c112e973878d52c9e >> Merge: e370fe2 773f8cf >> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> >> Date: Thu May 19 14:37:32 2011 -0400 >> >> Merge branch ''linux-next'' >> >> >> With a xen-4.1.0 hypervisor, on my AMD x6 phenom. >> Curious if Xen Power Management would work... >> >> Output of all xenpm get* commands is attached, prefix 32 is with a stable working 2.6.32.35 kernel from jeremy''s tree with working xenpm. >> prefix 39 is with the kernel from the tree mentoined above. >> >> There are differences in cpu-idle-states (C0 and C1 state are not reported on .39) >> and cpu-freq-states/para (which fails entirely on .39) >> >> But it doesn''t crash .. just fails .. so that''s positive ! :-)> HA! >> Of course i''m willing to give any more information or test additional patches. >> >> >> Will let it run for the night on 2.6.39 to see how blkback works !> Excellent.-- Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sander Eikelenboom
2011-May-21 07:42 UTC
[Xen-devel] Re: 2.6.39 dom0 xen power management test
Hi Konrad, First tests looked good, but tonight after approx. 2 hours after boot the machine crashed. Since my previous setup ran perfectly stable for 55 days, i didn''t have a serial console attached. I shot a photo of what was left onscreen (attached), will attach a serial console later to get it all. -- Sander Friday, May 20, 2011, 8:09:05 PM, you wrote:> On Fri, May 20, 2011 at 07:57:47PM +0200, Sander Eikelenboom wrote: >> Hi Konrad / Yu Ke, >> >> I have tried konrad''s master tree:> Might want to try devel/next-2.6.39. It has the CPU freq and S3 patches in it. > I am still working through them, but they do seem to work (I can suspend > and resume a machine).> The #master has the ones that have been cleaned up and are slowly going > to make their path through the maintainers. The ACPI/S#/CPU freq aren''t there > yet.>> >> commit 329408d788f62629131ea28c112e973878d52c9e >> Merge: e370fe2 773f8cf >> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> >> Date: Thu May 19 14:37:32 2011 -0400 >> >> Merge branch ''linux-next'' >> >> >> With a xen-4.1.0 hypervisor, on my AMD x6 phenom. >> Curious if Xen Power Management would work... >> >> Output of all xenpm get* commands is attached, prefix 32 is with a stable working 2.6.32.35 kernel from jeremy''s tree with working xenpm. >> prefix 39 is with the kernel from the tree mentoined above. >> >> There are differences in cpu-idle-states (C0 and C1 state are not reported on .39) >> and cpu-freq-states/para (which fails entirely on .39) >> >> But it doesn''t crash .. just fails .. so that''s positive ! :-)> HA! >> Of course i''m willing to give any more information or test additional patches. >> >> >> Will let it run for the night on 2.6.39 to see how blkback works !> Excellent.-- Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2011-May-23 11:17 UTC
Re: [Xen-devel] Re: 2.6.39 dom0 xen power management test
On Sat, 21 May 2011, Sander Eikelenboom wrote:> Hi Konrad, > > First tests looked good, but tonight after approx. 2 hours after boot the machine crashed. > Since my previous setup ran perfectly stable for 55 days, i didn''t have a serial console attached. > I shot a photo of what was left onscreen (attached), will attach a serial console later to get it all. >does this patch help? diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 7f676f8..9249ed7 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -1644,7 +1644,7 @@ static struct irq_chip xen_percpu_chip __read_mostly = { .irq_mask = evtchn_noop, .irq_unmask = evtchn_noop, - .irq_ack = ack_dynirq, + .irq_eoi = ack_dynirq, }; int xen_set_callback_via(uint64_t via) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sander Eikelenboom
2011-May-23 11:54 UTC
Re: [Xen-devel] Re: 2.6.39 dom0 xen power management test
Hi Stefano, Will give it a try, but the machine is now running for approx 2 days without hitting it again. So i don''t know how to trigger the problem, and that means i can''t really confirm if the patch helps or not. -- Sander Monday, May 23, 2011, 1:17:07 PM, you wrote:> On Sat, 21 May 2011, Sander Eikelenboom wrote: >> Hi Konrad, >> >> First tests looked good, but tonight after approx. 2 hours after boot the machine crashed. >> Since my previous setup ran perfectly stable for 55 days, i didn''t have a serial console attached. >> I shot a photo of what was left onscreen (attached), will attach a serial console later to get it all. >>> does this patch help?> diff --git a/drivers/xen/events.c b/drivers/xen/events.c > index 7f676f8..9249ed7 100644 > --- a/drivers/xen/events.c > +++ b/drivers/xen/events.c > @@ -1644,7 +1644,7 @@ static struct irq_chip xen_percpu_chip __read_mostly = { > .irq_mask = evtchn_noop, > .irq_unmask = evtchn_noop, > > - .irq_ack = ack_dynirq, > + .irq_eoi = ack_dynirq, > }; > > int xen_set_callback_via(uint64_t via)-- Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sander Eikelenboom
2011-May-23 13:03 UTC
Re: [Xen-devel] Re: 2.6.39 dom0 xen power management test
Monday, May 23, 2011, 1:17:07 PM, you wrote:> On Sat, 21 May 2011, Sander Eikelenboom wrote: >> Hi Konrad, >> >> First tests looked good, but tonight after approx. 2 hours after boot the machine crashed. >> Since my previous setup ran perfectly stable for 55 days, i didn''t have a serial console attached. >> I shot a photo of what was left onscreen (attached), will attach a serial console later to get it all. >>> does this patch help?Nope it doesn''t, right after boot i''m getting: May 23 15:01:02 serveerstertje kernel: [ 361.274781] INFO: task xm:6252 blocked for more than 120 seconds. May 23 15:01:02 serveerstertje kernel: [ 361.275784] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 23 15:01:02 serveerstertje kernel: [ 361.277026] xm D ffff88002fdd7400 0 6252 6242 0x00000000 May 23 15:01:02 serveerstertje kernel: [ 361.278260] ffff8800247c3d58 0000000000000286 000000000000bdb1 0000000000000000 May 23 15:01:02 serveerstertje kernel: [ 361.278701] ffff88002837d580 0000000000013400 ffff8800247c3fd8 ffff8800247c2010 May 23 15:01:02 serveerstertje kernel: [ 361.278701] ffff8800247c3fd8 0000000000013400 ffffffff81fe7020 ffff88002837d580 May 23 15:01:02 serveerstertje kernel: [ 361.278701] Call Trace: May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff81047323>] ? xen_write_msr_safe+0xa3/0xe0 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff8104edaa>] ? __switch_to+0x18a/0x3d0 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff8108fdab>] ? finish_task_switch+0x5b/0xe0 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff81a8860d>] ? schedule+0x44d/0xae0 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff8104c21d>] ? xen_force_evtchn_callback+0xd/0x10 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff8104c9d2>] ? check_events+0x12/0x20 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff81a89445>] schedule_timeout+0x1e5/0x2b0 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff81a8ae30>] ? _raw_spin_unlock_irqrestore+0x30/0x70 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff8108f685>] ? try_to_wake_up+0xc5/0x420 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff81a8905e>] wait_for_common+0xde/0x190 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff8108f9e0>] ? try_to_wake_up+0x420/0x420 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff81a891ed>] wait_for_completion+0x1d/0x20 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff810b31c0>] flush_work+0x30/0x40 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff810b1b60>] ? do_work_for_cpu+0x30/0x30 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff810b4803>] schedule_on_each_cpu+0xc3/0x100 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff811258d5>] lru_add_drain_all+0x15/0x20 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff81141015>] sys_mlock+0x45/0x130 May 23 15:01:02 serveerstertje kernel: [ 361.278701] [<ffffffff81a8bcc2>] system_call_fastpath+0x16/0x1b May 23 15:01:02 serveerstertje kernel: [ 361.278701] INFO: task xm:6278 blocked for more than 120 seconds. May 23 15:01:02 serveerstertje kernel: [ 361.278701] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 23 15:01:02 serveerstertje kernel: [ 361.278701] xm D ffff88002fdd7400 0 6278 6268 0x00000000 May 23 15:01:02 serveerstertje kernel: [ 361.278701] ffff8800258b1d58 0000000000000286 000000000000b8df 0000000000000000 May 23 15:01:02 serveerstertje kernel: [ 361.278701] ffff88002837f200 0000000000013400 ffff8800258b1fd8 ffff8800258b0010 May 23 15:01:02 serveerstertje kernel: [ 361.309209] ffff8800258b1fd8 0000000000013400 ffffffff81fe7020 ffff88002837f200 May 23 15:01:02 serveerstertje kernel: [ 361.309209] Call Trace: May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81047323>] ? xen_write_msr_safe+0xa3/0xe0 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8104edaa>] ? __switch_to+0x18a/0x3d0 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8108fdab>] ? finish_task_switch+0x5b/0xe0 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a8860d>] ? schedule+0x44d/0xae0 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8104c21d>] ? xen_force_evtchn_callback+0xd/0x10 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8104c9d2>] ? check_events+0x12/0x20 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a89445>] schedule_timeout+0x1e5/0x2b0 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a8ae30>] ? _raw_spin_unlock_irqrestore+0x30/0x70 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8108f685>] ? try_to_wake_up+0xc5/0x420 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a8905e>] wait_for_common+0xde/0x190 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8108f9e0>] ? try_to_wake_up+0x420/0x420 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a891ed>] wait_for_completion+0x1d/0x20 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff810b31c0>] flush_work+0x30/0x40 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff810b1b60>] ? do_work_for_cpu+0x30/0x30 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff810b4803>] schedule_on_each_cpu+0xc3/0x100 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff811258d5>] lru_add_drain_all+0x15/0x20 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81141015>] sys_mlock+0x45/0x130 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a8bcc2>] system_call_fastpath+0x16/0x1b May 23 15:01:02 serveerstertje kernel: [ 361.309209] INFO: task xentop:6287 blocked for more than 120 seconds. May 23 15:01:02 serveerstertje kernel: [ 361.309209] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 23 15:01:02 serveerstertje kernel: [ 361.309209] xentop D ffff88002fdd7400 0 6287 1 0x00000004 May 23 15:01:02 serveerstertje kernel: [ 361.309209] ffff880025d1dd58 0000000000000282 0000000000000000 0000000000000000 May 23 15:01:02 serveerstertje kernel: [ 361.309209] ffff880029d65580 0000000000013400 ffff880025d1dfd8 ffff880025d1c010 May 23 15:01:02 serveerstertje kernel: [ 361.309209] ffff880025d1dfd8 0000000000013400 ffffffff81fe7020 ffff880029d65580 May 23 15:01:02 serveerstertje kernel: [ 361.309209] Call Trace: May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81047323>] ? xen_write_msr_safe+0xa3/0xe0 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8104edaa>] ? __switch_to+0x18a/0x3d0 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8108fdab>] ? finish_task_switch+0x5b/0xe0 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a8860d>] ? schedule+0x44d/0xae0 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8104c21d>] ? xen_force_evtchn_callback+0xd/0x10 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8104c9d2>] ? check_events+0x12/0x20 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a89445>] schedule_timeout+0x1e5/0x2b0 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a8ae30>] ? _raw_spin_unlock_irqrestore+0x30/0x70 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8108f685>] ? try_to_wake_up+0xc5/0x420 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a8905e>] wait_for_common+0xde/0x190 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff8108f9e0>] ? try_to_wake_up+0x420/0x420 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a891ed>] wait_for_completion+0x1d/0x20 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff810b31c0>] flush_work+0x30/0x40 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff810b1b60>] ? do_work_for_cpu+0x30/0x30 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff810b4803>] schedule_on_each_cpu+0xc3/0x100 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff811258d5>] lru_add_drain_all+0x15/0x20 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81141015>] sys_mlock+0x45/0x130 May 23 15:01:02 serveerstertje kernel: [ 361.309209] [<ffffffff81a8bcc2>] system_call_fastpath+0x16/0x1b> diff --git a/drivers/xen/events.c b/drivers/xen/events.c > index 7f676f8..9249ed7 100644 > --- a/drivers/xen/events.c > +++ b/drivers/xen/events.c > @@ -1644,7 +1644,7 @@ static struct irq_chip xen_percpu_chip __read_mostly = { > .irq_mask = evtchn_noop, > .irq_unmask = evtchn_noop, > > - .irq_ack = ack_dynirq, > + .irq_eoi = ack_dynirq, > }; > > int xen_set_callback_via(uint64_t via)-- Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2011-May-23 13:59 UTC
Re: [Xen-devel] Re: 2.6.39 dom0 xen power management test
On Mon, 23 May 2011, Sander Eikelenboom wrote:> Monday, May 23, 2011, 1:17:07 PM, you wrote: > > > On Sat, 21 May 2011, Sander Eikelenboom wrote: > >> Hi Konrad, > >> > >> First tests looked good, but tonight after approx. 2 hours after boot the machine crashed. > >> Since my previous setup ran perfectly stable for 55 days, i didn''t have a serial console attached. > >> I shot a photo of what was left onscreen (attached), will attach a serial console later to get it all. > >> > > > does this patch help? > > Nope it doesn''t, right after boot i''m getting:Sorry after reading more carefully your problem and it is clear that the patch was a bad idea. Could you please resolve the RIP of the crash with the previous build (ffffffff810e5464 from the pic you posted before)? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sander Eikelenboom
2011-May-23 14:55 UTC
Re: [Xen-devel] Re: 2.6.39 dom0 xen power management test
Hmm i had to rebuild the kernel, but although i used the exact same config gdb can''t find it: serveerstertje:~# gdb vmlinux GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /root/vmlinux...done. (gdb) x/i ffffffff810e5464 No symbol "ffffffff810e5464" in current context. Monday, May 23, 2011, 3:59:04 PM, you wrote:> On Mon, 23 May 2011, Sander Eikelenboom wrote: >> Monday, May 23, 2011, 1:17:07 PM, you wrote: >> >> > On Sat, 21 May 2011, Sander Eikelenboom wrote: >> >> Hi Konrad, >> >> >> >> First tests looked good, but tonight after approx. 2 hours after boot the machine crashed. >> >> Since my previous setup ran perfectly stable for 55 days, i didn''t have a serial console attached. >> >> I shot a photo of what was left onscreen (attached), will attach a serial console later to get it all. >> >> >> >> > does this patch help? >> >> Nope it doesn''t, right after boot i''m getting:> Sorry after reading more carefully your problem and it is clear that the > patch was a bad idea.> Could you please resolve the RIP of the crash with the previous build > (ffffffff810e5464 from the pic you posted before)?-- Best regards, Sander mailto:linux@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Seemingly Similar Threads
- [ 3009.778974] mcelog:16842 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
- [PATCH] amd iommu: Dump flags of IO page faults
- pv_ops DomU boot problem using pvgrub, xen 3.4.1-rc7, debian 2.6.26 dom0
- xen-unstable: commit commit 63753b3e0dc56efb1acf94fa46f3fee7bc59281c leaves HVM guest dangling after shutdown or destroy.
- IOMMU and AMD 890fx