All of lore.kernel.org
 help / color / mirror / Atom feed
* AMD GPU passthrough in Xen
@ 2014-09-22 12:16 Peter Kay
  2014-09-22 12:38 ` Sander Eikelenboom
  0 siblings, 1 reply; 17+ messages in thread
From: Peter Kay @ 2014-09-22 12:16 UTC (permalink / raw)
  To: xen-devel; +Cc: kelly.zytaruk

Hi Kelly, list

I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9. I've been less than successful getting passthrough working at all in Xen (although it's fine in KVM primary passthrough as long as the BIOS is supplied as a file). Could I confirm the following :

Is there any specific reason you're using Xen 4.2 rather than 4.4.1? I know in some ways 4.4 suffers as it's now xl only and some of the xm functionality has not come across.

In 4.2, using xl or xm?

Primary or secondary passthrough?

Presumably 64 bit versions of Windows?

My system is a bit old (Core2Quad) but as mentioned AMD passthrough works in KVM but I've found it tricky in Xen.

I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.

Thanks

Peter

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-22 12:16 AMD GPU passthrough in Xen Peter Kay
@ 2014-09-22 12:38 ` Sander Eikelenboom
  2014-09-22 14:31   ` Peter Kay
  2014-09-23 13:19   ` Zytaruk, Kelly
  0 siblings, 2 replies; 17+ messages in thread
From: Sander Eikelenboom @ 2014-09-22 12:38 UTC (permalink / raw)
  To: Peter Kay; +Cc: kelly.zytaruk, xen-devel


Monday, September 22, 2014, 2:16:58 PM, you wrote:

> Hi Kelly, list

> I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9. I've been less than successful getting passthrough working at all in Xen (although it's fine in KVM primary passthrough as long as the BIOS is supplied as a file). Could I confirm the following :

> Is there any specific reason you're using Xen 4.2 rather than 4.4.1? I know in some ways 4.4 suffers as it's now xl only and some of the xm functionality has not come across.

> In 4.2, using xl or xm?

Another interesting question/aspect would be qemu-traditional (with rombios) or 
"upstream" (with seabios) ? 

> Primary or secondary passthrough?

> Presumably 64 bit versions of Windows?

> My system is a bit old (Core2Quad) but as mentioned AMD passthrough works in KVM but I've found it tricky in Xen.

> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.

> Thanks

> Peter

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-22 12:38 ` Sander Eikelenboom
@ 2014-09-22 14:31   ` Peter Kay
  2014-09-22 15:05     ` Gordan Bobic
  2014-09-23 13:19   ` Zytaruk, Kelly
  1 sibling, 1 reply; 17+ messages in thread
From: Peter Kay @ 2014-09-22 14:31 UTC (permalink / raw)
  To: Sander Eikelenboom; +Cc: kelly.zytaruk, xen-devel



On 22 September 2014 13:38:28 BST, Sander Eikelenboom <linux@eikelenboom.it> wrote:

>Another interesting question/aspect would be qemu-traditional (with
>rombios) or 
>"upstream" (with seabios) ? 
Point, although I didn't think this was generally an option in 4.2?

Certainly I've found upstream to be functional (using a Quadro), but a less stable domU overall

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-22 14:31   ` Peter Kay
@ 2014-09-22 15:05     ` Gordan Bobic
  2014-09-23 11:22       ` Peter Kay
  0 siblings, 1 reply; 17+ messages in thread
From: Gordan Bobic @ 2014-09-22 15:05 UTC (permalink / raw)
  To: Peter Kay; +Cc: xen-devel

On 09/22/2014 03:31 PM, Peter Kay wrote:
>
>
> On 22 September 2014 13:38:28 BST, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>
>> Another interesting question/aspect would be qemu-traditional (with
>> rombios) or
>> "upstream" (with seabios) ?
> Point, although I didn't think this was generally an option in 4.2?
>
> Certainly I've found upstream to be functional (using a Quadro), but a less stable domU overall

Do you happen to know if the recent KVM/QEMU provides a feature to limit 
the amount of memory below 4GB to assign to the guest? Or provide a 
custom e820 map? To work around a hardware bug I have to somehow make 
sure that everything between 2.5GB and 4GB is reserved and untouchable.

Gordan

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-22 15:05     ` Gordan Bobic
@ 2014-09-23 11:22       ` Peter Kay
  0 siblings, 0 replies; 17+ messages in thread
From: Peter Kay @ 2014-09-23 11:22 UTC (permalink / raw)
  To: Gordan Bobic; +Cc: xen-devel

   

On 22 September 2014 16:05:41 BST, Gordan Bobic <gordan@bobich.net> wrote:
>On 09/22/2014 03:31 PM, Peter Kay wrote:

>Do you happen to know if the recent KVM/QEMU provides a feature to
>limit 
>the amount of memory below 4GB to assign to the guest? Or provide a 
>custom e820 map? To work around a hardware bug I have to somehow make 
>sure that everything between 2.5GB and 4GB is reserved and untouchable.
KVM/Qemu,
I haven't done it myself, but Qemu supports the -smbios parameter to read ACPI tables. These may have to be packed. Both Qemu and KVM seem to have APIs to modify e820.

It's probably worth trying without any modifications on the latest Linux kernel, as KVM is (to my mind) best thought of as a KVM accelerator and VFIO does all the neat stuff (I.e. qemu can be run with passthrough without kvm acceleration). It might just work...

I see xc_reserved_device_memory_map has recently been submitted for xen? It's a very new set of patches though and I can't seem to see it in the source tree. It's slated for inclusion in 4.5 release, written by Tiejun Chen

PK
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-22 12:38 ` Sander Eikelenboom
  2014-09-22 14:31   ` Peter Kay
@ 2014-09-23 13:19   ` Zytaruk, Kelly
  2014-09-23 13:45     ` Sander Eikelenboom
  1 sibling, 1 reply; 17+ messages in thread
From: Zytaruk, Kelly @ 2014-09-23 13:19 UTC (permalink / raw)
  To: Sander Eikelenboom, Peter Kay; +Cc: xen-devel

Hi Peter / Sander,

Yes, I have AMD GPU passthru working as both primary and secondary passthru.  Secondary was easy but primary is a bit tricky.  

Getting on to your questions;

> Is there any specific reason you're using Xen 4.2 rather than 4.4.1?

I am working on a project that is based on Xen 4.2 (I can't say any more than that).  I have looked at some of the more recent versions just to check if some of the bugs that I have seen have been fixed but I have not studied the newer versions in detail.  At some point in time in the future I would like will make the jump to a more recent version but I don't know the scheduling of that.

> In 4.2, using xl or xm?

xl

> qemu-traditional (with rombios) or "upstream"

qemu-traditional

> Primary or secondary passthrough?

Both but I am focusing on secondary right now.

> Presumably 64 bit versions of Windows?

32 bit and 64 bit Win7.  I have tested Win8.1 and it works but my focus is currently Win7

> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.

Awesome.  My goal right now is obtaining stability on Xen 4.2.  Since 4.2 is past its feature cutoff I won't be able to submit any open source changes for it.  I would like to eventually work with the community to get passthru working with a recent version of "upstream".  

Thanks,
Kelly



> -----Original Message-----
> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> Sent: Monday, September 22, 2014 8:38 AM
> To: Peter Kay
> Cc: xen-devel@lists.xen.org; Zytaruk, Kelly
> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> 
> 
> Monday, September 22, 2014, 2:16:58 PM, you wrote:
> 
> > Hi Kelly, list
> 
> > I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9. I've been
> less than successful getting passthrough working at all in Xen (although it's fine
> in KVM primary passthrough as long as the BIOS is supplied as a file). Could I
> confirm the following :
> 
> > Is there any specific reason you're using Xen 4.2 rather than 4.4.1? I know in
> some ways 4.4 suffers as it's now xl only and some of the xm functionality has
> not come across.
> 
> > In 4.2, using xl or xm?
> 
> Another interesting question/aspect would be qemu-traditional (with rombios)
> or "upstream" (with seabios) ?
> 
> > Primary or secondary passthrough?
> 
> > Presumably 64 bit versions of Windows?
> 
> > My system is a bit old (Core2Quad) but as mentioned AMD passthrough works
> in KVM but I've found it tricky in Xen.
> 
> > I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
> 
> > Thanks
> 
> > Peter
> 
> 

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-23 13:19   ` Zytaruk, Kelly
@ 2014-09-23 13:45     ` Sander Eikelenboom
  2014-09-23 14:44       ` Gordan Bobic
  2014-09-24 12:12       ` Zytaruk, Kelly
  0 siblings, 2 replies; 17+ messages in thread
From: Sander Eikelenboom @ 2014-09-23 13:45 UTC (permalink / raw)
  To: Zytaruk, Kelly; +Cc: xen-devel, Peter Kay

Good to know there is interest from AMD into this area :-)

I'm experimenting for a while with:

- xen-unstable (and thus xl)
- latest kernels (both dom0 and domU)
- qemu-xen 
- Radeon HD 6570
- secondary passthrough
- Debian linux (sid) with the opensource (in kernel) radeon driver
  (i also tried fglrx with succes, but it's a real PITA to build with every 
  new kernel, so i ditched that)

It used to work, but something broke at the moment, but that could also be the 
changes to the systemd cruft that Debian jessie/sid is currently undergoing (or 
something else since i regularly update all components).

The problems are mostly with restarting the domU, it differs a bit:
- sometimes screen goes ok, sometimes it's garbage. 
- the radeon powercontrols only seem to work on the first boot and give errors on any subsequent one.

But when it works it does:
- the powercontrol.
- opengl and opencl benchmarks with (near) native results.
- hardware video acceleration in xbmc for instance.

So one of the main problems at present seems to be proper resetting of the whole 
device on domain shutdown/start. I did do some experiments with the opensource 
radeon driver, but didn't get conclusive results out of that yet.

--
Sander

Tuesday, September 23, 2014, 3:19:41 PM, you wrote:

> Hi Peter / Sander,

> Yes, I have AMD GPU passthru working as both primary and secondary passthru.  Secondary was easy but primary is a bit tricky.  

> Getting on to your questions;

>> Is there any specific reason you're using Xen 4.2 rather than 4.4.1?

> I am working on a project that is based on Xen 4.2 (I can't say any more than that).  I have looked at some of the more recent versions just to check if some of the bugs that I have seen have been fixed but I have not studied the newer versions in detail.  At some point in time in the future I would like will make the jump to a more recent version but I don't know the scheduling of that.

>> In 4.2, using xl or xm?

> xl

>> qemu-traditional (with rombios) or "upstream"

> qemu-traditional

>> Primary or secondary passthrough?

> Both but I am focusing on secondary right now.

>> Presumably 64 bit versions of Windows?

> 32 bit and 64 bit Win7.  I have tested Win8.1 and it works but my focus is currently Win7

>> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.

> Awesome.  My goal right now is obtaining stability on Xen 4.2.  Since 4.2 is past its feature cutoff I won't be able to submit any open source changes for it.  I would like to eventually work with the community to get passthru working with a recent version of "upstream".  

> Thanks,
> Kelly



>> -----Original Message-----
>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> Sent: Monday, September 22, 2014 8:38 AM
>> To: Peter Kay
>> Cc: xen-devel@lists.xen.org; Zytaruk, Kelly
>> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> 
>> 
>> Monday, September 22, 2014, 2:16:58 PM, you wrote:
>> 
>> > Hi Kelly, list
>> 
>> > I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9. I've been
>> less than successful getting passthrough working at all in Xen (although it's fine
>> in KVM primary passthrough as long as the BIOS is supplied as a file). Could I
>> confirm the following :
>> 
>> > Is there any specific reason you're using Xen 4.2 rather than 4.4.1? I know in
>> some ways 4.4 suffers as it's now xl only and some of the xm functionality has
>> not come across.
>> 
>> > In 4.2, using xl or xm?
>> 
>> Another interesting question/aspect would be qemu-traditional (with rombios)
>> or "upstream" (with seabios) ?
>> 
>> > Primary or secondary passthrough?
>> 
>> > Presumably 64 bit versions of Windows?
>> 
>> > My system is a bit old (Core2Quad) but as mentioned AMD passthrough works
>> in KVM but I've found it tricky in Xen.
>> 
>> > I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
>> 
>> > Thanks
>> 
>> > Peter
>> 
>> 

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-23 13:45     ` Sander Eikelenboom
@ 2014-09-23 14:44       ` Gordan Bobic
  2014-09-24 12:12       ` Zytaruk, Kelly
  1 sibling, 0 replies; 17+ messages in thread
From: Gordan Bobic @ 2014-09-23 14:44 UTC (permalink / raw)
  To: xen-devel

On 2014-09-23 14:45, Sander Eikelenboom wrote:
> Good to know there is interest from AMD into this area :-)
> 
> I'm experimenting for a while with:
> 
> - xen-unstable (and thus xl)
> - latest kernels (both dom0 and domU)
> - qemu-xen
> - Radeon HD 6570
> - secondary passthrough
> - Debian linux (sid) with the opensource (in kernel) radeon driver
>   (i also tried fglrx with succes, but it's a real PITA to build with 
> every
>   new kernel, so i ditched that)
> 
> It used to work, but something broke at the moment, but that could also 
> be the
> changes to the systemd cruft that Debian jessie/sid is currently 
> undergoing (or
> something else since i regularly update all components).
> 
> The problems are mostly with restarting the domU, it differs a bit:
> - sometimes screen goes ok, sometimes it's garbage.
> - the radeon powercontrols only seem to work on the first boot and
> give errors on any subsequent one.
> 
> But when it works it does:
> - the powercontrol.
> - opengl and opencl benchmarks with (near) native results.
> - hardware video acceleration in xbmc for instance.
> 
> So one of the main problems at present seems to be proper resetting of
> the whole
> device on domain shutdown/start. I did do some experiments with the 
> opensource
> radeon driver, but didn't get conclusive results out of that yet.

Interestingly, on my machine this seems to be down to the lack of
reset knowledge on part of xen-pciback. In dom0:

# lspci -nn | grep ATI
0e:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Caicos [Radeon HD 6450/7450/8450] [1002:6779]
0e:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] 
Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98]

# ls -la 
/sys/devices/pci0000:00/0000:00:03.0/0000:0a:00.0/0000:0b:00.0/0000:0e:00.0/reset
--w------- 1 root root 4096 Sep 23 15:39 
/sys/devices/pci0000:00/0000:00:03.0/0000:0a:00.0/0000:0b:00.0/0000:0e:00.0/reset

# cat 
/sys/devices/pci0000:00/0000:00:03.0/0000:0a:00.0/0000:0b:00.0/0000:0e:00.0/d3cold_allowed
1

# uname -a
Linux normandy 3.14.12-1.el6xen.x86_64 #1 SMP Fri Jul 11 19:30:39 EST 
2014 x86_64 x86_64 x86_64 GNU/Linux

But IIRC if I unbind the radeon (open source) driver and bind
xen-pciback to the device, the reset node disappears (not in a
position to try it right now).

Gordan

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-23 13:45     ` Sander Eikelenboom
  2014-09-23 14:44       ` Gordan Bobic
@ 2014-09-24 12:12       ` Zytaruk, Kelly
  2014-09-24 12:56         ` Gordan Bobic
  2014-09-24 13:21         ` Sander Eikelenboom
  1 sibling, 2 replies; 17+ messages in thread
From: Zytaruk, Kelly @ 2014-09-24 12:12 UTC (permalink / raw)
  To: Sander Eikelenboom; +Cc: Gordan Bobic, xen-devel, Peter Kay

> Good to know there is interest from AMD into this area :-)

I am taking a personal interest in this and would like to improve AMD support and presence within the Xen community.

Gordan has also reported problems restarting a guest.  

I have been trying to reproduce the problem but have not had any luck.  As a secondary it restarts for me every time.  I don't know if I inadvertently made a change that indirectly fixed it in my code base or what the difference might be.

What Xen version are you testing with?

Thanks,
Kelly

> -----Original Message-----
> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> Sent: Tuesday, September 23, 2014 9:45 AM
> To: Zytaruk, Kelly
> Cc: Peter Kay; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> 
> Good to know there is interest from AMD into this area :-)
> 
> I'm experimenting for a while with:
> 
> - xen-unstable (and thus xl)
> - latest kernels (both dom0 and domU)
> - qemu-xen
> - Radeon HD 6570
> - secondary passthrough
> - Debian linux (sid) with the opensource (in kernel) radeon driver
>   (i also tried fglrx with succes, but it's a real PITA to build with every
>   new kernel, so i ditched that)
> 
> It used to work, but something broke at the moment, but that could also be the
> changes to the systemd cruft that Debian jessie/sid is currently undergoing (or
> something else since i regularly update all components).
> 
> The problems are mostly with restarting the domU, it differs a bit:
> - sometimes screen goes ok, sometimes it's garbage.
> - the radeon powercontrols only seem to work on the first boot and give errors
> on any subsequent one.
> 
> But when it works it does:
> - the powercontrol.
> - opengl and opencl benchmarks with (near) native results.
> - hardware video acceleration in xbmc for instance.
> 
> So one of the main problems at present seems to be proper resetting of the
> whole device on domain shutdown/start. I did do some experiments with the
> opensource radeon driver, but didn't get conclusive results out of that yet.
> 
> --
> Sander
> 
> Tuesday, September 23, 2014, 3:19:41 PM, you wrote:
> 
> > Hi Peter / Sander,
> 
> > Yes, I have AMD GPU passthru working as both primary and secondary
> passthru.  Secondary was easy but primary is a bit tricky.
> 
> > Getting on to your questions;
> 
> >> Is there any specific reason you're using Xen 4.2 rather than 4.4.1?
> 
> > I am working on a project that is based on Xen 4.2 (I can't say any more than
> that).  I have looked at some of the more recent versions just to check if some
> of the bugs that I have seen have been fixed but I have not studied the newer
> versions in detail.  At some point in time in the future I would like will make the
> jump to a more recent version but I don't know the scheduling of that.
> 
> >> In 4.2, using xl or xm?
> 
> > xl
> 
> >> qemu-traditional (with rombios) or "upstream"
> 
> > qemu-traditional
> 
> >> Primary or secondary passthrough?
> 
> > Both but I am focusing on secondary right now.
> 
> >> Presumably 64 bit versions of Windows?
> 
> > 32 bit and 64 bit Win7.  I have tested Win8.1 and it works but my
> > focus is currently Win7
> 
> >> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
> 
> > Awesome.  My goal right now is obtaining stability on Xen 4.2.  Since 4.2 is
> past its feature cutoff I won't be able to submit any open source changes for it.
> I would like to eventually work with the community to get passthru working with
> a recent version of "upstream".
> 
> > Thanks,
> > Kelly
> 
> 
> 
> >> -----Original Message-----
> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> >> Sent: Monday, September 22, 2014 8:38 AM
> >> To: Peter Kay
> >> Cc: xen-devel@lists.xen.org; Zytaruk, Kelly
> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> >>
> >>
> >> Monday, September 22, 2014, 2:16:58 PM, you wrote:
> >>
> >> > Hi Kelly, list
> >>
> >> > I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9.
> >> > I've been
> >> less than successful getting passthrough working at all in Xen
> >> (although it's fine in KVM primary passthrough as long as the BIOS is
> >> supplied as a file). Could I confirm the following :
> >>
> >> > Is there any specific reason you're using Xen 4.2 rather than
> >> > 4.4.1? I know in
> >> some ways 4.4 suffers as it's now xl only and some of the xm
> >> functionality has not come across.
> >>
> >> > In 4.2, using xl or xm?
> >>
> >> Another interesting question/aspect would be qemu-traditional (with
> >> rombios) or "upstream" (with seabios) ?
> >>
> >> > Primary or secondary passthrough?
> >>
> >> > Presumably 64 bit versions of Windows?
> >>
> >> > My system is a bit old (Core2Quad) but as mentioned AMD passthrough
> >> > works
> >> in KVM but I've found it tricky in Xen.
> >>
> >> > I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
> >>
> >> > Thanks
> >>
> >> > Peter
> >>
> >>
> 
> 

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-24 12:12       ` Zytaruk, Kelly
@ 2014-09-24 12:56         ` Gordan Bobic
  2014-09-24 13:31           ` Zytaruk, Kelly
  2014-09-24 13:21         ` Sander Eikelenboom
  1 sibling, 1 reply; 17+ messages in thread
From: Gordan Bobic @ 2014-09-24 12:56 UTC (permalink / raw)
  To: Zytaruk, Kelly; +Cc: Sander Eikelenboom, xen-devel, Peter Kay

On 2014-09-24 13:12, Zytaruk, Kelly wrote:
>> Good to know there is interest from AMD into this area :-)
> 
> I am taking a personal interest in this and would like to improve AMD
> support and presence within the Xen community.
> 
> Gordan has also reported problems restarting a guest.
> 
> I have been trying to reproduce the problem but have not had any luck.
>  As a secondary it restarts for me every time.  I don't know if I
> inadvertently made a change that indirectly fixed it in my code base
> or what the difference might be.
> 
> What Xen version are you testing with?

I mentioned this before, the behaviour is the same with various
versions of Xen between versions 4.2.0 and 4.3.1 (haven't tried
more recent ones). Also with kernels between 3.8.x and 3.14.x.

I'll try to build another machine for testing and re-attempt
with my old HD4850 (I disposed of all my ATI cards apart from
the HD6450 which I'm using in a different machine and the
HD4850 which I kept because it's the latest generation of
pre-R9 ATI cards that has dual DL-DVI outputs). Unfortunately,
that may take a little while (days/weeks) to find time to
do. :(

Note that the fact it's a HD4xxx series card means I
won't be able to use particularly recent drivers as
the support for those has been dropped a while back,
IIRC.

And then there's the issue of the R9 class cards not
working properly behind NF200 bridges (and all 7 of my
PCIe slots are behind NF200 bridges), but I'll worry about
that when I get any ATI card working reliably across
reboots.

Gordan

>> -----Original Message-----
>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> Sent: Tuesday, September 23, 2014 9:45 AM
>> To: Zytaruk, Kelly
>> Cc: Peter Kay; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> 
>> Good to know there is interest from AMD into this area :-)
>> 
>> I'm experimenting for a while with:
>> 
>> - xen-unstable (and thus xl)
>> - latest kernels (both dom0 and domU)
>> - qemu-xen
>> - Radeon HD 6570
>> - secondary passthrough
>> - Debian linux (sid) with the opensource (in kernel) radeon driver
>>   (i also tried fglrx with succes, but it's a real PITA to build with 
>> every
>>   new kernel, so i ditched that)
>> 
>> It used to work, but something broke at the moment, but that could 
>> also be the
>> changes to the systemd cruft that Debian jessie/sid is currently 
>> undergoing (or
>> something else since i regularly update all components).
>> 
>> The problems are mostly with restarting the domU, it differs a bit:
>> - sometimes screen goes ok, sometimes it's garbage.
>> - the radeon powercontrols only seem to work on the first boot and 
>> give errors
>> on any subsequent one.
>> 
>> But when it works it does:
>> - the powercontrol.
>> - opengl and opencl benchmarks with (near) native results.
>> - hardware video acceleration in xbmc for instance.
>> 
>> So one of the main problems at present seems to be proper resetting of 
>> the
>> whole device on domain shutdown/start. I did do some experiments with 
>> the
>> opensource radeon driver, but didn't get conclusive results out of 
>> that yet.
>> 
>> --
>> Sander
>> 
>> Tuesday, September 23, 2014, 3:19:41 PM, you wrote:
>> 
>> > Hi Peter / Sander,
>> 
>> > Yes, I have AMD GPU passthru working as both primary and secondary
>> passthru.  Secondary was easy but primary is a bit tricky.
>> 
>> > Getting on to your questions;
>> 
>> >> Is there any specific reason you're using Xen 4.2 rather than 4.4.1?
>> 
>> > I am working on a project that is based on Xen 4.2 (I can't say any more than
>> that).  I have looked at some of the more recent versions just to 
>> check if some
>> of the bugs that I have seen have been fixed but I have not studied 
>> the newer
>> versions in detail.  At some point in time in the future I would like 
>> will make the
>> jump to a more recent version but I don't know the scheduling of that.
>> 
>> >> In 4.2, using xl or xm?
>> 
>> > xl
>> 
>> >> qemu-traditional (with rombios) or "upstream"
>> 
>> > qemu-traditional
>> 
>> >> Primary or secondary passthrough?
>> 
>> > Both but I am focusing on secondary right now.
>> 
>> >> Presumably 64 bit versions of Windows?
>> 
>> > 32 bit and 64 bit Win7.  I have tested Win8.1 and it works but my
>> > focus is currently Win7
>> 
>> >> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
>> 
>> > Awesome.  My goal right now is obtaining stability on Xen 4.2.  Since 4.2 is
>> past its feature cutoff I won't be able to submit any open source 
>> changes for it.
>> I would like to eventually work with the community to get passthru 
>> working with
>> a recent version of "upstream".
>> 
>> > Thanks,
>> > Kelly
>> 
>> 
>> 
>> >> -----Original Message-----
>> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> >> Sent: Monday, September 22, 2014 8:38 AM
>> >> To: Peter Kay
>> >> Cc: xen-devel@lists.xen.org; Zytaruk, Kelly
>> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> >>
>> >>
>> >> Monday, September 22, 2014, 2:16:58 PM, you wrote:
>> >>
>> >> > Hi Kelly, list
>> >>
>> >> > I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9.
>> >> > I've been
>> >> less than successful getting passthrough working at all in Xen
>> >> (although it's fine in KVM primary passthrough as long as the BIOS is
>> >> supplied as a file). Could I confirm the following :
>> >>
>> >> > Is there any specific reason you're using Xen 4.2 rather than
>> >> > 4.4.1? I know in
>> >> some ways 4.4 suffers as it's now xl only and some of the xm
>> >> functionality has not come across.
>> >>
>> >> > In 4.2, using xl or xm?
>> >>
>> >> Another interesting question/aspect would be qemu-traditional (with
>> >> rombios) or "upstream" (with seabios) ?
>> >>
>> >> > Primary or secondary passthrough?
>> >>
>> >> > Presumably 64 bit versions of Windows?
>> >>
>> >> > My system is a bit old (Core2Quad) but as mentioned AMD passthrough
>> >> > works
>> >> in KVM but I've found it tricky in Xen.
>> >>
>> >> > I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
>> >>
>> >> > Thanks
>> >>
>> >> > Peter
>> >>
>> >>
>> 
>> 

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-24 12:12       ` Zytaruk, Kelly
  2014-09-24 12:56         ` Gordan Bobic
@ 2014-09-24 13:21         ` Sander Eikelenboom
  2014-09-24 13:58           ` Zytaruk, Kelly
  1 sibling, 1 reply; 17+ messages in thread
From: Sander Eikelenboom @ 2014-09-24 13:21 UTC (permalink / raw)
  To: Zytaruk, Kelly; +Cc: Gordan Bobic, xen-devel, Peter Kay


Wednesday, September 24, 2014, 2:12:38 PM, you wrote:

>> Good to know there is interest from AMD into this area :-)

> I am taking a personal interest in this and would like to improve AMD support and presence within the Xen community.

Thanks for that !

> Gordan has also reported problems restarting a guest.  

Added Konrad to the CC as pciback maintainer.

Yes, from what i see the problem seems to be that the Radeon card is not reset 
to a state were it will regard itself as "unposted". (on the first boot of the 
guest i see the driver report it hasn't posted (which is correct), it starts to 
past, and it works. On subsequent boots of the domU i don't see the unposted 
message but some failures that are probably due to the driver regarding the card as 
already been posted and skipping some init logic and reusing wrong values.

So current xen-pciback logic doesn't seem to be able to reset the card in a 
"non-posted" state. 

I don't know if you know what kind of reset is required for radeon cards to 
regard itself as "not posted" ?

Current xen-pciback logic uses the "__pci_reset_function_locked(dev);" functions 
(see pcistub.c pcistub_device_release()) to try to reset the device .. that 
function in turn tries some possible reset functions in a specific order and 
bails out at the first one reporting "succes". However it could be that this 
level of reset is not enough for this specific case. (in my case it always uses 
and succeeds at the first (pci_dev_specific_reset(dev, probe);).

When looking at the code for vfio/kvm in "drivers/vfio/pci/vfio_pci.c  
vfio_pci_disable()", it seems to use:
- Another order for disabling resetting and config save/restore
- Always try a slot/bus reset on the way out ..

I'm trying to experiment with that in 2 ways:
1) overrulling the logic in the domU radeon driver to do the reposting no matter 
   in what state it thinks it is.
2) Trying to change the xen-pciback reset logic, but at present that delivers 
   bad irq's to dom0 for completly different irq's as the passedthrough device 
   has (which i have seen before .. and is a bit worrying)

> I have been trying to reproduce the problem but have not had any luck.  As a secondary it restarts for me every time.  I don't know if I inadvertently made a change that indirectly fixed it in my code base or what the difference might be.

Perhaps in the older qemu-traditional there is already some sort of reset done ?

> What Xen version are you testing with?
I'm almost always living on the edge with Xen-unstable ;)
(the latest and greatest, which is actually pretty stable)

--
Sander

> Thanks,
> Kelly

>> -----Original Message-----
>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> Sent: Tuesday, September 23, 2014 9:45 AM
>> To: Zytaruk, Kelly
>> Cc: Peter Kay; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> 
>> Good to know there is interest from AMD into this area :-)
>> 
>> I'm experimenting for a while with:
>> 
>> - xen-unstable (and thus xl)
>> - latest kernels (both dom0 and domU)
>> - qemu-xen
>> - Radeon HD 6570
>> - secondary passthrough
>> - Debian linux (sid) with the opensource (in kernel) radeon driver
>>   (i also tried fglrx with succes, but it's a real PITA to build with every
>>   new kernel, so i ditched that)
>> 
>> It used to work, but something broke at the moment, but that could also be the
>> changes to the systemd cruft that Debian jessie/sid is currently undergoing (or
>> something else since i regularly update all components).
>> 
>> The problems are mostly with restarting the domU, it differs a bit:
>> - sometimes screen goes ok, sometimes it's garbage.
>> - the radeon powercontrols only seem to work on the first boot and give errors
>> on any subsequent one.
>> 
>> But when it works it does:
>> - the powercontrol.
>> - opengl and opencl benchmarks with (near) native results.
>> - hardware video acceleration in xbmc for instance.
>> 
>> So one of the main problems at present seems to be proper resetting of the
>> whole device on domain shutdown/start. I did do some experiments with the
>> opensource radeon driver, but didn't get conclusive results out of that yet.
>> 
>> --
>> Sander
>> 
>> Tuesday, September 23, 2014, 3:19:41 PM, you wrote:
>> 
>> > Hi Peter / Sander,
>> 
>> > Yes, I have AMD GPU passthru working as both primary and secondary
>> passthru.  Secondary was easy but primary is a bit tricky.
>> 
>> > Getting on to your questions;
>> 
>> >> Is there any specific reason you're using Xen 4.2 rather than 4.4.1?
>> 
>> > I am working on a project that is based on Xen 4.2 (I can't say any more than
>> that).  I have looked at some of the more recent versions just to check if some
>> of the bugs that I have seen have been fixed but I have not studied the newer
>> versions in detail.  At some point in time in the future I would like will make the
>> jump to a more recent version but I don't know the scheduling of that.
>> 
>> >> In 4.2, using xl or xm?
>> 
>> > xl
>> 
>> >> qemu-traditional (with rombios) or "upstream"
>> 
>> > qemu-traditional
>> 
>> >> Primary or secondary passthrough?
>> 
>> > Both but I am focusing on secondary right now.
>> 
>> >> Presumably 64 bit versions of Windows?
>> 
>> > 32 bit and 64 bit Win7.  I have tested Win8.1 and it works but my
>> > focus is currently Win7
>> 
>> >> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
>> 
>> > Awesome.  My goal right now is obtaining stability on Xen 4.2.  Since 4.2 is
>> past its feature cutoff I won't be able to submit any open source changes for it.
>> I would like to eventually work with the community to get passthru working with
>> a recent version of "upstream".
>> 
>> > Thanks,
>> > Kelly
>> 
>> 
>> 
>> >> -----Original Message-----
>> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> >> Sent: Monday, September 22, 2014 8:38 AM
>> >> To: Peter Kay
>> >> Cc: xen-devel@lists.xen.org; Zytaruk, Kelly
>> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> >>
>> >>
>> >> Monday, September 22, 2014, 2:16:58 PM, you wrote:
>> >>
>> >> > Hi Kelly, list
>> >>
>> >> > I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9.
>> >> > I've been
>> >> less than successful getting passthrough working at all in Xen
>> >> (although it's fine in KVM primary passthrough as long as the BIOS is
>> >> supplied as a file). Could I confirm the following :
>> >>
>> >> > Is there any specific reason you're using Xen 4.2 rather than
>> >> > 4.4.1? I know in
>> >> some ways 4.4 suffers as it's now xl only and some of the xm
>> >> functionality has not come across.
>> >>
>> >> > In 4.2, using xl or xm?
>> >>
>> >> Another interesting question/aspect would be qemu-traditional (with
>> >> rombios) or "upstream" (with seabios) ?
>> >>
>> >> > Primary or secondary passthrough?
>> >>
>> >> > Presumably 64 bit versions of Windows?
>> >>
>> >> > My system is a bit old (Core2Quad) but as mentioned AMD passthrough
>> >> > works
>> >> in KVM but I've found it tricky in Xen.
>> >>
>> >> > I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
>> >>
>> >> > Thanks
>> >>
>> >> > Peter
>> >>
>> >>
>> 
>> 

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-24 12:56         ` Gordan Bobic
@ 2014-09-24 13:31           ` Zytaruk, Kelly
  2014-09-24 13:35             ` Gordan Bobic
  0 siblings, 1 reply; 17+ messages in thread
From: Zytaruk, Kelly @ 2014-09-24 13:31 UTC (permalink / raw)
  To: Gordan Bobic; +Cc: Sander Eikelenboom, xen-devel, Peter Kay

AMD has two sets of drivers.  One is our Legacy driver which supports HD4xxx and previous GPU families and the other is our current driver which supports HD5xxx and up.
Officially we don't support the Legacy driver anymore.  HD4850 is a very old product and there isn't much that I can do with it as the driver changed significantly between HD4xxx and HD5xxx. 

Please don't spend too much time on the HD4850.  It uses an entirely different driver and there have been a lot of fixes that have gone into the latest driver.

Thanks,
Kelly

> -----Original Message-----
> From: Gordan Bobic [mailto:gordan@bobich.net]
> Sent: Wednesday, September 24, 2014 8:56 AM
> To: Zytaruk, Kelly
> Cc: Sander Eikelenboom; Peter Kay; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] AMD GPU passthrough in Xen
> 
> On 2014-09-24 13:12, Zytaruk, Kelly wrote:
> >> Good to know there is interest from AMD into this area :-)
> >
> > I am taking a personal interest in this and would like to improve AMD
> > support and presence within the Xen community.
> >
> > Gordan has also reported problems restarting a guest.
> >
> > I have been trying to reproduce the problem but have not had any luck.
> >  As a secondary it restarts for me every time.  I don't know if I
> > inadvertently made a change that indirectly fixed it in my code base
> > or what the difference might be.
> >
> > What Xen version are you testing with?
> 
> I mentioned this before, the behaviour is the same with various versions of Xen
> between versions 4.2.0 and 4.3.1 (haven't tried more recent ones). Also with
> kernels between 3.8.x and 3.14.x.
> 
> I'll try to build another machine for testing and re-attempt with my old HD4850 (I
> disposed of all my ATI cards apart from the HD6450 which I'm using in a
> different machine and the
> HD4850 which I kept because it's the latest generation of
> pre-R9 ATI cards that has dual DL-DVI outputs). Unfortunately, that may take a
> little while (days/weeks) to find time to do. :(
> 
> Note that the fact it's a HD4xxx series card means I won't be able to use
> particularly recent drivers as the support for those has been dropped a while
> back, IIRC.
> 
> And then there's the issue of the R9 class cards not working properly behind
> NF200 bridges (and all 7 of my PCIe slots are behind NF200 bridges), but I'll
> worry about that when I get any ATI card working reliably across reboots.
> 
> Gordan
> 
> >> -----Original Message-----
> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> >> Sent: Tuesday, September 23, 2014 9:45 AM
> >> To: Zytaruk, Kelly
> >> Cc: Peter Kay; xen-devel@lists.xen.org
> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> >>
> >> Good to know there is interest from AMD into this area :-)
> >>
> >> I'm experimenting for a while with:
> >>
> >> - xen-unstable (and thus xl)
> >> - latest kernels (both dom0 and domU)
> >> - qemu-xen
> >> - Radeon HD 6570
> >> - secondary passthrough
> >> - Debian linux (sid) with the opensource (in kernel) radeon driver
> >>   (i also tried fglrx with succes, but it's a real PITA to build with
> >> every
> >>   new kernel, so i ditched that)
> >>
> >> It used to work, but something broke at the moment, but that could
> >> also be the changes to the systemd cruft that Debian jessie/sid is
> >> currently undergoing (or something else since i regularly update all
> >> components).
> >>
> >> The problems are mostly with restarting the domU, it differs a bit:
> >> - sometimes screen goes ok, sometimes it's garbage.
> >> - the radeon powercontrols only seem to work on the first boot and
> >> give errors on any subsequent one.
> >>
> >> But when it works it does:
> >> - the powercontrol.
> >> - opengl and opencl benchmarks with (near) native results.
> >> - hardware video acceleration in xbmc for instance.
> >>
> >> So one of the main problems at present seems to be proper resetting
> >> of the whole device on domain shutdown/start. I did do some
> >> experiments with the opensource radeon driver, but didn't get
> >> conclusive results out of that yet.
> >>
> >> --
> >> Sander
> >>
> >> Tuesday, September 23, 2014, 3:19:41 PM, you wrote:
> >>
> >> > Hi Peter / Sander,
> >>
> >> > Yes, I have AMD GPU passthru working as both primary and secondary
> >> passthru.  Secondary was easy but primary is a bit tricky.
> >>
> >> > Getting on to your questions;
> >>
> >> >> Is there any specific reason you're using Xen 4.2 rather than 4.4.1?
> >>
> >> > I am working on a project that is based on Xen 4.2 (I can't say any more
> than
> >> that).  I have looked at some of the more recent versions just to
> >> check if some
> >> of the bugs that I have seen have been fixed but I have not studied
> >> the newer
> >> versions in detail.  At some point in time in the future I would like
> >> will make the
> >> jump to a more recent version but I don't know the scheduling of that.
> >>
> >> >> In 4.2, using xl or xm?
> >>
> >> > xl
> >>
> >> >> qemu-traditional (with rombios) or "upstream"
> >>
> >> > qemu-traditional
> >>
> >> >> Primary or secondary passthrough?
> >>
> >> > Both but I am focusing on secondary right now.
> >>
> >> >> Presumably 64 bit versions of Windows?
> >>
> >> > 32 bit and 64 bit Win7.  I have tested Win8.1 and it works but my
> >> > focus is currently Win7
> >>
> >> >> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
> >>
> >> > Awesome.  My goal right now is obtaining stability on Xen 4.2.  Since 4.2 is
> >> past its feature cutoff I won't be able to submit any open source
> >> changes for it.
> >> I would like to eventually work with the community to get passthru
> >> working with
> >> a recent version of "upstream".
> >>
> >> > Thanks,
> >> > Kelly
> >>
> >>
> >>
> >> >> -----Original Message-----
> >> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> >> >> Sent: Monday, September 22, 2014 8:38 AM
> >> >> To: Peter Kay
> >> >> Cc: xen-devel@lists.xen.org; Zytaruk, Kelly
> >> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> >> >>
> >> >>
> >> >> Monday, September 22, 2014, 2:16:58 PM, you wrote:
> >> >>
> >> >> > Hi Kelly, list
> >> >>
> >> >> > I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9.
> >> >> > I've been
> >> >> less than successful getting passthrough working at all in Xen
> >> >> (although it's fine in KVM primary passthrough as long as the BIOS is
> >> >> supplied as a file). Could I confirm the following :
> >> >>
> >> >> > Is there any specific reason you're using Xen 4.2 rather than
> >> >> > 4.4.1? I know in
> >> >> some ways 4.4 suffers as it's now xl only and some of the xm
> >> >> functionality has not come across.
> >> >>
> >> >> > In 4.2, using xl or xm?
> >> >>
> >> >> Another interesting question/aspect would be qemu-traditional (with
> >> >> rombios) or "upstream" (with seabios) ?
> >> >>
> >> >> > Primary or secondary passthrough?
> >> >>
> >> >> > Presumably 64 bit versions of Windows?
> >> >>
> >> >> > My system is a bit old (Core2Quad) but as mentioned AMD passthrough
> >> >> > works
> >> >> in KVM but I've found it tricky in Xen.
> >> >>
> >> >> > I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
> >> >>
> >> >> > Thanks
> >> >>
> >> >> > Peter
> >> >>
> >> >>
> >>
> >>

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-24 13:31           ` Zytaruk, Kelly
@ 2014-09-24 13:35             ` Gordan Bobic
  0 siblings, 0 replies; 17+ messages in thread
From: Gordan Bobic @ 2014-09-24 13:35 UTC (permalink / raw)
  To: Zytaruk, Kelly; +Cc: Sander Eikelenboom, xen-devel, Peter Kay

Fair enough, thanks for the info. I guess there isn't much
I can do to help at the moment, then, due to lack of suitable
hardware.

Gordan

On 2014-09-24 14:31, Zytaruk, Kelly wrote:
> AMD has two sets of drivers.  One is our Legacy driver which supports
> HD4xxx and previous GPU families and the other is our current driver
> which supports HD5xxx and up.
> Officially we don't support the Legacy driver anymore.  HD4850 is a
> very old product and there isn't much that I can do with it as the
> driver changed significantly between HD4xxx and HD5xxx.
> 
> Please don't spend too much time on the HD4850.  It uses an entirely
> different driver and there have been a lot of fixes that have gone
> into the latest driver.
> 
> Thanks,
> Kelly
> 
>> -----Original Message-----
>> From: Gordan Bobic [mailto:gordan@bobich.net]
>> Sent: Wednesday, September 24, 2014 8:56 AM
>> To: Zytaruk, Kelly
>> Cc: Sander Eikelenboom; Peter Kay; xen-devel@lists.xen.org
>> Subject: RE: [Xen-devel] AMD GPU passthrough in Xen
>> 
>> On 2014-09-24 13:12, Zytaruk, Kelly wrote:
>> >> Good to know there is interest from AMD into this area :-)
>> >
>> > I am taking a personal interest in this and would like to improve AMD
>> > support and presence within the Xen community.
>> >
>> > Gordan has also reported problems restarting a guest.
>> >
>> > I have been trying to reproduce the problem but have not had any luck.
>> >  As a secondary it restarts for me every time.  I don't know if I
>> > inadvertently made a change that indirectly fixed it in my code base
>> > or what the difference might be.
>> >
>> > What Xen version are you testing with?
>> 
>> I mentioned this before, the behaviour is the same with various 
>> versions of Xen
>> between versions 4.2.0 and 4.3.1 (haven't tried more recent ones). 
>> Also with
>> kernels between 3.8.x and 3.14.x.
>> 
>> I'll try to build another machine for testing and re-attempt with my 
>> old HD4850 (I
>> disposed of all my ATI cards apart from the HD6450 which I'm using in 
>> a
>> different machine and the
>> HD4850 which I kept because it's the latest generation of
>> pre-R9 ATI cards that has dual DL-DVI outputs). Unfortunately, that 
>> may take a
>> little while (days/weeks) to find time to do. :(
>> 
>> Note that the fact it's a HD4xxx series card means I won't be able to 
>> use
>> particularly recent drivers as the support for those has been dropped 
>> a while
>> back, IIRC.
>> 
>> And then there's the issue of the R9 class cards not working properly 
>> behind
>> NF200 bridges (and all 7 of my PCIe slots are behind NF200 bridges), 
>> but I'll
>> worry about that when I get any ATI card working reliably across 
>> reboots.
>> 
>> Gordan
>> 
>> >> -----Original Message-----
>> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> >> Sent: Tuesday, September 23, 2014 9:45 AM
>> >> To: Zytaruk, Kelly
>> >> Cc: Peter Kay; xen-devel@lists.xen.org
>> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> >>
>> >> Good to know there is interest from AMD into this area :-)
>> >>
>> >> I'm experimenting for a while with:
>> >>
>> >> - xen-unstable (and thus xl)
>> >> - latest kernels (both dom0 and domU)
>> >> - qemu-xen
>> >> - Radeon HD 6570
>> >> - secondary passthrough
>> >> - Debian linux (sid) with the opensource (in kernel) radeon driver
>> >>   (i also tried fglrx with succes, but it's a real PITA to build with
>> >> every
>> >>   new kernel, so i ditched that)
>> >>
>> >> It used to work, but something broke at the moment, but that could
>> >> also be the changes to the systemd cruft that Debian jessie/sid is
>> >> currently undergoing (or something else since i regularly update all
>> >> components).
>> >>
>> >> The problems are mostly with restarting the domU, it differs a bit:
>> >> - sometimes screen goes ok, sometimes it's garbage.
>> >> - the radeon powercontrols only seem to work on the first boot and
>> >> give errors on any subsequent one.
>> >>
>> >> But when it works it does:
>> >> - the powercontrol.
>> >> - opengl and opencl benchmarks with (near) native results.
>> >> - hardware video acceleration in xbmc for instance.
>> >>
>> >> So one of the main problems at present seems to be proper resetting
>> >> of the whole device on domain shutdown/start. I did do some
>> >> experiments with the opensource radeon driver, but didn't get
>> >> conclusive results out of that yet.
>> >>
>> >> --
>> >> Sander
>> >>
>> >> Tuesday, September 23, 2014, 3:19:41 PM, you wrote:
>> >>
>> >> > Hi Peter / Sander,
>> >>
>> >> > Yes, I have AMD GPU passthru working as both primary and secondary
>> >> passthru.  Secondary was easy but primary is a bit tricky.
>> >>
>> >> > Getting on to your questions;
>> >>
>> >> >> Is there any specific reason you're using Xen 4.2 rather than 4.4.1?
>> >>
>> >> > I am working on a project that is based on Xen 4.2 (I can't say any more
>> than
>> >> that).  I have looked at some of the more recent versions just to
>> >> check if some
>> >> of the bugs that I have seen have been fixed but I have not studied
>> >> the newer
>> >> versions in detail.  At some point in time in the future I would like
>> >> will make the
>> >> jump to a more recent version but I don't know the scheduling of that.
>> >>
>> >> >> In 4.2, using xl or xm?
>> >>
>> >> > xl
>> >>
>> >> >> qemu-traditional (with rombios) or "upstream"
>> >>
>> >> > qemu-traditional
>> >>
>> >> >> Primary or secondary passthrough?
>> >>
>> >> > Both but I am focusing on secondary right now.
>> >>
>> >> >> Presumably 64 bit versions of Windows?
>> >>
>> >> > 32 bit and 64 bit Win7.  I have tested Win8.1 and it works but my
>> >> > focus is currently Win7
>> >>
>> >> >> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
>> >>
>> >> > Awesome.  My goal right now is obtaining stability on Xen 4.2.  Since 4.2 is
>> >> past its feature cutoff I won't be able to submit any open source
>> >> changes for it.
>> >> I would like to eventually work with the community to get passthru
>> >> working with
>> >> a recent version of "upstream".
>> >>
>> >> > Thanks,
>> >> > Kelly
>> >>
>> >>
>> >>
>> >> >> -----Original Message-----
>> >> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> >> >> Sent: Monday, September 22, 2014 8:38 AM
>> >> >> To: Peter Kay
>> >> >> Cc: xen-devel@lists.xen.org; Zytaruk, Kelly
>> >> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> >> >>
>> >> >>
>> >> >> Monday, September 22, 2014, 2:16:58 PM, you wrote:
>> >> >>
>> >> >> > Hi Kelly, list
>> >> >>
>> >> >> > I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9.
>> >> >> > I've been
>> >> >> less than successful getting passthrough working at all in Xen
>> >> >> (although it's fine in KVM primary passthrough as long as the BIOS is
>> >> >> supplied as a file). Could I confirm the following :
>> >> >>
>> >> >> > Is there any specific reason you're using Xen 4.2 rather than
>> >> >> > 4.4.1? I know in
>> >> >> some ways 4.4 suffers as it's now xl only and some of the xm
>> >> >> functionality has not come across.
>> >> >>
>> >> >> > In 4.2, using xl or xm?
>> >> >>
>> >> >> Another interesting question/aspect would be qemu-traditional (with
>> >> >> rombios) or "upstream" (with seabios) ?
>> >> >>
>> >> >> > Primary or secondary passthrough?
>> >> >>
>> >> >> > Presumably 64 bit versions of Windows?
>> >> >>
>> >> >> > My system is a bit old (Core2Quad) but as mentioned AMD passthrough
>> >> >> > works
>> >> >> in KVM but I've found it tricky in Xen.
>> >> >>
>> >> >> > I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
>> >> >>
>> >> >> > Thanks
>> >> >>
>> >> >> > Peter
>> >> >>
>> >> >>
>> >>
>> >>

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-24 13:21         ` Sander Eikelenboom
@ 2014-09-24 13:58           ` Zytaruk, Kelly
  2014-09-24 14:16             ` Sander Eikelenboom
  0 siblings, 1 reply; 17+ messages in thread
From: Zytaruk, Kelly @ 2014-09-24 13:58 UTC (permalink / raw)
  To: Sander Eikelenboom; +Cc: Gordan Bobic, xen-devel, Peter Kay

Sander,

You have given me some interesting information.  First off, I would like to ask you about one of your comments;

> Yes, from what i see the problem seems to be that the Radeon card is not reset
> to a state were it will regard itself as "unposted". (on the first boot of the guest i
> see the driver report it hasn't posted (which is correct), it starts to past, and it
> works. On subsequent boots of the domU i don't see the unposted message

I am curious how you can tell if the driver is posting or not?  Which message are you looking at? 

Thanks,
Kelly

> -----Original Message-----
> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> Sent: Wednesday, September 24, 2014 9:22 AM
> To: Zytaruk, Kelly
> Cc: Peter Kay; xen-devel@lists.xen.org; Gordan Bobic; Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> 
> 
> Wednesday, September 24, 2014, 2:12:38 PM, you wrote:
> 
> >> Good to know there is interest from AMD into this area :-)
> 
> > I am taking a personal interest in this and would like to improve AMD support
> and presence within the Xen community.
> 
> Thanks for that !
> 
> > Gordan has also reported problems restarting a guest.
> 
> Added Konrad to the CC as pciback maintainer.
> 
> Yes, from what i see the problem seems to be that the Radeon card is not reset
> to a state were it will regard itself as "unposted". (on the first boot of the guest i
> see the driver report it hasn't posted (which is correct), it starts to past, and it
> works. On subsequent boots of the domU i don't see the unposted message but
> some failures that are probably due to the driver regarding the card as already
> been posted and skipping some init logic and reusing wrong values.
> 
> So current xen-pciback logic doesn't seem to be able to reset the card in a "non-
> posted" state.
> 
> I don't know if you know what kind of reset is required for radeon cards to
> regard itself as "not posted" ?
> 
> Current xen-pciback logic uses the "__pci_reset_function_locked(dev);"
> functions (see pcistub.c pcistub_device_release()) to try to reset the device ..
> that function in turn tries some possible reset functions in a specific order and
> bails out at the first one reporting "succes". However it could be that this level
> of reset is not enough for this specific case. (in my case it always uses and
> succeeds at the first (pci_dev_specific_reset(dev, probe);).
> 
> When looking at the code for vfio/kvm in "drivers/vfio/pci/vfio_pci.c
> vfio_pci_disable()", it seems to use:
> - Another order for disabling resetting and config save/restore
> - Always try a slot/bus reset on the way out ..
> 
> I'm trying to experiment with that in 2 ways:
> 1) overrulling the logic in the domU radeon driver to do the reposting no matter
>    in what state it thinks it is.
> 2) Trying to change the xen-pciback reset logic, but at present that delivers
>    bad irq's to dom0 for completly different irq's as the passedthrough device
>    has (which i have seen before .. and is a bit worrying)
> 
> > I have been trying to reproduce the problem but have not had any luck.  As a
> secondary it restarts for me every time.  I don't know if I inadvertently made a
> change that indirectly fixed it in my code base or what the difference might be.
> 
> Perhaps in the older qemu-traditional there is already some sort of reset done ?
> 
> > What Xen version are you testing with?
> I'm almost always living on the edge with Xen-unstable ;) (the latest and
> greatest, which is actually pretty stable)
> 
> --
> Sander
> 
> > Thanks,
> > Kelly
> 
> >> -----Original Message-----
> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> >> Sent: Tuesday, September 23, 2014 9:45 AM
> >> To: Zytaruk, Kelly
> >> Cc: Peter Kay; xen-devel@lists.xen.org
> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> >>
> >> Good to know there is interest from AMD into this area :-)
> >>
> >> I'm experimenting for a while with:
> >>
> >> - xen-unstable (and thus xl)
> >> - latest kernels (both dom0 and domU)
> >> - qemu-xen
> >> - Radeon HD 6570
> >> - secondary passthrough
> >> - Debian linux (sid) with the opensource (in kernel) radeon driver
> >>   (i also tried fglrx with succes, but it's a real PITA to build with every
> >>   new kernel, so i ditched that)
> >>
> >> It used to work, but something broke at the moment, but that could
> >> also be the changes to the systemd cruft that Debian jessie/sid is
> >> currently undergoing (or something else since i regularly update all
> components).
> >>
> >> The problems are mostly with restarting the domU, it differs a bit:
> >> - sometimes screen goes ok, sometimes it's garbage.
> >> - the radeon powercontrols only seem to work on the first boot and
> >> give errors on any subsequent one.
> >>
> >> But when it works it does:
> >> - the powercontrol.
> >> - opengl and opencl benchmarks with (near) native results.
> >> - hardware video acceleration in xbmc for instance.
> >>
> >> So one of the main problems at present seems to be proper resetting
> >> of the whole device on domain shutdown/start. I did do some
> >> experiments with the opensource radeon driver, but didn't get conclusive
> results out of that yet.
> >>
> >> --
> >> Sander
> >>
> >> Tuesday, September 23, 2014, 3:19:41 PM, you wrote:
> >>
> >> > Hi Peter / Sander,
> >>
> >> > Yes, I have AMD GPU passthru working as both primary and secondary
> >> passthru.  Secondary was easy but primary is a bit tricky.
> >>
> >> > Getting on to your questions;
> >>
> >> >> Is there any specific reason you're using Xen 4.2 rather than 4.4.1?
> >>
> >> > I am working on a project that is based on Xen 4.2 (I can't say any
> >> > more than
> >> that).  I have looked at some of the more recent versions just to
> >> check if some of the bugs that I have seen have been fixed but I have
> >> not studied the newer versions in detail.  At some point in time in
> >> the future I would like will make the jump to a more recent version but I don't
> know the scheduling of that.
> >>
> >> >> In 4.2, using xl or xm?
> >>
> >> > xl
> >>
> >> >> qemu-traditional (with rombios) or "upstream"
> >>
> >> > qemu-traditional
> >>
> >> >> Primary or secondary passthrough?
> >>
> >> > Both but I am focusing on secondary right now.
> >>
> >> >> Presumably 64 bit versions of Windows?
> >>
> >> > 32 bit and 64 bit Win7.  I have tested Win8.1 and it works but my
> >> > focus is currently Win7
> >>
> >> >> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
> >>
> >> > Awesome.  My goal right now is obtaining stability on Xen 4.2.
> >> > Since 4.2 is
> >> past its feature cutoff I won't be able to submit any open source changes for
> it.
> >> I would like to eventually work with the community to get passthru
> >> working with a recent version of "upstream".
> >>
> >> > Thanks,
> >> > Kelly
> >>
> >>
> >>
> >> >> -----Original Message-----
> >> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> >> >> Sent: Monday, September 22, 2014 8:38 AM
> >> >> To: Peter Kay
> >> >> Cc: xen-devel@lists.xen.org; Zytaruk, Kelly
> >> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> >> >>
> >> >>
> >> >> Monday, September 22, 2014, 2:16:58 PM, you wrote:
> >> >>
> >> >> > Hi Kelly, list
> >> >>
> >> >> > I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9.
> >> >> > I've been
> >> >> less than successful getting passthrough working at all in Xen
> >> >> (although it's fine in KVM primary passthrough as long as the BIOS
> >> >> is supplied as a file). Could I confirm the following :
> >> >>
> >> >> > Is there any specific reason you're using Xen 4.2 rather than
> >> >> > 4.4.1? I know in
> >> >> some ways 4.4 suffers as it's now xl only and some of the xm
> >> >> functionality has not come across.
> >> >>
> >> >> > In 4.2, using xl or xm?
> >> >>
> >> >> Another interesting question/aspect would be qemu-traditional
> >> >> (with
> >> >> rombios) or "upstream" (with seabios) ?
> >> >>
> >> >> > Primary or secondary passthrough?
> >> >>
> >> >> > Presumably 64 bit versions of Windows?
> >> >>
> >> >> > My system is a bit old (Core2Quad) but as mentioned AMD
> >> >> > passthrough works
> >> >> in KVM but I've found it tricky in Xen.
> >> >>
> >> >> > I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
> >> >>
> >> >> > Thanks
> >> >>
> >> >> > Peter
> >> >>
> >> >>
> >>
> >>
> 
> 

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-24 13:58           ` Zytaruk, Kelly
@ 2014-09-24 14:16             ` Sander Eikelenboom
  2014-09-24 15:10               ` Zytaruk, Kelly
  0 siblings, 1 reply; 17+ messages in thread
From: Sander Eikelenboom @ 2014-09-24 14:16 UTC (permalink / raw)
  To: Zytaruk, Kelly; +Cc: Gordan Bobic, xen-devel, Peter Kay

[-- Attachment #1: Type: text/plain, Size: 10653 bytes --]


Wednesday, September 24, 2014, 3:58:57 PM, you wrote:

> Sander,

> You have given me some interesting information.  First off, I would like to ask you about one of your comments;

>> Yes, from what i see the problem seems to be that the Radeon card is not reset
>> to a state were it will regard itself as "unposted". (on the first boot of the guest i
>> see the driver report it hasn't posted (which is correct), it starts to past, and it
>> works. On subsequent boots of the domU i don't see the unposted message

> I am curious how you can tell if the driver is posting or not?  Which message are you looking at? 

With domU kernel 3.17-rc5 (with older kernels (i forgot the version number where it got fixed) there was a problem with the secondary card getting the shadow rom 
from the primary(emulated cirrus) ( see https://lkml.org/lkml/2014/2/13/109)), so a recent kernel domU kernel is best :)

In the domU on first boot it says it's not posted:

[    4.346649] [drm] Initialized drm 1.1.0 20060810
[    4.359722] [drm] radeon kernel modesetting enabled.
[    4.380435] xen: --> pirq=32 -> irq=36 (gsi=36)
[    4.383891] [drm] initializing kernel modesetting (TURKS 0x1002:0x6759 0x174B:0xE193).
[    4.405597] [drm] register mmio base: 0xF3060000
[    4.418262] [drm] register mmio size: 131072
[    4.559911] ATOM BIOS: ELIXIR
[    4.569063] [drm] GPU not posted. posting now...
[    4.585542] radeon 0000:00:05.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
[    4.609664] radeon 0000:00:05.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
....

In the domU on subsequent boots that message is not there, but i end up with 
errors like (and garbage on the screen (looks somewhat like white noise)):

[    4.321952] [drm] Initialized drm 1.1.0 20060810
[    4.335246] [drm] radeon kernel modesetting enabled.
[    4.355349] xen: --> pirq=32 -> irq=36 (gsi=36)
[    4.359541] [drm] initializing kernel modesetting (TURKS 0x1002:0x6759 0x174B:0xE193).
[    4.385655] [drm] register mmio base: 0xF3060000
[    4.401814] [drm] register mmio size: 131072
[    4.599903] ATOM BIOS: ELIXIR
[    4.609170] radeon 0000:00:05.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
[    4.632895] radeon 0000:00:05.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
....
[    5.126844] [drm:radeon_pm_init_dpm] *ERROR* radeon: dpm initialization failed
....
[    5.555322] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
....
 
(complete dmesg from both boots attached)

--
Sander

> Thanks,
> Kelly

>> -----Original Message-----
>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> Sent: Wednesday, September 24, 2014 9:22 AM
>> To: Zytaruk, Kelly
>> Cc: Peter Kay; xen-devel@lists.xen.org; Gordan Bobic; Konrad Rzeszutek Wilk
>> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> 
>> 
>> Wednesday, September 24, 2014, 2:12:38 PM, you wrote:
>> 
>> >> Good to know there is interest from AMD into this area :-)
>> 
>> > I am taking a personal interest in this and would like to improve AMD support
>> and presence within the Xen community.
>> 
>> Thanks for that !
>> 
>> > Gordan has also reported problems restarting a guest.
>> 
>> Added Konrad to the CC as pciback maintainer.
>> 
>> Yes, from what i see the problem seems to be that the Radeon card is not reset
>> to a state were it will regard itself as "unposted". (on the first boot of the guest i
>> see the driver report it hasn't posted (which is correct), it starts to past, and it
>> works. On subsequent boots of the domU i don't see the unposted message but
>> some failures that are probably due to the driver regarding the card as already
>> been posted and skipping some init logic and reusing wrong values.
>> 
>> So current xen-pciback logic doesn't seem to be able to reset the card in a "non-
>> posted" state.
>> 
>> I don't know if you know what kind of reset is required for radeon cards to
>> regard itself as "not posted" ?
>> 
>> Current xen-pciback logic uses the "__pci_reset_function_locked(dev);"
>> functions (see pcistub.c pcistub_device_release()) to try to reset the device ..
>> that function in turn tries some possible reset functions in a specific order and
>> bails out at the first one reporting "succes". However it could be that this level
>> of reset is not enough for this specific case. (in my case it always uses and
>> succeeds at the first (pci_dev_specific_reset(dev, probe);).
>> 
>> When looking at the code for vfio/kvm in "drivers/vfio/pci/vfio_pci.c
>> vfio_pci_disable()", it seems to use:
>> - Another order for disabling resetting and config save/restore
>> - Always try a slot/bus reset on the way out ..
>> 
>> I'm trying to experiment with that in 2 ways:
>> 1) overrulling the logic in the domU radeon driver to do the reposting no matter
>>    in what state it thinks it is.
>> 2) Trying to change the xen-pciback reset logic, but at present that delivers
>>    bad irq's to dom0 for completly different irq's as the passedthrough device
>>    has (which i have seen before .. and is a bit worrying)
>> 
>> > I have been trying to reproduce the problem but have not had any luck.  As a
>> secondary it restarts for me every time.  I don't know if I inadvertently made a
>> change that indirectly fixed it in my code base or what the difference might be.
>> 
>> Perhaps in the older qemu-traditional there is already some sort of reset done ?
>> 
>> > What Xen version are you testing with?
>> I'm almost always living on the edge with Xen-unstable ;) (the latest and
>> greatest, which is actually pretty stable)
>> 
>> --
>> Sander
>> 
>> > Thanks,
>> > Kelly
>> 
>> >> -----Original Message-----
>> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> >> Sent: Tuesday, September 23, 2014 9:45 AM
>> >> To: Zytaruk, Kelly
>> >> Cc: Peter Kay; xen-devel@lists.xen.org
>> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> >>
>> >> Good to know there is interest from AMD into this area :-)
>> >>
>> >> I'm experimenting for a while with:
>> >>
>> >> - xen-unstable (and thus xl)
>> >> - latest kernels (both dom0 and domU)
>> >> - qemu-xen
>> >> - Radeon HD 6570
>> >> - secondary passthrough
>> >> - Debian linux (sid) with the opensource (in kernel) radeon driver
>> >>   (i also tried fglrx with succes, but it's a real PITA to build with every
>> >>   new kernel, so i ditched that)
>> >>
>> >> It used to work, but something broke at the moment, but that could
>> >> also be the changes to the systemd cruft that Debian jessie/sid is
>> >> currently undergoing (or something else since i regularly update all
>> components).
>> >>
>> >> The problems are mostly with restarting the domU, it differs a bit:
>> >> - sometimes screen goes ok, sometimes it's garbage.
>> >> - the radeon powercontrols only seem to work on the first boot and
>> >> give errors on any subsequent one.
>> >>
>> >> But when it works it does:
>> >> - the powercontrol.
>> >> - opengl and opencl benchmarks with (near) native results.
>> >> - hardware video acceleration in xbmc for instance.
>> >>
>> >> So one of the main problems at present seems to be proper resetting
>> >> of the whole device on domain shutdown/start. I did do some
>> >> experiments with the opensource radeon driver, but didn't get conclusive
>> results out of that yet.
>> >>
>> >> --
>> >> Sander
>> >>
>> >> Tuesday, September 23, 2014, 3:19:41 PM, you wrote:
>> >>
>> >> > Hi Peter / Sander,
>> >>
>> >> > Yes, I have AMD GPU passthru working as both primary and secondary
>> >> passthru.  Secondary was easy but primary is a bit tricky.
>> >>
>> >> > Getting on to your questions;
>> >>
>> >> >> Is there any specific reason you're using Xen 4.2 rather than 4.4.1?
>> >>
>> >> > I am working on a project that is based on Xen 4.2 (I can't say any
>> >> > more than
>> >> that).  I have looked at some of the more recent versions just to
>> >> check if some of the bugs that I have seen have been fixed but I have
>> >> not studied the newer versions in detail.  At some point in time in
>> >> the future I would like will make the jump to a more recent version but I don't
>> know the scheduling of that.
>> >>
>> >> >> In 4.2, using xl or xm?
>> >>
>> >> > xl
>> >>
>> >> >> qemu-traditional (with rombios) or "upstream"
>> >>
>> >> > qemu-traditional
>> >>
>> >> >> Primary or secondary passthrough?
>> >>
>> >> > Both but I am focusing on secondary right now.
>> >>
>> >> >> Presumably 64 bit versions of Windows?
>> >>
>> >> > 32 bit and 64 bit Win7.  I have tested Win8.1 and it works but my
>> >> > focus is currently Win7
>> >>
>> >> >> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
>> >>
>> >> > Awesome.  My goal right now is obtaining stability on Xen 4.2.
>> >> > Since 4.2 is
>> >> past its feature cutoff I won't be able to submit any open source changes for
>> it.
>> >> I would like to eventually work with the community to get passthru
>> >> working with a recent version of "upstream".
>> >>
>> >> > Thanks,
>> >> > Kelly
>> >>
>> >>
>> >>
>> >> >> -----Original Message-----
>> >> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> >> >> Sent: Monday, September 22, 2014 8:38 AM
>> >> >> To: Peter Kay
>> >> >> Cc: xen-devel@lists.xen.org; Zytaruk, Kelly
>> >> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> >> >>
>> >> >>
>> >> >> Monday, September 22, 2014, 2:16:58 PM, you wrote:
>> >> >>
>> >> >> > Hi Kelly, list
>> >> >>
>> >> >> > I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9.
>> >> >> > I've been
>> >> >> less than successful getting passthrough working at all in Xen
>> >> >> (although it's fine in KVM primary passthrough as long as the BIOS
>> >> >> is supplied as a file). Could I confirm the following :
>> >> >>
>> >> >> > Is there any specific reason you're using Xen 4.2 rather than
>> >> >> > 4.4.1? I know in
>> >> >> some ways 4.4 suffers as it's now xl only and some of the xm
>> >> >> functionality has not come across.
>> >> >>
>> >> >> > In 4.2, using xl or xm?
>> >> >>
>> >> >> Another interesting question/aspect would be qemu-traditional
>> >> >> (with
>> >> >> rombios) or "upstream" (with seabios) ?
>> >> >>
>> >> >> > Primary or secondary passthrough?
>> >> >>
>> >> >> > Presumably 64 bit versions of Windows?
>> >> >>
>> >> >> > My system is a bit old (Core2Quad) but as mentioned AMD
>> >> >> > passthrough works
>> >> >> in KVM but I've found it tricky in Xen.
>> >> >>
>> >> >> > I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
>> >> >>
>> >> >> > Thanks
>> >> >>
>> >> >> > Peter
>> >> >>
>> >> >>
>> >>
>> >>
>> 
>> 


[-- Attachment #2: dmesg-firstboot.txt --]
[-- Type: text/plain, Size: 53637 bytes --]

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.17.0-rc5-20140920-vanilla+ (root@xbmc13sid) (gcc version 4.9.1 (Debian 4.9.1-4) ) #1 SMP Sat Sep 20 22:03:11 CEST 2014
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.17.0-rc5-20140920-vanilla+ root=UUID=4b432b33-87ec-4522-8b10-5dba3f49099e ro debug loglevel=7 console=tty1 console=ttyS0 slub_debug radeon.dpm=1 radeon.hard_reset=1 radeon.always_post=1 systemd.log_level=warning
[    0.000000] tseg: 0000000000
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003f7fefff] usable
[    0.000000] BIOS-e820: [mem 0x000000003f7ff000-0x000000003f7fffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.4 present.
[    0.000000] DMI: Xen HVM domU, BIOS 4.5-unstable 09/23/2014
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.5.
[    0.000000] Xen Platform PCI: I/O protocol version 1
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root= kernel command line option
[    0.000000] HVMOP_pagetable_dying not supported
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] AGP: No AGP bridge found
[    0.000000] e820: last_pfn = 0x3f7ff max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: write-back
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF write-combining
[    0.000000]   C0000-FFFFF write-back
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 0000E0000000 mask FFFFE0000000 uncachable
[    0.000000]   1 disabled
[    0.000000]   2 disabled
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] TOM2: 0000000560000000 aka 22016M
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [mem 0x000f0e40-0x000f0e4f] mapped at [ffff8800000f0e40]
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] BRK [0x02e0b000, 0x02e0bfff] PGTABLE
[    0.000000] BRK [0x02e0c000, 0x02e0cfff] PGTABLE
[    0.000000] BRK [0x02e0d000, 0x02e0dfff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x3f400000-0x3f5fffff]
[    0.000000]  [mem 0x3f400000-0x3f5fffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x3c000000-0x3f3fffff]
[    0.000000]  [mem 0x3c000000-0x3f3fffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x00100000-0x3bffffff]
[    0.000000]  [mem 0x00100000-0x001fffff] page 4k
[    0.000000]  [mem 0x00200000-0x3bffffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x3f600000-0x3f7fefff]
[    0.000000]  [mem 0x3f600000-0x3f7fefff] page 4k
[    0.000000] BRK [0x02e0e000, 0x02e0efff] PGTABLE
[    0.000000] RAMDISK: [mem 0x36f76000-0x377b2fff]
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000000F0D90 000024 (v02 Xen   )
[    0.000000] ACPI: XSDT 0x00000000FC00A120 000054 (v01 Xen    HVM      00000000 HVML 00000000)
[    0.000000] ACPI: FACP 0x00000000FC009A50 0000F4 (v04 Xen    HVM      00000000 HVML 00000000)
[    0.000000] ACPI: DSDT 0x00000000FC0012E0 0086F0 (v02 Xen    HVM      00000000 INTL 20100528)
[    0.000000] ACPI: FACS 0x00000000FC0012A0 000040
[    0.000000] ACPI: APIC 0x00000000FC009B50 000460 (v02 Xen    HVM      00000000 HVML 00000000)
[    0.000000] ACPI: HPET 0x00000000FC00A030 000038 (v01 Xen    HVM      00000000 HVML 00000000)
[    0.000000] ACPI: WAET 0x00000000FC00A070 000028 (v01 Xen    HVM      00000000 HVML 00000000)
[    0.000000] ACPI: SSDT 0x00000000FC00A0A0 000031 (v02 Xen    HVM      00000000 INTL 20100528)
[    0.000000] ACPI: SSDT 0x00000000FC00A0E0 000031 (v02 Xen    HVM      00000000 INTL 20100528)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000003f7fefff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x3f7fefff]
[    0.000000]   NODE_DATA [mem 0x3f7f4000-0x3f7fefff]
[    0.000000]  [ffffea0000000000-ffffea0000ffffff] PMD -> [ffff88003de00000-ffff88003edfffff] on node 0
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0x3f7fefff]
[    0.000000] On node 0 totalpages: 259997
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 21 pages reserved
[    0.000000]   DMA zone: 3998 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 4000 pages used for memmap
[    0.000000]   DMA32 zone: 255999 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x1e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x20] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x22] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x24] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x26] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x28] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x2a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x2c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x2e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x30] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x32] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x34] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x36] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x38] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x3a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x3c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x3e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x40] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x21] lapic_id[0x42] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x22] lapic_id[0x44] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x23] lapic_id[0x46] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x24] lapic_id[0x48] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x25] lapic_id[0x4a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x26] lapic_id[0x4c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x27] lapic_id[0x4e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x28] lapic_id[0x50] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x29] lapic_id[0x52] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2a] lapic_id[0x54] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2b] lapic_id[0x56] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2c] lapic_id[0x58] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2d] lapic_id[0x5a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2e] lapic_id[0x5c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2f] lapic_id[0x5e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x30] lapic_id[0x60] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x31] lapic_id[0x62] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x32] lapic_id[0x64] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x33] lapic_id[0x66] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x34] lapic_id[0x68] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x35] lapic_id[0x6a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x36] lapic_id[0x6c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x37] lapic_id[0x6e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x38] lapic_id[0x70] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x39] lapic_id[0x72] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3a] lapic_id[0x74] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3b] lapic_id[0x76] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3c] lapic_id[0x78] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3d] lapic_id[0x7a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3e] lapic_id[0x7c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3f] lapic_id[0x7e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x40] lapic_id[0x80] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x41] lapic_id[0x82] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x42] lapic_id[0x84] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x43] lapic_id[0x86] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x44] lapic_id[0x88] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x45] lapic_id[0x8a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x46] lapic_id[0x8c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x47] lapic_id[0x8e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x48] lapic_id[0x90] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x49] lapic_id[0x92] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4a] lapic_id[0x94] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4b] lapic_id[0x96] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4c] lapic_id[0x98] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4d] lapic_id[0x9a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4e] lapic_id[0x9c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4f] lapic_id[0x9e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x50] lapic_id[0xa0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x51] lapic_id[0xa2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x52] lapic_id[0xa4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x53] lapic_id[0xa6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x54] lapic_id[0xa8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x55] lapic_id[0xaa] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x56] lapic_id[0xac] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x57] lapic_id[0xae] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x58] lapic_id[0xb0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x59] lapic_id[0xb2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5a] lapic_id[0xb4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5b] lapic_id[0xb6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5c] lapic_id[0xb8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5d] lapic_id[0xba] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5e] lapic_id[0xbc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5f] lapic_id[0xbe] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x60] lapic_id[0xc0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x61] lapic_id[0xc2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x62] lapic_id[0xc4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x63] lapic_id[0xc6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x64] lapic_id[0xc8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x65] lapic_id[0xca] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x66] lapic_id[0xcc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x67] lapic_id[0xce] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x68] lapic_id[0xd0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x69] lapic_id[0xd2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6a] lapic_id[0xd4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6b] lapic_id[0xd6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6c] lapic_id[0xd8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6d] lapic_id[0xda] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6e] lapic_id[0xdc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6f] lapic_id[0xde] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x70] lapic_id[0xe0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x71] lapic_id[0xe2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x72] lapic_id[0xe4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x73] lapic_id[0xe6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x74] lapic_id[0xe8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x75] lapic_id[0xea] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x76] lapic_id[0xec] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x77] lapic_id[0xee] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x78] lapic_id[0xf0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x79] lapic_id[0xf2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7a] lapic_id[0xf4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7b] lapic_id[0xf6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7c] lapic_id[0xf8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7d] lapic_id[0xfa] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7e] lapic_id[0xfc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7f] lapic_id[0xfe] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ5 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ10 used by override.
[    0.000000] ACPI: IRQ11 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] smpboot: 128 Processors exceeds NR_CPUS limit of 8
[    0.000000] smpboot: Allowing 8 CPUs, 5 hotplug CPUs
[    0.000000] e820: [mem 0x3f800000-0xfbffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003f400000 s83520 r8192 d22976 u262144
[    0.000000] pcpu-alloc: s83520 r8192 d22976 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    0.000000] xen: PV spinlocks enabled
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 255912
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.17.0-rc5-20140920-vanilla+ root=UUID=4b432b33-87ec-4522-8b10-5dba3f49099e ro debug loglevel=7 console=tty1 console=ttyS0 slub_debug radeon.dpm=1 radeon.hard_reset=1 radeon.always_post=1 systemd.log_level=warning
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] AGP: Checking aperture...
[    0.000000] AGP: No AGP bridge found
[    0.000000] Memory: 983224K/1039988K available (10175K kernel code, 981K rwdata, 4028K rodata, 1108K init, 14292K bss, 56764K reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] 	Additional per-CPU info printed with stalls.
[    0.000000] NR_IRQS:4352 nr_irqs:896 0
[    0.000000] xen:events: Using FIFO-based ABI
[    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty1] enabled
[    0.000000] console [ttyS0] enabled
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.000000] ... MAX_LOCKDEP_CHAINS:      65536
[    0.000000] ... CHAINHASH_SIZE:          32768
[    0.000000]  memory used by lock dependency info: 8159 kB
[    0.000000]  per task-struct memory footprint: 1920 bytes
[    0.000000] kmemleak: Kernel memory leak detector disabled
[    0.000000] hpet clockevent registered
[    0.000000] tsc: Detected 3200.172 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.033333] Calibrating delay loop (skipped), value calculated using timer frequency.. 6402.02 BogoMIPS (lpj=10667240)
[    0.060005] pid_max: default: 32768 minimum: 301
[    0.073403] ACPI: Core revision 20140724
[    0.270371] ACPI: All ACPI Tables successfully acquired
[    0.287077] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.307044] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.326851] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
[    0.346705] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
[    0.367502] Initializing cgroup subsys freezer
[    0.380030] Initializing cgroup subsys blkio
[    0.390287] CPU: Physical Processor ID: 0
[    0.403338] CPU: Processor Core ID: 0
[    0.413342] mce: CPU supports 2 MCE banks
[    0.426704] numa_add_cpu cpu 0 node 0: mask now 0
[    0.426709] Last level iTLB entries: 4KB 512, 2MB 16, 4MB 8
[    0.426709] Last level dTLB entries: 4KB 512, 2MB 128, 4MB 64, 1GB 0
[    0.456986] Freeing SMP alternatives memory: 32K (ffffffff8200c000 - ffffffff82014000)
[    0.486341] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.535245] smpboot: CPU0: AMD Phenom(tm) II X6 1090T Processor (fam: 10, model: 0a, stepping: 00)
[    0.560026] Xen: using vcpuop timer interface
[    0.560035] installing Xen timer for CPU 0
[    0.573617] cpu 0 spinlock event irq 53
[    0.577135] Performance Events: Broken PMU hardware detected, using software events only.
[    0.583343] Failed to access perfctr msr (MSR c0010004 is 0)
[    0.588128] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.590514] installing Xen timer for CPU 1
[    0.593585] x86: Booting SMP configuration:
[    0.596679] .... node  #0, CPUs:      #1
[    0.033333] numa_add_cpu cpu 1 node 0: mask now 0-1
[    0.700274] cpu 1 spinlock event irq 59
[    0.703806] installing Xen timer for CPU 2
[    0.706860]  #2
[    0.033333] numa_add_cpu cpu 2 node 0: mask now 0-2
[    0.807118] cpu 2 spinlock event irq 65
[    0.810083] x86: Booted up 1 node, 3 CPUs
[    0.813343] smpboot: Total of 3 processors activated (19232.02 BogoMIPS)
[    0.820412] devtmpfs: initialized
[    0.834328] xor: measuring software checksum speed
[    0.880453]    prefetch64-sse:   812.400 MB/sec
[    0.926849]    generic_sse:   810.000 MB/sec
[    0.940014] xor: using function: prefetch64-sse (812.400 MB/sec)
[    0.957317] NET: Registered protocol family 16
[    0.973631] xenbus: xs_reset_watches failed: -38
[    0.986749] cpuidle: using governor ladder
[    0.996683] cpuidle: using governor menu
[    1.016974] ACPI: bus type PCI registered
[    1.026677] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    1.046672] PCI: Using configuration type 1 for base access
[    1.060008] PCI: Using configuration type 1 for extended access
[    1.193413] raid6: sse2x1    2723 MB/s
[    1.253410] raid6: sse2x2    3713 MB/s
[    1.313429] raid6: sse2x4    3575 MB/s
[    1.316768] raid6: using algorithm sse2x2 (3713 MB/s)
[    1.320080] raid6: using intx1 recovery algorithm
[    1.323726] ACPI: Added _OSI(Module Device)
[    1.326753] ACPI: Added _OSI(Processor Device)
[    1.330079] ACPI: Added _OSI(3.0 _SCP Extensions)
[    1.333411] ACPI: Added _OSI(Processor Aggregator Device)
[    1.462914] ACPI: Interpreter enabled
[    1.463386] ACPI: (supports S0 S5)
[    1.466677] ACPI: Using IOAPIC for interrupt routing
[    1.470388] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    1.632993] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    1.646711] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    1.670139] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[    1.694200] pci_bus 0000:00: dev 01, created physical slot 1
[    1.694355] pci_bus 0000:00: dev 02, created physical slot 2
[    1.694507] pci_bus 0000:00: dev 03, created physical slot 3
[    1.694659] pci_bus 0000:00: dev 04, created physical slot 4
[    1.694838] pci_bus 0000:00: dev 05, created physical slot 5
[    1.695027] pci_bus 0000:00: dev 06, created physical slot 6
[    1.695202] pci_bus 0000:00: dev 07, created physical slot 7
[    1.695374] pci_bus 0000:00: dev 08, created physical slot 8
[    1.695553] pci_bus 0000:00: dev 09, created physical slot 9
[    1.695725] pci_bus 0000:00: dev 0a, created physical slot 10
[    1.695902] pci_bus 0000:00: dev 0b, created physical slot 11
[    1.696080] pci_bus 0000:00: dev 0c, created physical slot 12
[    1.696256] pci_bus 0000:00: dev 0d, created physical slot 13
[    1.696436] pci_bus 0000:00: dev 0e, created physical slot 14
[    1.696608] pci_bus 0000:00: dev 0f, created physical slot 15
[    1.696768] pci_bus 0000:00: dev 10, created physical slot 16
[    1.696922] pci_bus 0000:00: dev 11, created physical slot 17
[    1.697074] pci_bus 0000:00: dev 12, created physical slot 18
[    1.697236] pci_bus 0000:00: dev 13, created physical slot 19
[    1.697387] pci_bus 0000:00: dev 14, created physical slot 20
[    1.697538] pci_bus 0000:00: dev 15, created physical slot 21
[    1.697690] pci_bus 0000:00: dev 16, created physical slot 22
[    1.697852] pci_bus 0000:00: dev 17, created physical slot 23
[    1.698008] pci_bus 0000:00: dev 18, created physical slot 24
[    1.698162] pci_bus 0000:00: dev 19, created physical slot 25
[    1.698316] pci_bus 0000:00: dev 1a, created physical slot 26
[    1.698469] pci_bus 0000:00: dev 1b, created physical slot 27
[    1.698621] pci_bus 0000:00: dev 1c, created physical slot 28
[    1.698772] pci_bus 0000:00: dev 1d, created physical slot 29
[    1.698924] pci_bus 0000:00: dev 1e, created physical slot 30
[    1.699087] pci_bus 0000:00: dev 1f, created physical slot 31
[    1.700327] acpiphp: Slot [3] registered
[    1.710327] acpiphp: Slot [4] registered
[    1.723690] acpiphp: Slot [5] registered
[    1.733666] acpiphp: Slot [6] registered
[    1.746987] acpiphp: Slot [7] registered
[    1.757013] acpiphp: Slot [8] registered
[    1.770387] acpiphp: Slot [9] registered
[    1.780350] acpiphp: Slot [10] registered
[    1.793731] acpiphp: Slot [11] registered
[    1.803710] acpiphp: Slot [12] registered
[    1.817060] acpiphp: Slot [13] registered
[    1.830439] acpiphp: Slot [14] registered
[    1.840338] acpiphp: Slot [15] registered
[    1.853841] acpiphp: Slot [16] registered
[    1.867028] acpiphp: Slot [17] registered
[    1.877235] acpiphp: Slot [18] registered
[    1.890380] acpiphp: Slot [19] registered
[    1.903700] acpiphp: Slot [20] registered
[    1.913698] acpiphp: Slot [21] registered
[    1.926978] acpiphp: Slot [22] registered
[    1.937333] acpiphp: Slot [23] registered
[    1.950423] acpiphp: Slot [24] registered
[    1.963878] acpiphp: Slot [25] registered
[    1.973739] acpiphp: Slot [26] registered
[    1.993752] acpiphp: Slot [27] registered
[    2.007100] acpiphp: Slot [28] registered
[    2.020662] acpiphp: Slot [29] registered
[    2.033884] acpiphp: Slot [30] registered
[    2.047029] acpiphp: Slot [31] registered
[    2.060093] PCI host bridge to bus 0000:00
[    2.073357] pci_bus 0000:00: root bus resource [bus 00-ff]
[    2.086681] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    2.103369] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    2.120024] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    2.140026] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbffffff]
[    2.160012] pci_bus 0000:00: scanning bus
[    2.160387] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
[    2.161973] pci 0000:00:00.0: calling quirk_mmio_always_on+0x0/0x10
[    2.166930] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
[    2.172756] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
[    2.191975] pci 0000:00:01.1: reg 0x20: [io  0xc260-0xc26f]
[    2.200236] pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
[    2.223349] pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io  0x03f6]
[    2.240007] pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
[    2.260014] pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io  0x0376]
[    2.279050] pci 0000:00:01.2: [8086:7020] type 00 class 0x0c0300
[    2.298673] pci 0000:00:01.2: reg 0x20: [io  0xc240-0xc25f]
[    2.311733] pci 0000:00:01.3: [8086:7113] type 00 class 0x068000
[    2.311826] pci 0000:00:01.3: calling acpi_pm_check_blacklist+0x0/0x40
[    2.315515] pci 0000:00:01.3: calling quirk_piix4_acpi+0x0/0x140
[    2.315591] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX4 ACPI
[    2.333405] pci 0000:00:01.3: quirk: [io  0xb100-0xb10f] claimed by PIIX4 SMB
[    2.353751] pci 0000:00:01.3: calling pci_fixup_piix4_acpi+0x0/0x10
[    2.356674] pci 0000:00:02.0: [5853:0001] type 00 class 0xff8000
[    2.363345] pci 0000:00:02.0: reg 0x10: [io  0xc000-0xc0ff]
[    2.370013] pci 0000:00:02.0: reg 0x14: [mem 0xf2000000-0xf2ffffff pref]
[    2.406080] pci 0000:00:03.0: [1013:00b8] type 00 class 0x030000
[    2.413374] pci 0000:00:03.0: reg 0x10: [mem 0xf0000000-0xf1ffffff pref]
[    2.423373] pci 0000:00:03.0: reg 0x14: [mem 0xf30b0000-0xf30b0fff]
[    2.460014] pci 0000:00:03.0: reg 0x30: [mem 0xf30a0000-0xf30affff pref]
[    2.463746] pci 0000:00:05.0: [1002:6759] type 00 class 0x030000
[    2.493355] pci 0000:00:05.0: reg 0x10: [mem 0xe0000000-0xefffffff 64bit pref]
[    2.526722] pci 0000:00:05.0: reg 0x18: [mem 0xf3060000-0xf307ffff 64bit]
[    2.556691] pci 0000:00:05.0: reg 0x20: [io  0xc100-0xc1ff]
[    2.616688] pci 0000:00:05.0: reg 0x30: [mem 0xf3080000-0xf309ffff pref]
[    2.619093] pci 0000:00:05.0: supports D1 D2
[    2.619999] pci_bus 0000:00: fixups for bus
[    2.619999] pci_bus 0000:00: bus scan returning with max=00
[    2.619999] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
[    2.621726] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    2.626666] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    2.629999] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
[    2.636666] ACPI: Enabled 2 GPEs in block 00 to 0F
[    2.637063] xen:balloon: Initialising balloon driver
[    2.639999] vgaarb: setting as boot device: PCI:0000:00:03.0
[    2.639999] vgaarb: device added: PCI:0000:00:03.0,decodes=io+mem,owns=io+mem,locks=none
[    2.644175] vgaarb: device added: PCI:0000:00:05.0,decodes=io+mem,owns=io+mem,locks=none
[    2.646735] vgaarb: loaded
[    2.649999] vgaarb: bridge control possible 0000:00:05.0
[    2.650073] vgaarb: no bridge control possible 0000:00:03.0
[    2.653333] SCSI subsystem initialized
[    2.653611] libata version 3.00 loaded.
[    2.654079] ACPI: bus type USB registered
[    2.656666] usbcore: registered new interface driver usbfs
[    2.656984] usbcore: registered new interface driver hub
[    2.659999] usbcore: registered new device driver usb
[    2.662708] Linux video capture interface: v2.00
[    2.663426] pps_core: LinuxPPS API ver. 1 registered
[    2.663861] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    2.666800] PTP clock support registered
[    2.670040] PCI: Using ACPI for IRQ routing
[    2.670040] PCI: pci_cache_line_size set to 64 bytes
[    2.670247] pci 0000:00:01.1: BAR 0: reserving [io  0x01f0-0x01f7 flags 0x110] (d=0, p=0)
[    2.670252] pci 0000:00:01.1: BAR 1: reserving [io  0x03f6 flags 0x110] (d=0, p=0)
[    2.670254] pci 0000:00:01.1: BAR 2: reserving [io  0x0170-0x0177 flags 0x110] (d=0, p=0)
[    2.670256] pci 0000:00:01.1: BAR 3: reserving [io  0x0376 flags 0x110] (d=0, p=0)
[    2.670258] pci 0000:00:01.1: BAR 4: reserving [io  0xc260-0xc26f flags 0x40101] (d=0, p=0)
[    2.670327] pci 0000:00:01.2: BAR 4: reserving [io  0xc240-0xc25f flags 0x40101] (d=0, p=0)
[    2.670470] pci 0000:00:02.0: BAR 0: reserving [io  0xc000-0xc0ff flags 0x40101] (d=0, p=0)
[    2.670472] pci 0000:00:02.0: BAR 1: reserving [mem 0xf2000000-0xf2ffffff flags 0x42208] (d=0, p=0)
[    2.670540] pci 0000:00:03.0: BAR 0: reserving [mem 0xf0000000-0xf1ffffff flags 0x42208] (d=0, p=0)
[    2.670542] pci 0000:00:03.0: BAR 1: reserving [mem 0xf30b0000-0xf30b0fff flags 0x40200] (d=0, p=0)
[    2.670631] pci 0000:00:05.0: BAR 0: reserving [mem 0xe0000000-0xefffffff flags 0x14220c] (d=0, p=0)
[    2.670633] pci 0000:00:05.0: BAR 2: reserving [mem 0xf3060000-0xf307ffff flags 0x140204] (d=0, p=0)
[    2.670635] pci 0000:00:05.0: BAR 4: reserving [io  0xc100-0xc1ff flags 0x40101] (d=0, p=0)
[    2.671430] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff]
[    2.671451] e820: reserve RAM buffer [mem 0x3f7ff000-0x3fffffff]
[    2.673168] Bluetooth: Core ver 2.19
[    2.673354] NET: Registered protocol family 31
[    2.673354] Bluetooth: HCI device and connection manager initialized
[    2.676666] Bluetooth: HCI socket layer initialized
[    2.676700] Bluetooth: L2CAP socket layer initialized
[    2.679999] Bluetooth: SCO socket layer initialized
[    2.680362] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[    2.683333] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    2.689999] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[    2.690226] Switched to clocksource xen
[    2.693333] FS-Cache: Loaded
[    2.714006] pnp: PnP ACPI init
[    2.723170] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
[    2.741613] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[    2.742416] system 00:01: [io  0x08a0-0x08a3] has been reserved
[    2.758267] system 00:01: [io  0x0cc0-0x0ccf] has been reserved
[    2.774303] system 00:01: [io  0x04d0-0x04d1] has been reserved
[    2.790211] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
[    2.790463] xen: --> pirq=16 -> irq=8 (gsi=8)
[    2.790667] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active)
[    2.790936] xen: --> pirq=17 -> irq=12 (gsi=12)
[    2.791119] pnp 00:03: Plug and Play ACPI device, IDs PNP0f13 (active)
[    2.791339] xen: --> pirq=18 -> irq=1 (gsi=1)
[    2.791546] pnp 00:04: Plug and Play ACPI device, IDs PNP0303 PNP030b (active)
[    2.791775] xen: --> pirq=19 -> irq=6 (gsi=6)
[    2.791790] pnp 00:05: [dma 2]
[    2.791977] pnp 00:05: Plug and Play ACPI device, IDs PNP0700 (active)
[    2.792322] xen: --> pirq=20 -> irq=4 (gsi=4)
[    2.792507] pnp 00:06: Plug and Play ACPI device, IDs PNP0501 (active)
[    2.793554] system 00:07: [io  0xae00-0xae0f] has been reserved
[    2.809910] system 00:07: [io  0xb044-0xb047] has been reserved
[    2.825684] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    2.828307] pnp: PnP ACPI: found 8 devices
[    2.870863] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    2.870868] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    2.870871] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    2.870873] pci_bus 0000:00: resource 7 [mem 0xe0000000-0xfbffffff]
[    2.871020] NET: Registered protocol family 2
[    2.884007] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[    2.903996] TCP bind hash table entries: 8192 (order: 7, 524288 bytes)
[    2.922504] TCP: Hash tables configured (established 8192 bind 8192)
[    2.940059] TCP: reno registered
[    2.949893] UDP hash table entries: 512 (order: 4, 81920 bytes)
[    2.966208] UDP-Lite hash table entries: 512 (order: 4, 81920 bytes)
[    2.983818] NET: Registered protocol family 1
[    2.997019] pci 0000:00:00.0: calling quirk_natoma+0x0/0x40
[    2.997022] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    3.014637] pci 0000:00:00.0: calling quirk_passive_release+0x0/0x90
[    3.014722] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    3.031644] pci 0000:00:01.0: calling quirk_isa_dma_hangs+0x0/0x40
[    3.031649] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    3.049329] pci 0000:00:01.2: calling quirk_usb_early_handoff+0x0/0x6c0
[    3.053843] xen: --> pirq=21 -> irq=23 (gsi=23)
[    3.061169] pci 0000:00:03.0: calling pci_fixup_video+0x0/0xd0
[    3.061257] pci 0000:00:03.0: Video device with shadowed ROM
[    3.061330] pci 0000:00:05.0: calling pci_fixup_video+0x0/0xd0
[    3.061419] PCI: CLS 0 bytes, default 64
[    3.061780] Trying to unpack rootfs image as initramfs...
[    3.259590] Freeing initrd memory: 8436K (ffff880036f76000 - ffff8800377b3000)
[    3.450312] DMA-API: preallocated 65536 debug entries
[    3.464533] DMA-API: debugging enabled by kernel config
[    3.484304] Scanning for low memory corruption every 60 seconds
[    3.508599] sha1_ssse3: Neither AVX nor AVX2 nor SSSE3 is available/usable.
[    3.529765] futex hash table entries: 2048 (order: 6, 262144 bytes)
[    3.547224] audit: initializing netlink subsys (disabled)
[    3.562258] audit: type=2000 audit(1411510159.082:1): initialized
[    3.579879] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    3.652439] VFS: Disk quotas dquot_6.5.2
[    3.664338] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    3.693943] ntfs: driver 2.1.30 [Flags: R/W].
[    3.709288] fuse init (API version 7.23)
[    3.727078] gfs2: GFS2 installed
[    3.738388] ceph: loaded (mds proto 32)
[    3.749374] msgmni has been set to 1936
[    3.764114] bounce: pool size: 64 pages
[    3.775784] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[    3.794658] io scheduler noop registered
[    3.806261] io scheduler deadline registered
[    3.819514] io scheduler cfq registered (default)
[    3.832878] start plist test
[    3.834079] end plist test
[    3.834320] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
[    3.848982] crc32: self tests passed, processed 225944 bytes in 103212 nsec
[    3.868178] crc32c: CRC_LE_BITS = 64
[    3.878819] crc32c: self tests passed, processed 225944 bytes in 53558 nsec
[    3.906554] crc32_combine: 8373 self tests passed
[    3.929739] crc32c_combine: 8373 self tests passed
[    3.944005] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    3.960429] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    3.980471] cpcihp_zt5550: ZT5550 CompactPCI Hot Plug Driver version: 0.2
[    3.998764] cpcihp_generic: Generic port I/O CompactPCI Hot Plug Driver version: 0.1
[    4.020970] cpcihp_generic: not configured, disabling.
[    4.035067] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    4.068508] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed
[    4.087846] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[    4.110079] ACPI: Power Button [PWRF]
[    4.121354] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
[    4.142247] ACPI: Sleep Button [SLPF]
[    4.156098] xen:xen_evtchn: Event-channel device installed
[    4.177795] xen: --> pirq=22 -> irq=24 (gsi=24)
[    4.178211] xen:grant_table: Grant tables using version 1 layout
[    4.201298] Grant table initialized
[    4.217992] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    4.284416] 00:06: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    4.309847] Linux agpgart interface v0.103
[    4.322529] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds).
[    4.346649] [drm] Initialized drm 1.1.0 20060810
[    4.359722] [drm] radeon kernel modesetting enabled.
[    4.380435] xen: --> pirq=32 -> irq=36 (gsi=36)
[    4.383891] [drm] initializing kernel modesetting (TURKS 0x1002:0x6759 0x174B:0xE193).
[    4.405597] [drm] register mmio base: 0xF3060000
[    4.418262] [drm] register mmio size: 131072
[    4.559911] ATOM BIOS: ELIXIR
[    4.569063] [drm] GPU not posted. posting now...
[    4.585542] radeon 0000:00:05.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
[    4.609664] radeon 0000:00:05.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
[    4.632790] [drm] Detected VRAM RAM=1024M, BAR=256M
[    4.645764] [drm] RAM width 128bits DDR
[    4.657536] [TTM] Zone  kernel: Available graphics memory: 495846 kiB
[    4.674887] [TTM] Initializing pool allocator
[    4.686873] [TTM] Initializing DMA pool allocator
[    4.700414] [drm] radeon: 1024M of VRAM memory ready
[    4.714601] [drm] radeon: 1024M of GTT memory ready.
[    4.728693] [drm] Loading TURKS Microcode
[    4.740926] [drm] Internal thermal controller with fan control
[    4.757494] == power state 0 ==
[    4.766830] 	ui class: none
[    4.776832] 	internal class: boot 
[    4.789625] 	caps: 
[    4.797945] 	uvd    vclk: 0 dclk: 0
[    4.808191] 		power level 0    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    4.827523] 		power level 1    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    4.845356] 		power level 2    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    4.863453] 	status: c r b 
[    4.876650] == power state 1 ==
[    4.885966] 	ui class: performance
[    4.899288] 	internal class: none
[    4.913421] 	caps: 
[    4.921725] 	uvd    vclk: 0 dclk: 0
[    4.932150] 		power level 0    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    4.950751] 		power level 1    sclk: 40000 mclk: 66700 vddc: 1000 vddci: 0
[    4.969031] 		power level 2    sclk: 65000 mclk: 66700 vddc: 1050 vddci: 0
[    4.990583] 	status: 
[    4.999213] == power state 2 ==
[    5.008610] 	ui class: none
[    5.018321] 	internal class: uvd 
[    5.032166] 	caps: video 
[    5.042359] 	uvd    vclk: 70000 dclk: 56000
[    5.054199] 		power level 0    sclk: 65000 mclk: 66700 vddc: 1050 vddci: 0
[    5.072569] 		power level 1    sclk: 65000 mclk: 66700 vddc: 1050 vddci: 0
[    5.090332] 		power level 2    sclk: 65000 mclk: 66700 vddc: 1050 vddci: 0
[    5.109115] 	status: 
[    5.122634] [drm] radeon: dpm initialized
[    5.134204] [drm] GART: num cpu pages 262144, num gpu pages 262144
[    5.154340] [drm] PCIE GART of 1024M enabled (table at 0x0000000000273000).
[    5.173215] radeon 0000:00:05.0: WB enabled
[    5.184876] radeon 0000:00:05.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff880039578c00
[    5.220481] radeon 0000:00:05.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff880039578c0c
[    5.251772] radeon 0000:00:05.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0xffffc90000432118
[    5.285519] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    5.304980] [drm] Driver supports precise vblank timestamp query.
[    5.321889] radeon 0000:00:05.0: xen: msi bound to pirq=87
[    5.321940] radeon 0000:00:05.0: xen: msi --> pirq=87 --> irq=68
[    5.322401] radeon 0000:00:05.0: radeon: using MSI.
[    5.337058] [drm] radeon: irq initialized.
[    5.370568] [drm] ring test on 0 succeeded in 2 usecs
[    5.383979] [drm] ring test on 3 succeeded in 2 usecs
[    5.585190] [drm] ring test on 5 succeeded in 2 usecs
[    5.599252] [drm] UVD initialized successfully.
[    5.614934] [drm] ib test on ring 0 succeeded in 0 usecs
[    5.629975] [drm] ib test on ring 3 succeeded in 0 usecs
[    5.797731] [drm] ib test on ring 5 succeeded
[    5.816397] [drm] Radeon Display Connectors
[    5.830108] [drm] Connector 0:
[    5.839965] [drm]   HDMI-A-1
[    5.848363] [drm]   HPD4
[    5.855863] [drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c
[    5.877128] [drm]   Encoders:
[    5.886149] [drm]     DFP1: INTERNAL_UNIPHY2
[    5.898826] [drm] Connector 1:
[    5.908299] [drm]   DVI-D-1
[    5.916427] [drm]   HPD1
[    5.924490] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c
[    5.945556] [drm]   Encoders:
[    5.954870] [drm]     DFP2: INTERNAL_UNIPHY
[    5.966387] [drm] Connector 2:
[    5.976125] [drm]   VGA-1
[    5.985043] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[    6.006135] [drm]   Encoders:
[    6.019032] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
[    6.037513] switching from power state:
[    6.053429] 	ui class: none
[    6.063696] 	internal class: boot 
[    6.075571] 	caps: 
[    6.083269] 	uvd    vclk: 0 dclk: 0
[    6.093065] 		power level 0    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    6.112931] 		power level 1    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    6.132145] 		power level 2    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    6.150053] 	status: c b 
[    6.160916] switching to power state:
[    6.172579] 	ui class: performance
[    6.183436] 	internal class: none
[    6.195427] 	caps: 
[    6.203115] 	uvd    vclk: 0 dclk: 0
[    6.213312] 		power level 0    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    6.233507] 		power level 1    sclk: 40000 mclk: 66700 vddc: 1000 vddci: 0
[    6.251957] 		power level 2    sclk: 65000 mclk: 66700 vddc: 1050 vddci: 0
[    6.271299] 	status: r 
[    6.342301] [drm] fb mappable at 0xE0474000
[    6.354112] [drm] vram apper at 0xE0000000
[    6.365543] [drm] size 7299072
[    6.375098] [drm] fb depth is 24
[    6.384408] [drm]    pitch is 6912
[    6.397236] switching from power state:
[    6.397243] 	ui class: performance
[    6.397245] 	internal class: none
[    6.397246] 	caps: 
[    6.397247] 	uvd    vclk: 0 dclk: 0
[    6.397252] 		power level 0    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    6.397253] 		power level 1    sclk: 40000 mclk: 66700 vddc: 1000 vddci: 0
[    6.397254] 		power level 2    sclk: 65000 mclk: 66700 vddc: 1050 vddci: 0
[    6.397256] 	status: c r 
[    6.397256] switching to power state:
[    6.397257] 	ui class: performance
[    6.397258] 	internal class: none
[    6.397259] 	caps: 
[    6.397260] 	uvd    vclk: 0 dclk: 0
[    6.397261] 		power level 0    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    6.397262] 		power level 1    sclk: 40000 mclk: 66700 vddc: 1000 vddci: 0
[    6.397262] 		power level 2    sclk: 65000 mclk: 66700 vddc: 1050 vddci: 0
[    6.397264] 	status: c r 
[    6.432988] Console: switching to colour frame buffer device 210x65
[    6.648148] radeon 0000:00:05.0: fb0: radeondrmfb frame buffer device
[    6.663827] radeon 0000:00:05.0: registered panic notifier
[    6.704243] [drm] Initialized radeon 2.40.0 20080528 for 0000:00:05.0 on minor 0
[    6.765104] brd: module loaded
[    6.783052] loop: module loaded
[    6.796772] Uniform Multi-Platform E-IDE driver
[    6.815271] piix 0000:00:01.1: IDE controller (0x8086:0x7010 rev 0x00)
[    6.819006] blkfront: xvda: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
[    6.851024] random: nonblocking pool is initialized
[    6.851053]  xvda: xvda1 xvda2 < xvda5 >
[    6.882597] piix 0000:00:01.1: not 100% native mode: will probe irqs later
[    6.901037]     ide0: BM-DMA at 0xc260-0xc267
[    6.912308]     ide1: BM-DMA at 0xc268-0xc26f
[    6.924359] Probing IDE interface ide0...
[    7.468189] Probing IDE interface ide1...
[    8.013477] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[    8.043945] ide1 at 0x170-0x177,0x376 on irq 15
[    8.055744] ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports
[    8.083690] ide-gd driver 1.18
[    8.095307] tun: Universal TUN/TAP device driver, 1.6
[    8.108913] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    8.125562] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[    8.144416] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    8.159759] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    8.174832] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[    8.190238] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.13-k
[    8.208260] igb: Copyright (c) 2007-2014 Intel Corporation.
[    8.222835] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.2-k
[    8.242617] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    8.258105] xen_netfront: Initialising Xen virtual ethernet driver
[    8.279705] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    8.296355] ehci-pci: EHCI PCI platform driver
[    8.313554] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    8.333834] ohci-pci: OHCI PCI platform driver
[    8.347078] uhci_hcd: USB Universal Host Controller Interface driver
[    8.372448] uhci_hcd 0000:00:01.2: enabling bus mastering
[    8.374953] uhci_hcd 0000:00:01.2: UHCI Host Controller
[    8.391148] uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1
[    8.415214] uhci_hcd 0000:00:01.2: irq 23, io base 0x0000c240
[    8.435562] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[    8.456849] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    8.476572] usb usb1: Product: UHCI Host Controller
[    8.490478] usb usb1: Manufacturer: Linux 3.17.0-rc5-20140920-vanilla+ uhci_hcd
[    8.511323] usb usb1: SerialNumber: 0000:00:01.2
[    8.526608] hub 1-0:1.0: USB hub found
[    8.537329] hub 1-0:1.0: 2 ports detected
[    8.551789] usbcore: registered new interface driver usblp
[    8.566917] usbcore: registered new interface driver usb-storage
[    8.583703] usbcore: registered new interface driver usbserial
[    8.600276] usbcore: registered new interface driver cp210x
[    8.615653] usbserial: USB Serial support registered for cp210x
[    8.632043] usbcore: registered new interface driver cypress_m8
[    8.648299] usbserial: USB Serial support registered for DeLorme Earthmate USB
[    8.667750] usbserial: USB Serial support registered for HID->COM RS232 Adapter
[    8.687977] usbserial: USB Serial support registered for Nokia CA-42 V2 Adapter
[    8.708110] usbcore: registered new interface driver mos7720
[    8.724309] usbserial: USB Serial support registered for Moschip 2 port adapter
[    8.744560] usbcore: registered new interface driver mos7840
[    8.760183] usbserial: USB Serial support registered for Moschip 7840/7820 USB Serial Driver
[    8.783000] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    8.811719] serio: i8042 KBD port at 0x60,0x64 irq 1
[    8.825636] serio: i8042 AUX port at 0x60,0x64 irq 12
[    8.840340] mousedev: PS/2 mouse device common for all mice
[    8.861279] input: Xen Virtual Keyboard as /devices/virtual/input/input3
[    8.863121] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[    8.916940] input: Xen Virtual Pointer as /devices/virtual/input/input6
[    8.939557] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[    8.957701] rtc_cmos 00:02: alarms up to one day, 114 bytes nvram, hpet irqs
[    8.978404] piix4_smbus 0000:00:01.3: SMBus Host Controller not enabled!
[    8.998878] lirc_dev: IR Remote Control driver registered, major 248 
[    9.016892] IR NEC protocol handler initialized
[    9.016969] usb 1-1: new full-speed USB device number 2 using uhci_hcd
[    9.049095] IR RC5(x/sz) protocol handler initialized
[    9.063417] IR RC6 protocol handler initialized
[    9.076707] IR JVC protocol handler initialized
[    9.090095] IR Sony protocol handler initialized
[    9.106436] IR SANYO protocol handler initialized
[    9.119576] IR Sharp protocol handler initialized
[    9.133325] IR MCE Keyboard/mouse protocol handler initialized
[    9.150261] IR LIRC bridge handler initialized
[    9.163614] IR XMP protocol handler initialized
[    9.177099] cx25821: driver version 0.0.106 loaded
[    9.178986] usb 1-1: New USB device found, idVendor=0627, idProduct=0001
[    9.178988] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=5
[    9.178989] usb 1-1: Product: QEMU USB Tablet
[    9.178990] usb 1-1: Manufacturer: QEMU
[    9.178991] usb 1-1: SerialNumber: 42
[    9.267355] usbcore: registered new interface driver pvrusb2
[    9.286292] pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
[    9.308531] pvrusb2: Debug mask is 31 (0x1f)
[    9.324798] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
[    9.344620] xen_wdt: Xen WatchDog Timer Driver v0.01
[    9.359414] xen_wdt: initialized (timeout=60s, nowayout=0)
[    9.377564] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com
[    9.403439] Bluetooth: Virtual HCI driver ver 1.5
[    9.417418] Bluetooth: HCI UART driver ver 2.2
[    9.432040] Bluetooth: HCI H4 protocol initialized
[    9.446083] Bluetooth: HCI BCSP protocol initialized
[    9.461738] Bluetooth: HCILL protocol initialized
[    9.475968] Bluetooth: HCIATH3K protocol initialized
[    9.491682] Bluetooth: HCI Three-wire UART (H5) protocol initialized
[    9.511110] usbcore: registered new interface driver bcm203x
[    9.527389] usbcore: registered new interface driver bpa10x
[    9.542924] usbcore: registered new interface driver bfusb
[    9.558471] usbcore: registered new interface driver btusb
[    9.574336] usbcore: registered new interface driver ath3k
[    9.591176] hidraw: raw HID events driver (C) Jiri Kosina
[    9.615269] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:01.2/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input7
[    9.648363] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Pointer [QEMU QEMU USB Tablet] on usb-0000:00:01.2-1/input0
[    9.681829] usbcore: registered new interface driver usbhid
[    9.699109] usbhid: USB HID core driver
[    9.711421] Netfilter messages via NETLINK v0.30.
[    9.725034] nfnl_acct: registering with nfnetlink.
[    9.739264] nf_conntrack version 0.5.0 (7747 buckets, 30988 max)
[    9.759475] ctnetlink v0.93: registering with nfnetlink.
[    9.779090] xt_time: kernel timezone is -0000
[    9.791582] ip_set: protocol 6
[    9.801736] IPVS: Registered protocols ()
[    9.815119] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
[    9.836398] IPVS: Creating netns size=1904 id=0
[    9.837093] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input5
[    9.882173] IPVS: ipvs loaded.
[    9.892048] ip_tables: (C) 2000-2006 Netfilter Core Team
[    9.907560] TCP: cubic registered
[    9.917392] NET: Registered protocol family 17
[    9.931228] Bridge firewalling registered
[    9.943410] Ebtables v2.0 registered
[    9.954096] Bluetooth: RFCOMM TTY layer initialized
[    9.967751] Bluetooth: RFCOMM socket layer initialized
[    9.982130] Bluetooth: RFCOMM ver 1.11
[    9.992838] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   10.007497] Bluetooth: BNEP filters: protocol multicast
[   10.022752] Bluetooth: BNEP socket layer initialized
[   10.036773] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[   10.052643] Bluetooth: HIDP socket layer initialized
[   10.066936] Key type ceph registered
[   10.078830] libceph: loaded (mon/osd proto 15/24)
[   10.095171] registered taskstats version 1
[   10.118359] Btrfs loaded
[   10.130750] xenbus_probe_frontend: Device with no driver: device/pci/0
[   10.149698] console [netcon0] enabled
[   10.161017] netconsole: network logging started
[   10.175435] rtc_cmos 00:02: setting system clock to 2014-09-23 22:09:28 UTC (1411510168)
[   10.201967] Freeing unused kernel memory: 1108K (ffffffff81ef7000 - ffffffff8200c000)
[   10.224064] Write protecting the kernel read-only data: 14336k
[   10.240726] Freeing unused kernel memory: 52K (ffff8800019f3000 - ffff880001a00000)
[   10.261969] Freeing unused kernel memory: 68K (ffff880001def000 - ffff880001e00000)
[   10.329930] systemd-udevd[1433]: starting version 208
[   10.723865] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[   11.575330] systemd[1]: Failed to insert module 'ipv6'
[   14.046625] systemd-udevd[1514]: starting version 208
[   14.915966] EXT4-fs (xvda1): re-mounted. Opts: errors=remount-ro
[   17.026094] systemd-journald[1498]: Received request to flush runtime journal from PID 1
[   18.578602] Adding 901116k swap on /dev/xvda5.  Priority:-1 extents:1 across:901116k SS
[   22.519021] vgaarb: device changed decodes: PCI:0000:00:05.0,olddecodes=io+mem,decodes=none:owns=io+mem

[-- Attachment #3: dmesg-secondboot.txt --]
[-- Type: text/plain, Size: 51640 bytes --]

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.17.0-rc5-20140920-vanilla+ (root@xbmc13sid) (gcc version 4.9.1 (Debian 4.9.1-4) ) #1 SMP Sat Sep 20 22:03:11 CEST 2014
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.17.0-rc5-20140920-vanilla+ root=UUID=4b432b33-87ec-4522-8b10-5dba3f49099e ro debug loglevel=7 console=tty1 console=ttyS0 slub_debug radeon.dpm=1 radeon.hard_reset=1 radeon.always_post=1 systemd.log_level=warning
[    0.000000] tseg: 0000000000
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003f7fefff] usable
[    0.000000] BIOS-e820: [mem 0x000000003f7ff000-0x000000003f7fffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.4 present.
[    0.000000] DMI: Xen HVM domU, BIOS 4.5-unstable 09/23/2014
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.5.
[    0.000000] Xen Platform PCI: I/O protocol version 1
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root= kernel command line option
[    0.000000] HVMOP_pagetable_dying not supported
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] AGP: No AGP bridge found
[    0.000000] e820: last_pfn = 0x3f7ff max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: write-back
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF write-combining
[    0.000000]   C0000-FFFFF write-back
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 0000E0000000 mask FFFFE0000000 uncachable
[    0.000000]   1 disabled
[    0.000000]   2 disabled
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] TOM2: 0000000560000000 aka 22016M
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [mem 0x000f0e40-0x000f0e4f] mapped at [ffff8800000f0e40]
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] BRK [0x02e0b000, 0x02e0bfff] PGTABLE
[    0.000000] BRK [0x02e0c000, 0x02e0cfff] PGTABLE
[    0.000000] BRK [0x02e0d000, 0x02e0dfff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x3f400000-0x3f5fffff]
[    0.000000]  [mem 0x3f400000-0x3f5fffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x3c000000-0x3f3fffff]
[    0.000000]  [mem 0x3c000000-0x3f3fffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x00100000-0x3bffffff]
[    0.000000]  [mem 0x00100000-0x001fffff] page 4k
[    0.000000]  [mem 0x00200000-0x3bffffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x3f600000-0x3f7fefff]
[    0.000000]  [mem 0x3f600000-0x3f7fefff] page 4k
[    0.000000] BRK [0x02e0e000, 0x02e0efff] PGTABLE
[    0.000000] RAMDISK: [mem 0x36f76000-0x377b2fff]
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000000F0D90 000024 (v02 Xen   )
[    0.000000] ACPI: XSDT 0x00000000FC00A120 000054 (v01 Xen    HVM      00000000 HVML 00000000)
[    0.000000] ACPI: FACP 0x00000000FC009A50 0000F4 (v04 Xen    HVM      00000000 HVML 00000000)
[    0.000000] ACPI: DSDT 0x00000000FC0012E0 0086F0 (v02 Xen    HVM      00000000 INTL 20100528)
[    0.000000] ACPI: FACS 0x00000000FC0012A0 000040
[    0.000000] ACPI: APIC 0x00000000FC009B50 000460 (v02 Xen    HVM      00000000 HVML 00000000)
[    0.000000] ACPI: HPET 0x00000000FC00A030 000038 (v01 Xen    HVM      00000000 HVML 00000000)
[    0.000000] ACPI: WAET 0x00000000FC00A070 000028 (v01 Xen    HVM      00000000 HVML 00000000)
[    0.000000] ACPI: SSDT 0x00000000FC00A0A0 000031 (v02 Xen    HVM      00000000 INTL 20100528)
[    0.000000] ACPI: SSDT 0x00000000FC00A0E0 000031 (v02 Xen    HVM      00000000 INTL 20100528)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000003f7fefff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x3f7fefff]
[    0.000000]   NODE_DATA [mem 0x3f7f4000-0x3f7fefff]
[    0.000000]  [ffffea0000000000-ffffea0000ffffff] PMD -> [ffff88003de00000-ffff88003edfffff] on node 0
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0x3f7fefff]
[    0.000000] On node 0 totalpages: 259997
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 21 pages reserved
[    0.000000]   DMA zone: 3998 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 4000 pages used for memmap
[    0.000000]   DMA32 zone: 255999 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x1e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x20] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x22] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x24] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x26] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x28] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x2a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x2c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x2e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x30] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x32] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x34] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x36] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x38] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x3a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x3c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x3e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x40] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x21] lapic_id[0x42] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x22] lapic_id[0x44] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x23] lapic_id[0x46] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x24] lapic_id[0x48] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x25] lapic_id[0x4a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x26] lapic_id[0x4c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x27] lapic_id[0x4e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x28] lapic_id[0x50] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x29] lapic_id[0x52] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2a] lapic_id[0x54] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2b] lapic_id[0x56] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2c] lapic_id[0x58] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2d] lapic_id[0x5a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2e] lapic_id[0x5c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2f] lapic_id[0x5e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x30] lapic_id[0x60] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x31] lapic_id[0x62] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x32] lapic_id[0x64] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x33] lapic_id[0x66] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x34] lapic_id[0x68] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x35] lapic_id[0x6a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x36] lapic_id[0x6c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x37] lapic_id[0x6e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x38] lapic_id[0x70] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x39] lapic_id[0x72] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3a] lapic_id[0x74] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3b] lapic_id[0x76] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3c] lapic_id[0x78] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3d] lapic_id[0x7a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3e] lapic_id[0x7c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3f] lapic_id[0x7e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x40] lapic_id[0x80] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x41] lapic_id[0x82] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x42] lapic_id[0x84] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x43] lapic_id[0x86] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x44] lapic_id[0x88] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x45] lapic_id[0x8a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x46] lapic_id[0x8c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x47] lapic_id[0x8e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x48] lapic_id[0x90] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x49] lapic_id[0x92] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4a] lapic_id[0x94] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4b] lapic_id[0x96] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4c] lapic_id[0x98] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4d] lapic_id[0x9a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4e] lapic_id[0x9c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4f] lapic_id[0x9e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x50] lapic_id[0xa0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x51] lapic_id[0xa2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x52] lapic_id[0xa4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x53] lapic_id[0xa6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x54] lapic_id[0xa8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x55] lapic_id[0xaa] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x56] lapic_id[0xac] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x57] lapic_id[0xae] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x58] lapic_id[0xb0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x59] lapic_id[0xb2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5a] lapic_id[0xb4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5b] lapic_id[0xb6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5c] lapic_id[0xb8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5d] lapic_id[0xba] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5e] lapic_id[0xbc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5f] lapic_id[0xbe] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x60] lapic_id[0xc0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x61] lapic_id[0xc2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x62] lapic_id[0xc4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x63] lapic_id[0xc6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x64] lapic_id[0xc8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x65] lapic_id[0xca] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x66] lapic_id[0xcc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x67] lapic_id[0xce] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x68] lapic_id[0xd0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x69] lapic_id[0xd2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6a] lapic_id[0xd4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6b] lapic_id[0xd6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6c] lapic_id[0xd8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6d] lapic_id[0xda] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6e] lapic_id[0xdc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6f] lapic_id[0xde] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x70] lapic_id[0xe0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x71] lapic_id[0xe2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x72] lapic_id[0xe4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x73] lapic_id[0xe6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x74] lapic_id[0xe8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x75] lapic_id[0xea] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x76] lapic_id[0xec] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x77] lapic_id[0xee] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x78] lapic_id[0xf0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x79] lapic_id[0xf2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7a] lapic_id[0xf4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7b] lapic_id[0xf6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7c] lapic_id[0xf8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7d] lapic_id[0xfa] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7e] lapic_id[0xfc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7f] lapic_id[0xfe] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ5 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ10 used by override.
[    0.000000] ACPI: IRQ11 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] smpboot: 128 Processors exceeds NR_CPUS limit of 8
[    0.000000] smpboot: Allowing 8 CPUs, 5 hotplug CPUs
[    0.000000] e820: [mem 0x3f800000-0xfbffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003f400000 s83520 r8192 d22976 u262144
[    0.000000] pcpu-alloc: s83520 r8192 d22976 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    0.000000] xen: PV spinlocks enabled
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 255912
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.17.0-rc5-20140920-vanilla+ root=UUID=4b432b33-87ec-4522-8b10-5dba3f49099e ro debug loglevel=7 console=tty1 console=ttyS0 slub_debug radeon.dpm=1 radeon.hard_reset=1 radeon.always_post=1 systemd.log_level=warning
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] AGP: Checking aperture...
[    0.000000] AGP: No AGP bridge found
[    0.000000] Memory: 983224K/1039988K available (10175K kernel code, 981K rwdata, 4028K rodata, 1108K init, 14292K bss, 56764K reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] 	Additional per-CPU info printed with stalls.
[    0.000000] NR_IRQS:4352 nr_irqs:896 0
[    0.000000] xen:events: Using FIFO-based ABI
[    0.000000] xen:events: Xen HVM callback vector for event delivery is enabled
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty1] enabled
[    0.000000] console [ttyS0] enabled
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.000000] ... MAX_LOCKDEP_CHAINS:      65536
[    0.000000] ... CHAINHASH_SIZE:          32768
[    0.000000]  memory used by lock dependency info: 8159 kB
[    0.000000]  per task-struct memory footprint: 1920 bytes
[    0.000000] kmemleak: Kernel memory leak detector disabled
[    0.000000] hpet clockevent registered
[    0.000000] tsc: Detected 3200.172 MHz processor
[    0.000000] tsc: Marking TSC unstable due to TSCs unsynchronized
[    0.029999] Calibrating delay loop (skipped), value calculated using timer frequency.. 6402.02 BogoMIPS (lpj=10667240)
[    0.056673] pid_max: default: 32768 minimum: 301
[    0.070074] ACPI: Core revision 20140724
[    0.267223] ACPI: All ACPI Tables successfully acquired
[    0.283715] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.303728] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.320193] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
[    0.340019] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
[    0.361108] Initializing cgroup subsys freezer
[    0.373373] Initializing cgroup subsys blkio
[    0.387533] CPU: Physical Processor ID: 0
[    0.396670] CPU: Processor Core ID: 0
[    0.410008] mce: CPU supports 2 MCE banks
[    0.426712] numa_add_cpu cpu 0 node 0: mask now 0
[    0.426718] Last level iTLB entries: 4KB 512, 2MB 16, 4MB 8
[    0.426718] Last level dTLB entries: 4KB 512, 2MB 128, 4MB 64, 1GB 0
[    0.460333] Freeing SMP alternatives memory: 32K (ffffffff8200c000 - ffffffff82014000)
[    0.487069] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.537527] smpboot: CPU0: AMD Phenom(tm) II X6 1090T Processor (fam: 10, model: 0a, stepping: 00)
[    0.563345] Xen: using vcpuop timer interface
[    0.563354] installing Xen timer for CPU 0
[    0.573579] cpu 0 spinlock event irq 53
[    0.577102] Performance Events: Broken PMU hardware detected, using software events only.
[    0.583340] Failed to access perfctr msr (MSR c0010004 is 0)
[    0.588186] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.590454] installing Xen timer for CPU 1
[    0.593527] x86: Booting SMP configuration:
[    0.596675] .... node  #0, CPUs:      #1
[    0.029999] numa_add_cpu cpu 1 node 0: mask now 0-1
[    0.700397] cpu 1 spinlock event irq 59
[    0.703829] installing Xen timer for CPU 2
[    0.706842]  #2
[    0.029999] numa_add_cpu cpu 2 node 0: mask now 0-2
[    0.806991] cpu 2 spinlock event irq 65
[    0.810058] x86: Booted up 1 node, 3 CPUs
[    0.813344] smpboot: Total of 3 processors activated (19228.51 BogoMIPS)
[    0.820395] devtmpfs: initialized
[    0.834384] xor: measuring software checksum speed
[    0.879083]    prefetch64-sse:   897.600 MB/sec
[    0.921913]    generic_sse:   871.200 MB/sec
[    0.933345] xor: using function: prefetch64-sse (897.600 MB/sec)
[    0.950684] NET: Registered protocol family 16
[    0.966917] xenbus: xs_reset_watches failed: -38
[    0.981218] cpuidle: using governor ladder
[    0.993356] cpuidle: using governor menu
[    1.010229] ACPI: bus type PCI registered
[    1.023344] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    1.041270] PCI: Using configuration type 1 for base access
[    1.053342] PCI: Using configuration type 1 for extended access
[    1.193360] raid6: sse2x1    2748 MB/s
[    1.253354] raid6: sse2x2    3785 MB/s
[    1.313356] raid6: sse2x4    3592 MB/s
[    1.316678] raid6: using algorithm sse2x2 (3785 MB/s)
[    1.320014] raid6: using intx1 recovery algorithm
[    1.323693] ACPI: Added _OSI(Module Device)
[    1.326675] ACPI: Added _OSI(Processor Device)
[    1.330018] ACPI: Added _OSI(3.0 _SCP Extensions)
[    1.333343] ACPI: Added _OSI(Processor Aggregator Device)
[    1.459591] ACPI: Interpreter enabled
[    1.460047] ACPI: (supports S0 S5)
[    1.463345] ACPI: Using IOAPIC for interrupt routing
[    1.467019] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    1.616965] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    1.633375] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    1.656810] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[    1.680830] pci_bus 0000:00: dev 01, created physical slot 1
[    1.680984] pci_bus 0000:00: dev 02, created physical slot 2
[    1.681136] pci_bus 0000:00: dev 03, created physical slot 3
[    1.681287] pci_bus 0000:00: dev 04, created physical slot 4
[    1.681440] pci_bus 0000:00: dev 05, created physical slot 5
[    1.681604] pci_bus 0000:00: dev 06, created physical slot 6
[    1.681778] pci_bus 0000:00: dev 07, created physical slot 7
[    1.681950] pci_bus 0000:00: dev 08, created physical slot 8
[    1.682126] pci_bus 0000:00: dev 09, created physical slot 9
[    1.682316] pci_bus 0000:00: dev 0a, created physical slot 10
[    1.682494] pci_bus 0000:00: dev 0b, created physical slot 11
[    1.682673] pci_bus 0000:00: dev 0c, created physical slot 12
[    1.682829] pci_bus 0000:00: dev 0d, created physical slot 13
[    1.682987] pci_bus 0000:00: dev 0e, created physical slot 14
[    1.683141] pci_bus 0000:00: dev 0f, created physical slot 15
[    1.683321] pci_bus 0000:00: dev 10, created physical slot 16
[    1.683479] pci_bus 0000:00: dev 11, created physical slot 17
[    1.683641] pci_bus 0000:00: dev 12, created physical slot 18
[    1.683812] pci_bus 0000:00: dev 13, created physical slot 19
[    1.683982] pci_bus 0000:00: dev 14, created physical slot 20
[    1.684147] pci_bus 0000:00: dev 15, created physical slot 21
[    1.684299] pci_bus 0000:00: dev 16, created physical slot 22
[    1.684488] pci_bus 0000:00: dev 17, created physical slot 23
[    1.684662] pci_bus 0000:00: dev 18, created physical slot 24
[    1.684836] pci_bus 0000:00: dev 19, created physical slot 25
[    1.684989] pci_bus 0000:00: dev 1a, created physical slot 26
[    1.685141] pci_bus 0000:00: dev 1b, created physical slot 27
[    1.685295] pci_bus 0000:00: dev 1c, created physical slot 28
[    1.685448] pci_bus 0000:00: dev 1d, created physical slot 29
[    1.685600] pci_bus 0000:00: dev 1e, created physical slot 30
[    1.685763] pci_bus 0000:00: dev 1f, created physical slot 31
[    1.686954] acpiphp: Slot [3] registered
[    1.697025] acpiphp: Slot [4] registered
[    1.710516] acpiphp: Slot [5] registered
[    1.720381] acpiphp: Slot [6] registered
[    1.733722] acpiphp: Slot [7] registered
[    1.743683] acpiphp: Slot [8] registered
[    1.757013] acpiphp: Slot [9] registered
[    1.767175] acpiphp: Slot [10] registered
[    1.780329] acpiphp: Slot [11] registered
[    1.790508] acpiphp: Slot [12] registered
[    1.803644] acpiphp: Slot [13] registered
[    1.813864] acpiphp: Slot [14] registered
[    1.827101] acpiphp: Slot [15] registered
[    1.840009] acpiphp: Slot [16] registered
[    1.850356] acpiphp: Slot [17] registered
[    1.863684] acpiphp: Slot [18] registered
[    1.873812] acpiphp: Slot [19] registered
[    1.887040] acpiphp: Slot [20] registered
[    1.896989] acpiphp: Slot [21] registered
[    1.910335] acpiphp: Slot [22] registered
[    1.920336] acpiphp: Slot [23] registered
[    1.933675] acpiphp: Slot [24] registered
[    1.947072] acpiphp: Slot [25] registered
[    1.957008] acpiphp: Slot [26] registered
[    1.970358] acpiphp: Slot [27] registered
[    1.983674] acpiphp: Slot [28] registered
[    1.997030] acpiphp: Slot [29] registered
[    2.010363] acpiphp: Slot [30] registered
[    2.020379] acpiphp: Slot [31] registered
[    2.033415] PCI host bridge to bus 0000:00
[    2.043355] pci_bus 0000:00: root bus resource [bus 00-ff]
[    2.060015] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    2.073351] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    2.090014] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    2.110019] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbffffff]
[    2.126682] pci_bus 0000:00: scanning bus
[    2.127175] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
[    2.128685] pci 0000:00:00.0: calling quirk_mmio_always_on+0x0/0x10
[    2.133898] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
[    2.140009] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
[    2.160021] pci 0000:00:01.1: reg 0x20: [io  0xc260-0xc26f]
[    2.172581] pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
[    2.193348] pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io  0x03f6]
[    2.213351] pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
[    2.233350] pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io  0x0376]
[    2.260868] pci 0000:00:01.2: [8086:7020] type 00 class 0x0c0300
[    2.278870] pci 0000:00:01.2: reg 0x20: [io  0xc240-0xc25f]
[    2.291440] pci 0000:00:01.3: [8086:7113] type 00 class 0x068000
[    2.291525] pci 0000:00:01.3: calling acpi_pm_check_blacklist+0x0/0x40
[    2.294662] pci 0000:00:01.3: calling quirk_piix4_acpi+0x0/0x140
[    2.294744] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX4 ACPI
[    2.313410] pci 0000:00:01.3: quirk: [io  0xb100-0xb10f] claimed by PIIX4 SMB
[    2.337041] pci 0000:00:01.3: calling pci_fixup_piix4_acpi+0x0/0x10
[    2.340009] pci 0000:00:02.0: [5853:0001] type 00 class 0xff8000
[    2.346678] pci 0000:00:02.0: reg 0x10: [io  0xc000-0xc0ff]
[    2.353376] pci 0000:00:02.0: reg 0x14: [mem 0xf2000000-0xf2ffffff pref]
[    2.393344] pci 0000:00:03.0: [1013:00b8] type 00 class 0x030000
[    2.400018] pci 0000:00:03.0: reg 0x10: [mem 0xf0000000-0xf1ffffff pref]
[    2.406679] pci 0000:00:03.0: reg 0x14: [mem 0xf30b0000-0xf30b0fff]
[    2.443376] pci 0000:00:03.0: reg 0x30: [mem 0xf30a0000-0xf30affff pref]
[    2.446759] pci 0000:00:05.0: [1002:6759] type 00 class 0x030000
[    2.480064] pci 0000:00:05.0: reg 0x10: [mem 0xe0000000-0xefffffff 64bit pref]
[    2.513357] pci 0000:00:05.0: reg 0x18: [mem 0xf3060000-0xf307ffff 64bit]
[    2.543354] pci 0000:00:05.0: reg 0x20: [io  0xc100-0xc1ff]
[    2.603388] pci 0000:00:05.0: reg 0x30: [mem 0xf3080000-0xf309ffff pref]
[    2.608034] pci 0000:00:05.0: supports D1 D2
[    2.609999] pci_bus 0000:00: fixups for bus
[    2.609999] pci_bus 0000:00: bus scan returning with max=00
[    2.609999] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
[    2.613333] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    2.619999] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    2.623417] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
[    2.633511] ACPI: Enabled 2 GPEs in block 00 to 0F
[    2.637105] xen:balloon: Initialising balloon driver
[    2.640362] vgaarb: setting as boot device: PCI:0000:00:03.0
[    2.643333] vgaarb: device added: PCI:0000:00:03.0,decodes=io+mem,owns=io+mem,locks=none
[    2.646817] vgaarb: device added: PCI:0000:00:05.0,decodes=io+mem,owns=io+mem,locks=none
[    2.650010] vgaarb: loaded
[    2.653333] vgaarb: bridge control possible 0000:00:05.0
[    2.653343] vgaarb: no bridge control possible 0000:00:03.0
[    2.654444] SCSI subsystem initialized
[    2.656694] libata version 3.00 loaded.
[    2.656811] ACPI: bus type USB registered
[    2.657051] usbcore: registered new interface driver usbfs
[    2.660077] usbcore: registered new interface driver hub
[    2.663483] usbcore: registered new device driver usb
[    2.663736] Linux video capture interface: v2.00
[    2.669999] pps_core: LinuxPPS API ver. 1 registered
[    2.669999] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    2.670124] PTP clock support registered
[    2.673361] PCI: Using ACPI for IRQ routing
[    2.673361] PCI: pci_cache_line_size set to 64 bytes
[    2.673586] pci 0000:00:01.1: BAR 0: reserving [io  0x01f0-0x01f7 flags 0x110] (d=0, p=0)
[    2.673592] pci 0000:00:01.1: BAR 1: reserving [io  0x03f6 flags 0x110] (d=0, p=0)
[    2.673594] pci 0000:00:01.1: BAR 2: reserving [io  0x0170-0x0177 flags 0x110] (d=0, p=0)
[    2.673596] pci 0000:00:01.1: BAR 3: reserving [io  0x0376 flags 0x110] (d=0, p=0)
[    2.673598] pci 0000:00:01.1: BAR 4: reserving [io  0xc260-0xc26f flags 0x40101] (d=0, p=0)
[    2.673670] pci 0000:00:01.2: BAR 4: reserving [io  0xc240-0xc25f flags 0x40101] (d=0, p=0)
[    2.673852] pci 0000:00:02.0: BAR 0: reserving [io  0xc000-0xc0ff flags 0x40101] (d=0, p=0)
[    2.673855] pci 0000:00:02.0: BAR 1: reserving [mem 0xf2000000-0xf2ffffff flags 0x42208] (d=0, p=0)
[    2.673925] pci 0000:00:03.0: BAR 0: reserving [mem 0xf0000000-0xf1ffffff flags 0x42208] (d=0, p=0)
[    2.673927] pci 0000:00:03.0: BAR 1: reserving [mem 0xf30b0000-0xf30b0fff flags 0x40200] (d=0, p=0)
[    2.674017] pci 0000:00:05.0: BAR 0: reserving [mem 0xe0000000-0xefffffff flags 0x14220c] (d=0, p=0)
[    2.674019] pci 0000:00:05.0: BAR 2: reserving [mem 0xf3060000-0xf307ffff flags 0x140204] (d=0, p=0)
[    2.674021] pci 0000:00:05.0: BAR 4: reserving [io  0xc100-0xc1ff flags 0x40101] (d=0, p=0)
[    2.674675] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff]
[    2.674691] e820: reserve RAM buffer [mem 0x3f7ff000-0x3fffffff]
[    2.676228] Bluetooth: Core ver 2.19
[    2.676700] NET: Registered protocol family 31
[    2.676700] Bluetooth: HCI device and connection manager initialized
[    2.679999] Bluetooth: HCI socket layer initialized
[    2.680038] Bluetooth: L2CAP socket layer initialized
[    2.683333] Bluetooth: SCO socket layer initialized
[    2.687042] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[    2.687042] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    2.690006] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[    2.696486] Switched to clocksource xen
[    2.696666] FS-Cache: Loaded
[    2.714848] pnp: PnP ACPI init
[    2.725180] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
[    2.743732] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[    2.744529] system 00:01: [io  0x08a0-0x08a3] has been reserved
[    2.761322] system 00:01: [io  0x0cc0-0x0ccf] has been reserved
[    2.777087] system 00:01: [io  0x04d0-0x04d1] has been reserved
[    2.793163] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
[    2.793472] xen: --> pirq=16 -> irq=8 (gsi=8)
[    2.793699] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active)
[    2.793948] xen: --> pirq=17 -> irq=12 (gsi=12)
[    2.794131] pnp 00:03: Plug and Play ACPI device, IDs PNP0f13 (active)
[    2.794361] xen: --> pirq=18 -> irq=1 (gsi=1)
[    2.794560] pnp 00:04: Plug and Play ACPI device, IDs PNP0303 PNP030b (active)
[    2.794791] xen: --> pirq=19 -> irq=6 (gsi=6)
[    2.794802] pnp 00:05: [dma 2]
[    2.794979] pnp 00:05: Plug and Play ACPI device, IDs PNP0700 (active)
[    2.795327] xen: --> pirq=20 -> irq=4 (gsi=4)
[    2.795517] pnp 00:06: Plug and Play ACPI device, IDs PNP0501 (active)
[    2.796540] system 00:07: [io  0xae00-0xae0f] has been reserved
[    2.812570] system 00:07: [io  0xb044-0xb047] has been reserved
[    2.828410] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    2.830330] pnp: PnP ACPI: found 8 devices
[    2.866433] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    2.866437] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    2.866439] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    2.866441] pci_bus 0000:00: resource 7 [mem 0xe0000000-0xfbffffff]
[    2.866582] NET: Registered protocol family 2
[    2.882196] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[    2.900902] TCP bind hash table entries: 8192 (order: 7, 524288 bytes)
[    2.921165] TCP: Hash tables configured (established 8192 bind 8192)
[    2.938865] TCP: reno registered
[    2.948160] UDP hash table entries: 512 (order: 4, 81920 bytes)
[    2.965711] UDP-Lite hash table entries: 512 (order: 4, 81920 bytes)
[    2.982630] NET: Registered protocol family 1
[    2.995977] pci 0000:00:00.0: calling quirk_natoma+0x0/0x40
[    2.995980] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    3.013833] pci 0000:00:00.0: calling quirk_passive_release+0x0/0x90
[    3.013925] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    3.028815] pci 0000:00:01.0: calling quirk_isa_dma_hangs+0x0/0x40
[    3.028817] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    3.045040] pci 0000:00:01.2: calling quirk_usb_early_handoff+0x0/0x6c0
[    3.049508] xen: --> pirq=21 -> irq=23 (gsi=23)
[    3.056392] pci 0000:00:03.0: calling pci_fixup_video+0x0/0xd0
[    3.056524] pci 0000:00:03.0: Video device with shadowed ROM
[    3.056620] pci 0000:00:05.0: calling pci_fixup_video+0x0/0xd0
[    3.056732] PCI: CLS 0 bytes, default 64
[    3.057142] Trying to unpack rootfs image as initramfs...
[    3.247379] Freeing initrd memory: 8436K (ffff880036f76000 - ffff8800377b3000)
[    3.438974] DMA-API: preallocated 65536 debug entries
[    3.453355] DMA-API: debugging enabled by kernel config
[    3.472578] Scanning for low memory corruption every 60 seconds
[    3.493007] sha1_ssse3: Neither AVX nor AVX2 nor SSSE3 is available/usable.
[    3.514669] futex hash table entries: 2048 (order: 6, 262144 bytes)
[    3.531545] audit: initializing netlink subsys (disabled)
[    3.546775] audit: type=2000 audit(1411510968.439:1): initialized
[    3.565242] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    3.634499] VFS: Disk quotas dquot_6.5.2
[    3.646636] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    3.675428] ntfs: driver 2.1.30 [Flags: R/W].
[    3.690887] fuse init (API version 7.23)
[    3.708324] gfs2: GFS2 installed
[    3.719921] ceph: loaded (mds proto 32)
[    3.730892] msgmni has been set to 1936
[    3.746554] bounce: pool size: 64 pages
[    3.759489] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[    3.779721] io scheduler noop registered
[    3.790661] io scheduler deadline registered
[    3.803727] io scheduler cfq registered (default)
[    3.817746] start plist test
[    3.819151] end plist test
[    3.819397] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
[    3.833419] crc32: self tests passed, processed 225944 bytes in 103180 nsec
[    3.851627] crc32c: CRC_LE_BITS = 64
[    3.861839] crc32c: self tests passed, processed 225944 bytes in 53538 nsec
[    3.888953] crc32_combine: 8373 self tests passed
[    3.910831] crc32c_combine: 8373 self tests passed
[    3.925502] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    3.941209] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    3.959375] cpcihp_zt5550: ZT5550 CompactPCI Hot Plug Driver version: 0.2
[    3.978609] cpcihp_generic: Generic port I/O CompactPCI Hot Plug Driver version: 0.1
[    4.000735] cpcihp_generic: not configured, disabling.
[    4.015255] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    4.050547] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed
[    4.069580] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[    4.090389] ACPI: Power Button [PWRF]
[    4.101920] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
[    4.124001] ACPI: Sleep Button [SLPF]
[    4.136807] xen:xen_evtchn: Event-channel device installed
[    4.157759] xen: --> pirq=22 -> irq=24 (gsi=24)
[    4.158259] xen:grant_table: Grant tables using version 1 layout
[    4.174492] Grant table initialized
[    4.187783] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    4.259042] 00:06: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    4.284640] Linux agpgart interface v0.103
[    4.296393] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds).
[    4.321952] [drm] Initialized drm 1.1.0 20060810
[    4.335246] [drm] radeon kernel modesetting enabled.
[    4.355349] xen: --> pirq=32 -> irq=36 (gsi=36)
[    4.359541] [drm] initializing kernel modesetting (TURKS 0x1002:0x6759 0x174B:0xE193).
[    4.385655] [drm] register mmio base: 0xF3060000
[    4.401814] [drm] register mmio size: 131072
[    4.599903] ATOM BIOS: ELIXIR
[    4.609170] radeon 0000:00:05.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
[    4.632895] radeon 0000:00:05.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
[    4.654488] [drm] Detected VRAM RAM=1024M, BAR=256M
[    4.667426] [drm] RAM width 128bits DDR
[    4.679286] [TTM] Zone  kernel: Available graphics memory: 495846 kiB
[    4.696260] [TTM] Initializing pool allocator
[    4.708263] [TTM] Initializing DMA pool allocator
[    4.722606] [drm] radeon: 1024M of VRAM memory ready
[    4.736052] [drm] radeon: 1024M of GTT memory ready.
[    4.749224] [drm] Loading TURKS Microcode
[    4.762740] [drm] Internal thermal controller with fan control
[    4.778911] == power state 0 ==
[    4.788065] 	ui class: none
[    4.797380] 	internal class: boot 
[    4.811123] 	caps: 
[    4.819073] 	uvd    vclk: 0 dclk: 0
[    4.828981] 		power level 0    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    4.847156] 		power level 1    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    4.864775] 		power level 2    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    4.882494] 	status: c r b 
[    4.895819] == power state 1 ==
[    4.904733] 	ui class: performance
[    4.915361] 	internal class: none
[    4.927838] 	caps: 
[    4.935585] 	uvd    vclk: 0 dclk: 0
[    4.945364] 		power level 0    sclk: 10000 mclk: 15000 vddc: 900 vddci: 0
[    4.963971] 		power level 1    sclk: 40000 mclk: 66700 vddc: 1000 vddci: 0
[    4.981618] 		power level 2    sclk: 65000 mclk: 66700 vddc: 1050 vddci: 0
[    5.000366] 	status: 
[    5.008871] == power state 2 ==
[    5.018138] 	ui class: none
[    5.028683] 	internal class: uvd 
[    5.040716] 	caps: video 
[    5.051145] 	uvd    vclk: 70000 dclk: 56000
[    5.063137] 		power level 0    sclk: 65000 mclk: 66700 vddc: 1050 vddci: 0
[    5.081189] 		power level 1    sclk: 65000 mclk: 66700 vddc: 1050 vddci: 0
[    5.098910] 		power level 2    sclk: 65000 mclk: 66700 vddc: 1050 vddci: 0
[    5.117140] 	status: 
[    5.126844] [drm:radeon_pm_init_dpm] *ERROR* radeon: dpm initialization failed
[    5.146436] [drm] GART: num cpu pages 262144, num gpu pages 262144
[    5.173510] [drm] PCIE GART of 1024M enabled (table at 0x0000000000273000).
[    5.192961] radeon 0000:00:05.0: WB enabled
[    5.205678] radeon 0000:00:05.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff880039581c00
[    5.234904] radeon 0000:00:05.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff880039581c0c
[    5.266349] radeon 0000:00:05.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0xffffc90000432118
[    5.301130] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    5.321223] [drm] Driver supports precise vblank timestamp query.
[    5.339703] radeon 0000:00:05.0: xen: msi bound to pirq=87
[    5.339757] radeon 0000:00:05.0: xen: msi --> pirq=87 --> irq=68
[    5.340274] radeon 0000:00:05.0: radeon: using MSI.
[    5.354299] [drm] radeon: irq initialized.
[    5.408876] random: nonblocking pool is initialized
[    5.555322] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
[    5.582130] radeon 0000:00:05.0: disabling GPU acceleration
[    5.608429] [drm] Radeon Display Connectors
[    5.619956] [drm] Connector 0:
[    5.628449] [drm]   HDMI-A-1
[    5.636995] [drm]   HPD4
[    5.645992] [drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c
[    5.665693] [drm]   Encoders:
[    5.674568] [drm]     DFP1: INTERNAL_UNIPHY2
[    5.686353] [drm] Connector 1:
[    5.695369] [drm]   DVI-D-1
[    5.703798] [drm]   HPD1
[    5.711155] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c
[    5.731244] [drm]   Encoders:
[    5.739910] [drm]     DFP2: INTERNAL_UNIPHY
[    5.750978] [drm] Connector 2:
[    5.760119] [drm]   VGA-1
[    5.768248] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[    5.787936] [drm]   Encoders:
[    5.796459] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
[    5.859339] [drm] fb mappable at 0xE0474000
[    5.873915] [drm] vram apper at 0xE0000000
[    5.890039] [drm] size 7299072
[    5.902621] [drm] fb depth is 24
[    5.917167] [drm]    pitch is 6912
[    5.941779] Console: switching to colour frame buffer device 210x65
[    5.962091] radeon 0000:00:05.0: fb0: radeondrmfb frame buffer device
[    5.976896] radeon 0000:00:05.0: registered panic notifier
[    6.027410] [drm] Initialized radeon 2.40.0 20080528 for 0000:00:05.0 on minor 0
[    6.089275] brd: module loaded
[    6.111989] loop: module loaded
[    6.128748] Uniform Multi-Platform E-IDE driver
[    6.148617] piix 0000:00:01.1: IDE controller (0x8086:0x7010 rev 0x00)
[    6.150238] blkfront: xvda: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
[    6.176725]  xvda: xvda1 xvda2 < xvda5 >
[    6.203535] piix 0000:00:01.1: not 100% native mode: will probe irqs later
[    6.220309]     ide0: BM-DMA at 0xc260-0xc267
[    6.230814]     ide1: BM-DMA at 0xc268-0xc26f
[    6.241348] Probing IDE interface ide0...
[    6.784823] Probing IDE interface ide1...
[    7.330166] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[    7.349921] ide1 at 0x170-0x177,0x376 on irq 15
[    7.363669] ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports
[    7.387846] ide-gd driver 1.18
[    7.404005] tun: Universal TUN/TAP device driver, 1.6
[    7.414909] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    7.435378] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[    7.452628] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    7.466526] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    7.480736] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[    7.494809] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.13-k
[    7.511583] igb: Copyright (c) 2007-2014 Intel Corporation.
[    7.525449] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.2-k
[    7.545325] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    7.561212] xen_netfront: Initialising Xen virtual ethernet driver
[    7.583086] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    7.602283] ehci-pci: EHCI PCI platform driver
[    7.619040] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    7.635903] ohci-pci: OHCI PCI platform driver
[    7.647148] uhci_hcd: USB Universal Host Controller Interface driver
[    7.668335] uhci_hcd 0000:00:01.2: enabling bus mastering
[    7.670252] uhci_hcd 0000:00:01.2: UHCI Host Controller
[    7.684693] uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1
[    7.703018] uhci_hcd 0000:00:01.2: irq 23, io base 0x0000c240
[    7.720706] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[    7.739815] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    7.761389] usb usb1: Product: UHCI Host Controller
[    7.774557] usb usb1: Manufacturer: Linux 3.17.0-rc5-20140920-vanilla+ uhci_hcd
[    7.794283] usb usb1: SerialNumber: 0000:00:01.2
[    7.812239] hub 1-0:1.0: USB hub found
[    7.822995] hub 1-0:1.0: 2 ports detected
[    7.837802] usbcore: registered new interface driver usblp
[    7.853130] usbcore: registered new interface driver usb-storage
[    7.870323] usbcore: registered new interface driver usbserial
[    7.887712] usbcore: registered new interface driver cp210x
[    7.903209] usbserial: USB Serial support registered for cp210x
[    7.920772] usbcore: registered new interface driver cypress_m8
[    7.936630] usbserial: USB Serial support registered for DeLorme Earthmate USB
[    7.956057] usbserial: USB Serial support registered for HID->COM RS232 Adapter
[    7.977539] usbserial: USB Serial support registered for Nokia CA-42 V2 Adapter
[    7.997057] usbcore: registered new interface driver mos7720
[    8.013062] usbserial: USB Serial support registered for Moschip 2 port adapter
[    8.032630] usbcore: registered new interface driver mos7840
[    8.048360] usbserial: USB Serial support registered for Moschip 7840/7820 USB Serial Driver
[    8.071062] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    8.098894] serio: i8042 KBD port at 0x60,0x64 irq 1
[    8.112830] serio: i8042 AUX port at 0x60,0x64 irq 12
[    8.127589] mousedev: PS/2 mouse device common for all mice
[    8.146857] input: Xen Virtual Keyboard as /devices/virtual/input/input3
[    8.148781] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[    8.198051] input: Xen Virtual Pointer as /devices/virtual/input/input6
[    8.221803] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[    8.239901] rtc_cmos 00:02: alarms up to one day, 114 bytes nvram, hpet irqs
[    8.260868] piix4_smbus 0000:00:01.3: SMBus Host Controller not enabled!
[    8.281202] lirc_dev: IR Remote Control driver registered, major 248 
[    8.299566] IR NEC protocol handler initialized
[    8.312030] IR RC5(x/sz) protocol handler initialized
[    8.328226] IR RC6 protocol handler initialized
[    8.333727] usb 1-1: new full-speed USB device number 2 using uhci_hcd
[    8.360016] IR JVC protocol handler initialized
[    8.372586] IR Sony protocol handler initialized
[    8.385598] IR SANYO protocol handler initialized
[    8.399043] IR Sharp protocol handler initialized
[    8.414734] IR MCE Keyboard/mouse protocol handler initialized
[    8.431096] IR LIRC bridge handler initialized
[    8.444118] IR XMP protocol handler initialized
[    8.461562] cx25821: driver version 0.0.106 loaded
[    8.477500] usbcore: registered new interface driver pvrusb2
[    8.497115] usb 1-1: New USB device found, idVendor=0627, idProduct=0001
[    8.497117] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=5
[    8.497118] usb 1-1: Product: QEMU USB Tablet
[    8.497119] usb 1-1: Manufacturer: QEMU
[    8.497120] usb 1-1: SerialNumber: 42
[    8.574955] pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
[    8.596259] pvrusb2: Debug mask is 31 (0x1f)
[    8.611646] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
[    8.629159] xen_wdt: Xen WatchDog Timer Driver v0.01
[    8.646070] xen_wdt: initialized (timeout=60s, nowayout=0)
[    8.663591] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com
[    8.687965] Bluetooth: Virtual HCI driver ver 1.5
[    8.701357] Bluetooth: HCI UART driver ver 2.2
[    8.714805] Bluetooth: HCI H4 protocol initialized
[    8.728173] Bluetooth: HCI BCSP protocol initialized
[    8.741951] Bluetooth: HCILL protocol initialized
[    8.756114] Bluetooth: HCIATH3K protocol initialized
[    8.769902] Bluetooth: HCI Three-wire UART (H5) protocol initialized
[    8.787424] usbcore: registered new interface driver bcm203x
[    8.803137] usbcore: registered new interface driver bpa10x
[    8.818750] usbcore: registered new interface driver bfusb
[    8.835118] usbcore: registered new interface driver btusb
[    8.852728] usbcore: registered new interface driver ath3k
[    8.870759] hidraw: raw HID events driver (C) Jiri Kosina
[    8.896799] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input5
[    8.901686] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:01.2/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input7
[    8.903412] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Pointer [QEMU QEMU USB Tablet] on usb-0000:00:01.2-1/input0
[    8.903597] usbcore: registered new interface driver usbhid
[    8.903598] usbhid: USB HID core driver
[    8.903706] Netfilter messages via NETLINK v0.30.
[    8.903736] nfnl_acct: registering with nfnetlink.
[    8.903842] nf_conntrack version 0.5.0 (7747 buckets, 30988 max)
[    8.905189] ctnetlink v0.93: registering with nfnetlink.
[    8.907515] xt_time: kernel timezone is -0000
[    8.907556] ip_set: protocol 6
[    8.907646] IPVS: Registered protocols ()
[    8.908606] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
[    8.908743] IPVS: Creating netns size=1904 id=0
[    9.150565] IPVS: ipvs loaded.
[    9.160955] ip_tables: (C) 2000-2006 Netfilter Core Team
[    9.175885] TCP: cubic registered
[    9.185709] NET: Registered protocol family 17
[    9.199607] Bridge firewalling registered
[    9.211402] Ebtables v2.0 registered
[    9.221859] Bluetooth: RFCOMM TTY layer initialized
[    9.236143] Bluetooth: RFCOMM socket layer initialized
[    9.251517] Bluetooth: RFCOMM ver 1.11
[    9.262280] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    9.277347] Bluetooth: BNEP filters: protocol multicast
[    9.292798] Bluetooth: BNEP socket layer initialized
[    9.306797] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[    9.324141] Bluetooth: HIDP socket layer initialized
[    9.337791] Key type ceph registered
[    9.349323] libceph: loaded (mon/osd proto 15/24)
[    9.366513] registered taskstats version 1
[    9.388166] Btrfs loaded
[    9.399922] xenbus_probe_frontend: Device with no driver: device/pci/0
[    9.418039] console [netcon0] enabled
[    9.428409] netconsole: network logging started
[    9.442642] rtc_cmos 00:02: setting system clock to 2014-09-23 22:22:57 UTC (1411510977)
[    9.469124] Freeing unused kernel memory: 1108K (ffffffff81ef7000 - ffffffff8200c000)
[    9.492084] Write protecting the kernel read-only data: 14336k
[    9.509592] Freeing unused kernel memory: 52K (ffff8800019f3000 - ffff880001a00000)
[    9.536924] Freeing unused kernel memory: 68K (ffff880001def000 - ffff880001e00000)
[    9.604516] systemd-udevd[1434]: starting version 208
[    9.974759] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[   10.809420] systemd[1]: Failed to insert module 'ipv6'
[   12.649929] systemd-udevd[1514]: starting version 208
[   13.699991] EXT4-fs (xvda1): re-mounted. Opts: errors=remount-ro
[   17.743673] systemd-journald[1498]: Received request to flush runtime journal from PID 1
[   18.049004] Adding 901116k swap on /dev/xvda5.  Priority:-1 extents:1 across:901116k SS
[   22.026608] vgaarb: device changed decodes: PCI:0000:00:05.0,olddecodes=io+mem,decodes=none:owns=io+mem

[-- Attachment #4: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-24 14:16             ` Sander Eikelenboom
@ 2014-09-24 15:10               ` Zytaruk, Kelly
  2014-09-24 15:35                 ` Sander Eikelenboom
  0 siblings, 1 reply; 17+ messages in thread
From: Zytaruk, Kelly @ 2014-09-24 15:10 UTC (permalink / raw)
  To: Sander Eikelenboom; +Cc: Gordan Bobic, xen-devel, Peter Kay

This is making more sense now.  I didn't read your first message close enough.

I didn't realize that you are running a Linux DomU.  I run Win7 in my domU. We have two completely different drivers (and groups) that support Windows vs Linux.  I don't have any problems restarting a DomU with Win7.  I haven't recently been using Linux in a DomU, that may be why I am not seeing the same problems.

My roots were in the Windows kernel driver team. I made the move over to Xen/Linux about a year ago.  I still work very closely with the Windows team and the Windows driver.  I don't work directly on the Linux Radeon driver, I concentrate more on Xen/QEMU.  I will have to ask around the Linux team if they can provide me with any insight.

Thanks,
Kelly

> -----Original Message-----
> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> Sent: Wednesday, September 24, 2014 10:16 AM
> To: Zytaruk, Kelly
> Cc: Peter Kay; xen-devel@lists.xen.org; Gordan Bobic; Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> 
> 
> Wednesday, September 24, 2014, 3:58:57 PM, you wrote:
> 
> > Sander,
> 
> > You have given me some interesting information.  First off, I would
> > like to ask you about one of your comments;
> 
> >> Yes, from what i see the problem seems to be that the Radeon card is
> >> not reset to a state were it will regard itself as "unposted". (on
> >> the first boot of the guest i see the driver report it hasn't posted
> >> (which is correct), it starts to past, and it works. On subsequent
> >> boots of the domU i don't see the unposted message
> 
> > I am curious how you can tell if the driver is posting or not?  Which message
> are you looking at?
> 
> With domU kernel 3.17-rc5 (with older kernels (i forgot the version number
> where it got fixed) there was a problem with the secondary card getting the
> shadow rom from the primary(emulated cirrus) ( see
> https://lkml.org/lkml/2014/2/13/109)), so a recent kernel domU kernel is best :)
> 
> In the domU on first boot it says it's not posted:
> 
> [    4.346649] [drm] Initialized drm 1.1.0 20060810
> [    4.359722] [drm] radeon kernel modesetting enabled.
> [    4.380435] xen: --> pirq=32 -> irq=36 (gsi=36)
> [    4.383891] [drm] initializing kernel modesetting (TURKS 0x1002:0x6759
> 0x174B:0xE193).
> [    4.405597] [drm] register mmio base: 0xF3060000
> [    4.418262] [drm] register mmio size: 131072
> [    4.559911] ATOM BIOS: ELIXIR
> [    4.569063] [drm] GPU not posted. posting now...
> [    4.585542] radeon 0000:00:05.0: VRAM: 1024M 0x0000000000000000 -
> 0x000000003FFFFFFF (1024M used)
> [    4.609664] radeon 0000:00:05.0: GTT: 1024M 0x0000000040000000 -
> 0x000000007FFFFFFF
> ....
> 
> In the domU on subsequent boots that message is not there, but i end up with
> errors like (and garbage on the screen (looks somewhat like white noise)):
> 
> [    4.321952] [drm] Initialized drm 1.1.0 20060810
> [    4.335246] [drm] radeon kernel modesetting enabled.
> [    4.355349] xen: --> pirq=32 -> irq=36 (gsi=36)
> [    4.359541] [drm] initializing kernel modesetting (TURKS 0x1002:0x6759
> 0x174B:0xE193).
> [    4.385655] [drm] register mmio base: 0xF3060000
> [    4.401814] [drm] register mmio size: 131072
> [    4.599903] ATOM BIOS: ELIXIR
> [    4.609170] radeon 0000:00:05.0: VRAM: 1024M 0x0000000000000000 -
> 0x000000003FFFFFFF (1024M used)
> [    4.632895] radeon 0000:00:05.0: GTT: 1024M 0x0000000040000000 -
> 0x000000007FFFFFFF
> ....
> [    5.126844] [drm:radeon_pm_init_dpm] *ERROR* radeon: dpm initialization
> failed
> ....
> [    5.555322] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
> (scratch(0x8504)=0xCAFEDEAD)
> ....
> 
> (complete dmesg from both boots attached)
> 
> --
> Sander
> 
> > Thanks,
> > Kelly
> 
> >> -----Original Message-----
> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> >> Sent: Wednesday, September 24, 2014 9:22 AM
> >> To: Zytaruk, Kelly
> >> Cc: Peter Kay; xen-devel@lists.xen.org; Gordan Bobic; Konrad
> >> Rzeszutek Wilk
> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> >>
> >>
> >> Wednesday, September 24, 2014, 2:12:38 PM, you wrote:
> >>
> >> >> Good to know there is interest from AMD into this area :-)
> >>
> >> > I am taking a personal interest in this and would like to improve
> >> > AMD support
> >> and presence within the Xen community.
> >>
> >> Thanks for that !
> >>
> >> > Gordan has also reported problems restarting a guest.
> >>
> >> Added Konrad to the CC as pciback maintainer.
> >>
> >> Yes, from what i see the problem seems to be that the Radeon card is
> >> not reset to a state were it will regard itself as "unposted". (on
> >> the first boot of the guest i see the driver report it hasn't posted
> >> (which is correct), it starts to past, and it works. On subsequent
> >> boots of the domU i don't see the unposted message but some failures
> >> that are probably due to the driver regarding the card as already been posted
> and skipping some init logic and reusing wrong values.
> >>
> >> So current xen-pciback logic doesn't seem to be able to reset the
> >> card in a "non- posted" state.
> >>
> >> I don't know if you know what kind of reset is required for radeon
> >> cards to regard itself as "not posted" ?
> >>
> >> Current xen-pciback logic uses the "__pci_reset_function_locked(dev);"
> >> functions (see pcistub.c pcistub_device_release()) to try to reset the device ..
> >> that function in turn tries some possible reset functions in a
> >> specific order and bails out at the first one reporting "succes".
> >> However it could be that this level of reset is not enough for this
> >> specific case. (in my case it always uses and succeeds at the first
> (pci_dev_specific_reset(dev, probe);).
> >>
> >> When looking at the code for vfio/kvm in "drivers/vfio/pci/vfio_pci.c
> >> vfio_pci_disable()", it seems to use:
> >> - Another order for disabling resetting and config save/restore
> >> - Always try a slot/bus reset on the way out ..
> >>
> >> I'm trying to experiment with that in 2 ways:
> >> 1) overrulling the logic in the domU radeon driver to do the reposting no
> matter
> >>    in what state it thinks it is.
> >> 2) Trying to change the xen-pciback reset logic, but at present that delivers
> >>    bad irq's to dom0 for completly different irq's as the passedthrough device
> >>    has (which i have seen before .. and is a bit worrying)
> >>
> >> > I have been trying to reproduce the problem but have not had any
> >> > luck.  As a
> >> secondary it restarts for me every time.  I don't know if I
> >> inadvertently made a change that indirectly fixed it in my code base or what
> the difference might be.
> >>
> >> Perhaps in the older qemu-traditional there is already some sort of reset
> done ?
> >>
> >> > What Xen version are you testing with?
> >> I'm almost always living on the edge with Xen-unstable ;) (the latest
> >> and greatest, which is actually pretty stable)
> >>
> >> --
> >> Sander
> >>
> >> > Thanks,
> >> > Kelly
> >>
> >> >> -----Original Message-----
> >> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> >> >> Sent: Tuesday, September 23, 2014 9:45 AM
> >> >> To: Zytaruk, Kelly
> >> >> Cc: Peter Kay; xen-devel@lists.xen.org
> >> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> >> >>
> >> >> Good to know there is interest from AMD into this area :-)
> >> >>
> >> >> I'm experimenting for a while with:
> >> >>
> >> >> - xen-unstable (and thus xl)
> >> >> - latest kernels (both dom0 and domU)
> >> >> - qemu-xen
> >> >> - Radeon HD 6570
> >> >> - secondary passthrough
> >> >> - Debian linux (sid) with the opensource (in kernel) radeon driver
> >> >>   (i also tried fglrx with succes, but it's a real PITA to build with every
> >> >>   new kernel, so i ditched that)
> >> >>
> >> >> It used to work, but something broke at the moment, but that could
> >> >> also be the changes to the systemd cruft that Debian jessie/sid is
> >> >> currently undergoing (or something else since i regularly update
> >> >> all
> >> components).
> >> >>
> >> >> The problems are mostly with restarting the domU, it differs a bit:
> >> >> - sometimes screen goes ok, sometimes it's garbage.
> >> >> - the radeon powercontrols only seem to work on the first boot and
> >> >> give errors on any subsequent one.
> >> >>
> >> >> But when it works it does:
> >> >> - the powercontrol.
> >> >> - opengl and opencl benchmarks with (near) native results.
> >> >> - hardware video acceleration in xbmc for instance.
> >> >>
> >> >> So one of the main problems at present seems to be proper
> >> >> resetting of the whole device on domain shutdown/start. I did do
> >> >> some experiments with the opensource radeon driver, but didn't get
> >> >> conclusive
> >> results out of that yet.
> >> >>
> >> >> --
> >> >> Sander
> >> >>
> >> >> Tuesday, September 23, 2014, 3:19:41 PM, you wrote:
> >> >>
> >> >> > Hi Peter / Sander,
> >> >>
> >> >> > Yes, I have AMD GPU passthru working as both primary and
> >> >> > secondary
> >> >> passthru.  Secondary was easy but primary is a bit tricky.
> >> >>
> >> >> > Getting on to your questions;
> >> >>
> >> >> >> Is there any specific reason you're using Xen 4.2 rather than 4.4.1?
> >> >>
> >> >> > I am working on a project that is based on Xen 4.2 (I can't say
> >> >> > any more than
> >> >> that).  I have looked at some of the more recent versions just to
> >> >> check if some of the bugs that I have seen have been fixed but I
> >> >> have not studied the newer versions in detail.  At some point in
> >> >> time in the future I would like will make the jump to a more
> >> >> recent version but I don't
> >> know the scheduling of that.
> >> >>
> >> >> >> In 4.2, using xl or xm?
> >> >>
> >> >> > xl
> >> >>
> >> >> >> qemu-traditional (with rombios) or "upstream"
> >> >>
> >> >> > qemu-traditional
> >> >>
> >> >> >> Primary or secondary passthrough?
> >> >>
> >> >> > Both but I am focusing on secondary right now.
> >> >>
> >> >> >> Presumably 64 bit versions of Windows?
> >> >>
> >> >> > 32 bit and 64 bit Win7.  I have tested Win8.1 and it works but
> >> >> > my focus is currently Win7
> >> >>
> >> >> >> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
> >> >>
> >> >> > Awesome.  My goal right now is obtaining stability on Xen 4.2.
> >> >> > Since 4.2 is
> >> >> past its feature cutoff I won't be able to submit any open source
> >> >> changes for
> >> it.
> >> >> I would like to eventually work with the community to get passthru
> >> >> working with a recent version of "upstream".
> >> >>
> >> >> > Thanks,
> >> >> > Kelly
> >> >>
> >> >>
> >> >>
> >> >> >> -----Original Message-----
> >> >> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> >> >> >> Sent: Monday, September 22, 2014 8:38 AM
> >> >> >> To: Peter Kay
> >> >> >> Cc: xen-devel@lists.xen.org; Zytaruk, Kelly
> >> >> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
> >> >> >>
> >> >> >>
> >> >> >> Monday, September 22, 2014, 2:16:58 PM, you wrote:
> >> >> >>
> >> >> >> > Hi Kelly, list
> >> >> >>
> >> >> >> > I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9.
> >> >> >> > I've been
> >> >> >> less than successful getting passthrough working at all in Xen
> >> >> >> (although it's fine in KVM primary passthrough as long as the
> >> >> >> BIOS is supplied as a file). Could I confirm the following :
> >> >> >>
> >> >> >> > Is there any specific reason you're using Xen 4.2 rather than
> >> >> >> > 4.4.1? I know in
> >> >> >> some ways 4.4 suffers as it's now xl only and some of the xm
> >> >> >> functionality has not come across.
> >> >> >>
> >> >> >> > In 4.2, using xl or xm?
> >> >> >>
> >> >> >> Another interesting question/aspect would be qemu-traditional
> >> >> >> (with
> >> >> >> rombios) or "upstream" (with seabios) ?
> >> >> >>
> >> >> >> > Primary or secondary passthrough?
> >> >> >>
> >> >> >> > Presumably 64 bit versions of Windows?
> >> >> >>
> >> >> >> > My system is a bit old (Core2Quad) but as mentioned AMD
> >> >> >> > passthrough works
> >> >> >> in KVM but I've found it tricky in Xen.
> >> >> >>
> >> >> >> > I am quite willing to test various scenarios. I've a 6950, 6450 and
> 5450.
> >> >> >>
> >> >> >> > Thanks
> >> >> >>
> >> >> >> > Peter
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>

^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: AMD GPU passthrough in Xen
  2014-09-24 15:10               ` Zytaruk, Kelly
@ 2014-09-24 15:35                 ` Sander Eikelenboom
  0 siblings, 0 replies; 17+ messages in thread
From: Sander Eikelenboom @ 2014-09-24 15:35 UTC (permalink / raw)
  To: Zytaruk, Kelly; +Cc: Gordan Bobic, xen-devel, Peter Kay


Wednesday, September 24, 2014, 5:10:41 PM, you wrote:

> This is making more sense now.  I didn't read your first message close enough.

> I didn't realize that you are running a Linux DomU.  I run Win7 in my domU. We have two completely different drivers (and groups) that support Windows vs Linux.  I don't have any problems restarting a DomU with Win7.  I haven't recently been using Linux in a DomU, that may be why I am not seeing the same problems.

> My roots were in the Windows kernel driver team. I made the move over to Xen/Linux about a year ago.  I still work very closely with the Windows team and the Windows driver.  I don't work directly on the Linux Radeon driver, I concentrate more on Xen/QEMU.  I will have to ask around the Linux team if they can provide me with any insight.

> Thanks,
> Kelly

(i also use Xen/QEMU (i'm using a HVM guest for this)

Perhaps a difference could be the windows driver always re-initinting the critical parts ?

The plus side of the linux radeon driver is that it is:
- quite verbose
- opensource .. so you can tinker with it

I have tried windows guests in the past with mixed results, but since it's more 
or less a black box i changed to first trying to get vga passthroug to a linux 
guest working :-)

However i think in general it would be best if there is a way to get the device 
in a not-posted state again by xen/dom0, instead of relying on the guest to do the right 
thing.

--
Sander



>> -----Original Message-----
>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> Sent: Wednesday, September 24, 2014 10:16 AM
>> To: Zytaruk, Kelly
>> Cc: Peter Kay; xen-devel@lists.xen.org; Gordan Bobic; Konrad Rzeszutek Wilk
>> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> 
>> 
>> Wednesday, September 24, 2014, 3:58:57 PM, you wrote:
>> 
>> > Sander,
>> 
>> > You have given me some interesting information.  First off, I would
>> > like to ask you about one of your comments;
>> 
>> >> Yes, from what i see the problem seems to be that the Radeon card is
>> >> not reset to a state were it will regard itself as "unposted". (on
>> >> the first boot of the guest i see the driver report it hasn't posted
>> >> (which is correct), it starts to past, and it works. On subsequent
>> >> boots of the domU i don't see the unposted message
>> 
>> > I am curious how you can tell if the driver is posting or not?  Which message
>> are you looking at?
>> 
>> With domU kernel 3.17-rc5 (with older kernels (i forgot the version number
>> where it got fixed) there was a problem with the secondary card getting the
>> shadow rom from the primary(emulated cirrus) ( see
>> https://lkml.org/lkml/2014/2/13/109)), so a recent kernel domU kernel is best :)
>> 
>> In the domU on first boot it says it's not posted:
>> 
>> [    4.346649] [drm] Initialized drm 1.1.0 20060810
>> [    4.359722] [drm] radeon kernel modesetting enabled.
>> [    4.380435] xen: --> pirq=32 -> irq=36 (gsi=36)
>> [    4.383891] [drm] initializing kernel modesetting (TURKS 0x1002:0x6759
>> 0x174B:0xE193).
>> [    4.405597] [drm] register mmio base: 0xF3060000
>> [    4.418262] [drm] register mmio size: 131072
>> [    4.559911] ATOM BIOS: ELIXIR
>> [    4.569063] [drm] GPU not posted. posting now...
>> [    4.585542] radeon 0000:00:05.0: VRAM: 1024M 0x0000000000000000 -
>> 0x000000003FFFFFFF (1024M used)
>> [    4.609664] radeon 0000:00:05.0: GTT: 1024M 0x0000000040000000 -
>> 0x000000007FFFFFFF
>> ....
>> 
>> In the domU on subsequent boots that message is not there, but i end up with
>> errors like (and garbage on the screen (looks somewhat like white noise)):
>> 
>> [    4.321952] [drm] Initialized drm 1.1.0 20060810
>> [    4.335246] [drm] radeon kernel modesetting enabled.
>> [    4.355349] xen: --> pirq=32 -> irq=36 (gsi=36)
>> [    4.359541] [drm] initializing kernel modesetting (TURKS 0x1002:0x6759
>> 0x174B:0xE193).
>> [    4.385655] [drm] register mmio base: 0xF3060000
>> [    4.401814] [drm] register mmio size: 131072
>> [    4.599903] ATOM BIOS: ELIXIR
>> [    4.609170] radeon 0000:00:05.0: VRAM: 1024M 0x0000000000000000 -
>> 0x000000003FFFFFFF (1024M used)
>> [    4.632895] radeon 0000:00:05.0: GTT: 1024M 0x0000000040000000 -
>> 0x000000007FFFFFFF
>> ....
>> [    5.126844] [drm:radeon_pm_init_dpm] *ERROR* radeon: dpm initialization
>> failed
>> ....
>> [    5.555322] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
>> (scratch(0x8504)=0xCAFEDEAD)
>> ....
>> 
>> (complete dmesg from both boots attached)
>> 
>> --
>> Sander
>> 
>> > Thanks,
>> > Kelly
>> 
>> >> -----Original Message-----
>> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> >> Sent: Wednesday, September 24, 2014 9:22 AM
>> >> To: Zytaruk, Kelly
>> >> Cc: Peter Kay; xen-devel@lists.xen.org; Gordan Bobic; Konrad
>> >> Rzeszutek Wilk
>> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> >>
>> >>
>> >> Wednesday, September 24, 2014, 2:12:38 PM, you wrote:
>> >>
>> >> >> Good to know there is interest from AMD into this area :-)
>> >>
>> >> > I am taking a personal interest in this and would like to improve
>> >> > AMD support
>> >> and presence within the Xen community.
>> >>
>> >> Thanks for that !
>> >>
>> >> > Gordan has also reported problems restarting a guest.
>> >>
>> >> Added Konrad to the CC as pciback maintainer.
>> >>
>> >> Yes, from what i see the problem seems to be that the Radeon card is
>> >> not reset to a state were it will regard itself as "unposted". (on
>> >> the first boot of the guest i see the driver report it hasn't posted
>> >> (which is correct), it starts to past, and it works. On subsequent
>> >> boots of the domU i don't see the unposted message but some failures
>> >> that are probably due to the driver regarding the card as already been posted
>> and skipping some init logic and reusing wrong values.
>> >>
>> >> So current xen-pciback logic doesn't seem to be able to reset the
>> >> card in a "non- posted" state.
>> >>
>> >> I don't know if you know what kind of reset is required for radeon
>> >> cards to regard itself as "not posted" ?
>> >>
>> >> Current xen-pciback logic uses the "__pci_reset_function_locked(dev);"
>> >> functions (see pcistub.c pcistub_device_release()) to try to reset the device ..
>> >> that function in turn tries some possible reset functions in a
>> >> specific order and bails out at the first one reporting "succes".
>> >> However it could be that this level of reset is not enough for this
>> >> specific case. (in my case it always uses and succeeds at the first
>> (pci_dev_specific_reset(dev, probe);).
>> >>
>> >> When looking at the code for vfio/kvm in "drivers/vfio/pci/vfio_pci.c
>> >> vfio_pci_disable()", it seems to use:
>> >> - Another order for disabling resetting and config save/restore
>> >> - Always try a slot/bus reset on the way out ..
>> >>
>> >> I'm trying to experiment with that in 2 ways:
>> >> 1) overrulling the logic in the domU radeon driver to do the reposting no
>> matter
>> >>    in what state it thinks it is.
>> >> 2) Trying to change the xen-pciback reset logic, but at present that delivers
>> >>    bad irq's to dom0 for completly different irq's as the passedthrough device
>> >>    has (which i have seen before .. and is a bit worrying)
>> >>
>> >> > I have been trying to reproduce the problem but have not had any
>> >> > luck.  As a
>> >> secondary it restarts for me every time.  I don't know if I
>> >> inadvertently made a change that indirectly fixed it in my code base or what
>> the difference might be.
>> >>
>> >> Perhaps in the older qemu-traditional there is already some sort of reset
>> done ?
>> >>
>> >> > What Xen version are you testing with?
>> >> I'm almost always living on the edge with Xen-unstable ;) (the latest
>> >> and greatest, which is actually pretty stable)
>> >>
>> >> --
>> >> Sander
>> >>
>> >> > Thanks,
>> >> > Kelly
>> >>
>> >> >> -----Original Message-----
>> >> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> >> >> Sent: Tuesday, September 23, 2014 9:45 AM
>> >> >> To: Zytaruk, Kelly
>> >> >> Cc: Peter Kay; xen-devel@lists.xen.org
>> >> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> >> >>
>> >> >> Good to know there is interest from AMD into this area :-)
>> >> >>
>> >> >> I'm experimenting for a while with:
>> >> >>
>> >> >> - xen-unstable (and thus xl)
>> >> >> - latest kernels (both dom0 and domU)
>> >> >> - qemu-xen
>> >> >> - Radeon HD 6570
>> >> >> - secondary passthrough
>> >> >> - Debian linux (sid) with the opensource (in kernel) radeon driver
>> >> >>   (i also tried fglrx with succes, but it's a real PITA to build with every
>> >> >>   new kernel, so i ditched that)
>> >> >>
>> >> >> It used to work, but something broke at the moment, but that could
>> >> >> also be the changes to the systemd cruft that Debian jessie/sid is
>> >> >> currently undergoing (or something else since i regularly update
>> >> >> all
>> >> components).
>> >> >>
>> >> >> The problems are mostly with restarting the domU, it differs a bit:
>> >> >> - sometimes screen goes ok, sometimes it's garbage.
>> >> >> - the radeon powercontrols only seem to work on the first boot and
>> >> >> give errors on any subsequent one.
>> >> >>
>> >> >> But when it works it does:
>> >> >> - the powercontrol.
>> >> >> - opengl and opencl benchmarks with (near) native results.
>> >> >> - hardware video acceleration in xbmc for instance.
>> >> >>
>> >> >> So one of the main problems at present seems to be proper
>> >> >> resetting of the whole device on domain shutdown/start. I did do
>> >> >> some experiments with the opensource radeon driver, but didn't get
>> >> >> conclusive
>> >> results out of that yet.
>> >> >>
>> >> >> --
>> >> >> Sander
>> >> >>
>> >> >> Tuesday, September 23, 2014, 3:19:41 PM, you wrote:
>> >> >>
>> >> >> > Hi Peter / Sander,
>> >> >>
>> >> >> > Yes, I have AMD GPU passthru working as both primary and
>> >> >> > secondary
>> >> >> passthru.  Secondary was easy but primary is a bit tricky.
>> >> >>
>> >> >> > Getting on to your questions;
>> >> >>
>> >> >> >> Is there any specific reason you're using Xen 4.2 rather than 4.4.1?
>> >> >>
>> >> >> > I am working on a project that is based on Xen 4.2 (I can't say
>> >> >> > any more than
>> >> >> that).  I have looked at some of the more recent versions just to
>> >> >> check if some of the bugs that I have seen have been fixed but I
>> >> >> have not studied the newer versions in detail.  At some point in
>> >> >> time in the future I would like will make the jump to a more
>> >> >> recent version but I don't
>> >> know the scheduling of that.
>> >> >>
>> >> >> >> In 4.2, using xl or xm?
>> >> >>
>> >> >> > xl
>> >> >>
>> >> >> >> qemu-traditional (with rombios) or "upstream"
>> >> >>
>> >> >> > qemu-traditional
>> >> >>
>> >> >> >> Primary or secondary passthrough?
>> >> >>
>> >> >> > Both but I am focusing on secondary right now.
>> >> >>
>> >> >> >> Presumably 64 bit versions of Windows?
>> >> >>
>> >> >> > 32 bit and 64 bit Win7.  I have tested Win8.1 and it works but
>> >> >> > my focus is currently Win7
>> >> >>
>> >> >> >> I am quite willing to test various scenarios. I've a 6950, 6450 and 5450.
>> >> >>
>> >> >> > Awesome.  My goal right now is obtaining stability on Xen 4.2.
>> >> >> > Since 4.2 is
>> >> >> past its feature cutoff I won't be able to submit any open source
>> >> >> changes for
>> >> it.
>> >> >> I would like to eventually work with the community to get passthru
>> >> >> working with a recent version of "upstream".
>> >> >>
>> >> >> > Thanks,
>> >> >> > Kelly
>> >> >>
>> >> >>
>> >> >>
>> >> >> >> -----Original Message-----
>> >> >> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> >> >> >> Sent: Monday, September 22, 2014 8:38 AM
>> >> >> >> To: Peter Kay
>> >> >> >> Cc: xen-devel@lists.xen.org; Zytaruk, Kelly
>> >> >> >> Subject: Re: [Xen-devel] AMD GPU passthrough in Xen
>> >> >> >>
>> >> >> >>
>> >> >> >> Monday, September 22, 2014, 2:16:58 PM, you wrote:
>> >> >> >>
>> >> >> >> > Hi Kelly, list
>> >> >> >>
>> >> >> >> > I see you're having AMD GPU success with Xen 4 2 and Linux 3.4.9.
>> >> >> >> > I've been
>> >> >> >> less than successful getting passthrough working at all in Xen
>> >> >> >> (although it's fine in KVM primary passthrough as long as the
>> >> >> >> BIOS is supplied as a file). Could I confirm the following :
>> >> >> >>
>> >> >> >> > Is there any specific reason you're using Xen 4.2 rather than
>> >> >> >> > 4.4.1? I know in
>> >> >> >> some ways 4.4 suffers as it's now xl only and some of the xm
>> >> >> >> functionality has not come across.
>> >> >> >>
>> >> >> >> > In 4.2, using xl or xm?
>> >> >> >>
>> >> >> >> Another interesting question/aspect would be qemu-traditional
>> >> >> >> (with
>> >> >> >> rombios) or "upstream" (with seabios) ?
>> >> >> >>
>> >> >> >> > Primary or secondary passthrough?
>> >> >> >>
>> >> >> >> > Presumably 64 bit versions of Windows?
>> >> >> >>
>> >> >> >> > My system is a bit old (Core2Quad) but as mentioned AMD
>> >> >> >> > passthrough works
>> >> >> >> in KVM but I've found it tricky in Xen.
>> >> >> >>
>> >> >> >> > I am quite willing to test various scenarios. I've a 6950, 6450 and
>> 5450.
>> >> >> >>
>> >> >> >> > Thanks
>> >> >> >>
>> >> >> >> > Peter
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >>

^ permalink raw reply	[flat|nested] 17+ messages in thread
end of thread, other threads:[~2014-09-24 15:35 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-22 12:16 AMD GPU passthrough in Xen Peter Kay
2014-09-22 12:38 ` Sander Eikelenboom
2014-09-22 14:31   ` Peter Kay
2014-09-22 15:05     ` Gordan Bobic
2014-09-23 11:22       ` Peter Kay
2014-09-23 13:19   ` Zytaruk, Kelly
2014-09-23 13:45     ` Sander Eikelenboom
2014-09-23 14:44       ` Gordan Bobic
2014-09-24 12:12       ` Zytaruk, Kelly
2014-09-24 12:56         ` Gordan Bobic
2014-09-24 13:31           ` Zytaruk, Kelly
2014-09-24 13:35             ` Gordan Bobic
2014-09-24 13:21         ` Sander Eikelenboom
2014-09-24 13:58           ` Zytaruk, Kelly
2014-09-24 14:16             ` Sander Eikelenboom
2014-09-24 15:10               ` Zytaruk, Kelly
2014-09-24 15:35                 ` Sander Eikelenboom

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.