Andrea Brugiolo
2013-Jul-26 10:32 UTC
Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
Good Morning I cannot do pciback anymore for both my second scsi controller and my second network card: when I try to pass the device to the domU I get this error in system logs: ... address space collision: [mem ...] conflicts with System RAM [mem ...] The problem is described here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717353 and is blocking my backup system which is based on a scsi tape changer attached to the domU. Thank you very much for your attention Andrea
Ian Campbell
2013-Jul-29 09:02 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote:> Good Morning > > I cannot do pciback anymore for both my second scsi controller and my > second network card: when I try to pass the device to the domU I get > this error in system logs: > > ... address space collision: [mem ...] conflicts with System RAM [mem ...]By eliding the actually addresses you''ve omitted something which I think might be interesting: [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] Note that there is not any actual overlap in those two sets of addresses... Might be that the check is truncating something, or maybe it is confusing MFN and PFN and so getting a false +ve. Both wild guesses having not even looked at the code...> The problem is described here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717353 and is > blocking my backup system which is based on a scsi tape changer > attached to the domU.What do the guest and host e820 map look like? Actually the full dmesg for the hypervisor, dom0 and domU kernels would be useful to provide, I expect. Ian.> > Thank you very much for your attention > > Andrea > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Andrea Brugiolo
2013-Jul-29 16:01 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote:> On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote: > > Good Morning > > > > I cannot do pciback anymore for both my second scsi controller and my > > second network card: when I try to pass the device to the domU I get > > this error in system logs: > > > > ... address space collision: [mem ...] conflicts with System RAM [mem ...] > > By eliding the actually addresses you''ve omitted something which I think > might be interesting: > [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > > Note that there is not any actual overlap in those two sets of addresses...Sure, I see> Might be that the check is truncating something, or maybe it is > confusing MFN and PFN and so getting a false +ve. Both wild guesses > having not even looked at the code...I apologize as my knowledge of Xen internals is very poor> > The problem is described here: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717353 and is > > blocking my backup system which is based on a scsi tape changer > > attached to the domU. > > What do the guest and host e820 map look like? Actually the full dmesg > for the hypervisor, dom0 and domU kernels would be useful to provide, I > expect.I will attach them as soon as the office operations will allow to reboot with the ill configuration (it''s a production system)> Ian.Thank you very much for your answer Andrea
Konrad Rzeszutek Wilk
2013-Jul-29 17:55 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote:> On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote: > > Good Morning > > > > I cannot do pciback anymore for both my second scsi controller and my > > second network card: when I try to pass the device to the domU I get > > this error in system logs: > > > > ... address space collision: [mem ...] conflicts with System RAM [mem ...] > > By eliding the actually addresses you''ve omitted something which I think > might be interesting: > [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > > Note that there is not any actual overlap in those two sets of addresses...I think it is: mem 0xf9e00000-0xf9e1ffff mem 0x00100000-0x4007fffff The RAM region is pretty much all of the memory. This looks like the ''e820_hole'' parameter is not being used? (It only works for xl btw).> > Might be that the check is truncating something, or maybe it is > confusing MFN and PFN and so getting a false +ve. Both wild guesses > having not even looked at the code... > > > The problem is described here: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717353 and is > > blocking my backup system which is based on a scsi tape changer > > attached to the domU. > > What do the guest and host e820 map look like? Actually the full dmesg > for the hypervisor, dom0 and domU kernels would be useful to provide, I > expect.And the guest config pls.> > Ian. > > > > > Thank you very much for your attention > > > > Andrea > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > >
Ian Campbell
2013-Jul-30 09:11 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Mon, 2013-07-29 at 13:55 -0400, Konrad Rzeszutek Wilk wrote:> On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote: > > On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote: > > > Good Morning > > > > > > I cannot do pciback anymore for both my second scsi controller and my > > > second network card: when I try to pass the device to the domU I get > > > this error in system logs: > > > > > > ... address space collision: [mem ...] conflicts with System RAM [mem ...] > > > > By eliding the actually addresses you''ve omitted something which I think > > might be interesting: > > [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > > > > Note that there is not any actual overlap in those two sets of addresses... > > I think it is: > mem 0xf9e00000-0xf9e1ffff > mem 0x00100000-0x4007fffffOops, didn''t spot that one of them had an extra digit. Worth throwing a field width into that printk so everything is physaddr width? (my grep can''t seem to find it in pciback) Ian.
Andrea Brugiolo
2013-Aug-02 09:07 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Mon, Jul 29, 2013 at 01:55:16PM -0400, Konrad Rzeszutek Wilk wrote:> On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote: > > On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote: > > > Good Morning > > > > > > I cannot do pciback anymore for both my second scsi controller and my > > > second network card: when I try to pass the device to the domU I get > > > this error in system logs: > > > > > > ... address space collision: [mem ...] conflicts with System RAM [mem ...] > > > > By eliding the actually addresses you''ve omitted something which I think > > might be interesting: > > [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > > > > Note that there is not any actual overlap in those two sets of addresses... > > I think it is: > mem 0xf9e00000-0xf9e1ffff > mem 0x00100000-0x4007fffff > > The RAM region is pretty much all of the memory. This looks like the ''e820_hole'' > parameter is not being used? (It only works for xl btw). > > > > > Might be that the check is truncating something, or maybe it is > > confusing MFN and PFN and so getting a false +ve. Both wild guesses > > having not even looked at the code... > > > > > The problem is described here: > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717353 and is > > > blocking my backup system which is based on a scsi tape changer > > > attached to the domU. > > > > What do the guest and host e820 map look like? Actually the full dmesg > > for the hypervisor, dom0 and domU kernels would be useful to provide, I > > expect. > > And the guest config pls.At last I have managed to reboot the system. Please find the attachments: - dom0 dmesg - domU dmesg - domU configuration Recall: - dom0 is Debian GNU/Linux 7.1 with Debian kernel 3.2.0-4-amd64 (3.2.46-1) - domU is Debian GNU/Linux 6.0.7 with the same kernel The "address space collision" shows up for both the devices I am trying to pass as I have been doing for years. Thank you Andrea _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Gordan Bobic
2013-Aug-02 09:27 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Fri, 2 Aug 2013 11:07:35 +0200, Andrea Brugiolo <andrea@cab.unipd.it> wrote:> On Mon, Jul 29, 2013 at 01:55:16PM -0400, Konrad Rzeszutek Wilk > wrote: >> On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote: >> > On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote: >> > > Good Morning >> > > >> > > I cannot do pciback anymore for both my second scsi controller >> and my >> > > second network card: when I try to pass the device to the domU I >> get >> > > this error in system logs: >> > > >> > > ... address space collision: [mem ...] conflicts with System >> RAM [mem ...] >> > >> > By eliding the actually addresses you''ve omitted something which I >> think >> > might be interesting: >> > [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System >> RAM [mem 0x00100000-0x4007fffff] >> > >> > Note that there is not any actual overlap in those two sets of >> addresses... >> >> I think it is: >> mem 0xf9e00000-0xf9e1ffff >> mem 0x00100000-0x4007fffff >> >> The RAM region is pretty much all of the memory. This looks like the >> ''e820_hole'' >> parameter is not being used? (It only works for xl btw).Where is the e820_hole option documented and what does it do? Gordan
Konrad Rzeszutek Wilk
2013-Aug-02 12:04 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Fri, Aug 02, 2013 at 11:07:35AM +0200, Andrea Brugiolo wrote:> On Mon, Jul 29, 2013 at 01:55:16PM -0400, Konrad Rzeszutek Wilk wrote: > > On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote: > > > On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote: > > > > Good Morning > > > > > > > > I cannot do pciback anymore for both my second scsi controller and my > > > > second network card: when I try to pass the device to the domU I get > > > > this error in system logs: > > > > > > > > ... address space collision: [mem ...] conflicts with System RAM [mem ...] > > > > > > By eliding the actually addresses you''ve omitted something which I think > > > might be interesting: > > > [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > > > > > > Note that there is not any actual overlap in those two sets of addresses... > > > > I think it is: > > mem 0xf9e00000-0xf9e1ffff > > mem 0x00100000-0x4007fffff > > > > The RAM region is pretty much all of the memory. This looks like the ''e820_hole'' > > parameter is not being used? (It only works for xl btw). > > > > > > > > Might be that the check is truncating something, or maybe it is > > > confusing MFN and PFN and so getting a false +ve. Both wild guesses > > > having not even looked at the code... > > > > > > > The problem is described here: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717353 and is > > > > blocking my backup system which is based on a scsi tape changer > > > > attached to the domU. > > > > > > What do the guest and host e820 map look like? Actually the full dmesg > > > for the hypervisor, dom0 and domU kernels would be useful to provide, I > > > expect. > > > > And the guest config pls. > > At last I have managed to reboot the system. Please find the attachments: > > - dom0 dmesg > - domU dmesg > - domU configuration > > Recall: > > - dom0 is Debian GNU/Linux 7.1 with Debian kernel 3.2.0-4-amd64 (3.2.46-1) > - domU is Debian GNU/Linux 6.0.7 with the same kernel > > The "address space collision" shows up for both the devices I am > trying to pass as I have been doing for years.So you are using ''xm'', but ''xm'' does not support ''e820_hole=1''. You need to use ''xl''. The domU E820 is as I suspected without the host E820 which is why you are hitting the issue. Note, I did at some point post an implementation of ''e820_hole=1'' argument for Xend, but since Xen is being deprecated ... it didn''t make much sense adding it in. Awaiting your response with the usage of ''xl''. Thanks!
Konrad Rzeszutek Wilk
2013-Aug-02 12:06 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Fri, Aug 02, 2013 at 10:27:04AM +0100, Gordan Bobic wrote:> On Fri, 2 Aug 2013 11:07:35 +0200, Andrea Brugiolo > <andrea@cab.unipd.it> wrote: > >On Mon, Jul 29, 2013 at 01:55:16PM -0400, Konrad Rzeszutek Wilk > >wrote: > >>On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote: > >>> On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote: > >>> > Good Morning > >>> > > >>> > I cannot do pciback anymore for both my second scsi > >>controller and my > >>> > second network card: when I try to pass the device to the > >>domU I get > >>> > this error in system logs: > >>> > > >>> > ... address space collision: [mem ...] conflicts with > >>System RAM [mem ...] > >>> > >>> By eliding the actually addresses you''ve omitted something > >>which I think > >>> might be interesting: > >>> [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with > >>System RAM [mem 0x00100000-0x4007fffff] > >>> > >>> Note that there is not any actual overlap in those two sets of > >>addresses... > >> > >>I think it is: > >>mem 0xf9e00000-0xf9e1ffff > >>mem 0x00100000-0x4007fffff > >> > >>The RAM region is pretty much all of the memory. This looks like > >>the ''e820_hole'' > >>parameter is not being used? (It only works for xl btw). > > Where is the e820_hole option documented and what does it do?It should be in the manpage (man xl.cfg). Here is a copy-n-paste: e820_host=BOOLEAN Selects whether to expose the host e820 (memory map) to the guest via the virtual e820. When this option is false (0) the guest pseudo-physical address space consists of a single contiguous RAM region. When this option is specified the virtual e820 instead reflects the host e820 and contains the same PCI holes. The total amount of RAM represented by the memory map is always the same, this option configures only how it is laid out. Exposing the host e820 to the guest gives the guest kernel the opportunity to set aside the required part of its pseudo-physical address space in order to provide address space to map passedthrough PCI devices. It is guest Operating System dependent whether this option is required, specifically it is required when using a mainline Linux ("pvops") kernel. This option defaults to true (1) if any PCI passthrough devices are configured and false (0) otherwise. If you do not configure any passthrough devices at domain creation time but expect to hotplug devices later then you should set this option. Conversely if your particular guest kernel does not require this behaviour then it is safe to allow this to be enabled but you may wish to disable it anyway.> > Gordan
Gordan Bobic
2013-Aug-02 12:19 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Fri, 2 Aug 2013 08:06:00 -0400, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:> On Fri, Aug 02, 2013 at 10:27:04AM +0100, Gordan Bobic wrote: >> On Fri, 2 Aug 2013 11:07:35 +0200, Andrea Brugiolo >> <andrea@cab.unipd.it> wrote: >> >On Mon, Jul 29, 2013 at 01:55:16PM -0400, Konrad Rzeszutek Wilk >> >wrote: >> >>On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote: >> >>> On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote: >> >>> > Good Morning >> >>> > >> >>> > I cannot do pciback anymore for both my second scsi >> >>controller and my >> >>> > second network card: when I try to pass the device to the >> >>domU I get >> >>> > this error in system logs: >> >>> > >> >>> > ... address space collision: [mem ...] conflicts with >> >>System RAM [mem ...] >> >>> >> >>> By eliding the actually addresses you''ve omitted something >> >>which I think >> >>> might be interesting: >> >>> [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with >> >>System RAM [mem 0x00100000-0x4007fffff] >> >>> >> >>> Note that there is not any actual overlap in those two sets of >> >>addresses... >> >> >> >>I think it is: >> >>mem 0xf9e00000-0xf9e1ffff >> >>mem 0x00100000-0x4007fffff >> >> >> >>The RAM region is pretty much all of the memory. This looks like >> >>the ''e820_hole'' >> >>parameter is not being used? (It only works for xl btw). >> >> Where is the e820_hole option documented and what does it do? > > It should be in the manpage (man xl.cfg). Here is a copy-n-paste: > e820_host=BOOLEAN > Selects whether to expose the host e820 (memory map) to the > guest > via the virtual e820. When this option is false (0) the guest > pseudo-physical address space consists of a single contiguous > RAM > region. When this option is specified the virtual e820 > instead > reflects the host e820 and contains the same PCI holes. The > total > amount of RAM represented by the memory map is always the > same, this > option configures only how it is laid out. > > Exposing the host e820 to the guest gives the guest kernel > the > opportunity to set aside the required part of its > pseudo-physical > address space in order to provide address space to map > passedthrough > PCI devices. It is guest Operating System dependent whether > this > option is required, specifically it is required when using a > mainline Linux ("pvops") kernel. This option defaults to true > (1) if > any PCI passthrough devices are configured and false (0) > otherwise. > If you do not configure any passthrough devices at domain > creation > time but expect to hotplug devices later then you should set > this > option. Conversely if your particular guest kernel does not > require > this behaviour then it is safe to allow this to be enabled > but you > may wish to disable it anyway.Ah, so this was a typo above. s/e820_hole/e820_host/ Thanks for clarifying. Gordan
Andrea Brugiolo
2013-Aug-02 12:30 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Fri, Aug 02, 2013 at 08:04:09AM -0400, Konrad Rzeszutek Wilk wrote:> On Fri, Aug 02, 2013 at 11:07:35AM +0200, Andrea Brugiolo wrote: > > On Mon, Jul 29, 2013 at 01:55:16PM -0400, Konrad Rzeszutek Wilk wrote: > > > On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote: > > > > On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote: > > > > > Good Morning > > > > > > > > > > I cannot do pciback anymore for both my second scsi controller and my > > > > > second network card: when I try to pass the device to the domU I get > > > > > this error in system logs: > > > > > > > > > > ... address space collision: [mem ...] conflicts with System RAM [mem ...] > > > > > > > > By eliding the actually addresses you''ve omitted something which I think > > > > might be interesting: > > > > [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > > > > > > > > Note that there is not any actual overlap in those two sets of addresses... > > > > > > I think it is: > > > mem 0xf9e00000-0xf9e1ffff > > > mem 0x00100000-0x4007fffff > > > > > > The RAM region is pretty much all of the memory. This looks like the ''e820_hole'' > > > parameter is not being used? (It only works for xl btw). > > > > > > > > > > > Might be that the check is truncating something, or maybe it is > > > > confusing MFN and PFN and so getting a false +ve. Both wild guesses > > > > having not even looked at the code... > > > > > > > > > The problem is described here: > > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717353 and is > > > > > blocking my backup system which is based on a scsi tape changer > > > > > attached to the domU. > > > > > > > > What do the guest and host e820 map look like? Actually the full dmesg > > > > for the hypervisor, dom0 and domU kernels would be useful to provide, I > > > > expect. > > > > > > And the guest config pls. > > > > At last I have managed to reboot the system. Please find the attachments: > > > > - dom0 dmesg > > - domU dmesg > > - domU configuration > > > > Recall: > > > > - dom0 is Debian GNU/Linux 7.1 with Debian kernel 3.2.0-4-amd64 (3.2.46-1) > > - domU is Debian GNU/Linux 6.0.7 with the same kernel > > > > The "address space collision" shows up for both the devices I am > > trying to pass as I have been doing for years. > > So you are using ''xm'', but ''xm'' does not support ''e820_hole=1''. You need > to use ''xl''. The domU E820 is as I suspected without the host E820 which > is why you are hitting the issue. > > Note, I did at some point post an implementation of ''e820_hole=1'' > argument for Xend, but since Xen is being deprecated ... it didn''t make > much sense adding it in. > > Awaiting your response with the usage of ''xl''.Do you really mean e820_hole=1 or do you mean e820_host=1? Thank you Andrea
Konrad Rzeszutek Wilk
2013-Aug-02 12:43 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Fri, Aug 02, 2013 at 02:30:24PM +0200, Andrea Brugiolo wrote:> On Fri, Aug 02, 2013 at 08:04:09AM -0400, Konrad Rzeszutek Wilk wrote: > > On Fri, Aug 02, 2013 at 11:07:35AM +0200, Andrea Brugiolo wrote: > > > On Mon, Jul 29, 2013 at 01:55:16PM -0400, Konrad Rzeszutek Wilk wrote: > > > > On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote: > > > > > On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote: > > > > > > Good Morning > > > > > > > > > > > > I cannot do pciback anymore for both my second scsi controller and my > > > > > > second network card: when I try to pass the device to the domU I get > > > > > > this error in system logs: > > > > > > > > > > > > ... address space collision: [mem ...] conflicts with System RAM [mem ...] > > > > > > > > > > By eliding the actually addresses you''ve omitted something which I think > > > > > might be interesting: > > > > > [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > > > > > > > > > > Note that there is not any actual overlap in those two sets of addresses... > > > > > > > > I think it is: > > > > mem 0xf9e00000-0xf9e1ffff > > > > mem 0x00100000-0x4007fffff > > > > > > > > The RAM region is pretty much all of the memory. This looks like the ''e820_hole'' > > > > parameter is not being used? (It only works for xl btw). > > > > > > > > > > > > > > Might be that the check is truncating something, or maybe it is > > > > > confusing MFN and PFN and so getting a false +ve. Both wild guesses > > > > > having not even looked at the code... > > > > > > > > > > > The problem is described here: > > > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717353 and is > > > > > > blocking my backup system which is based on a scsi tape changer > > > > > > attached to the domU. > > > > > > > > > > What do the guest and host e820 map look like? Actually the full dmesg > > > > > for the hypervisor, dom0 and domU kernels would be useful to provide, I > > > > > expect. > > > > > > > > And the guest config pls. > > > > > > At last I have managed to reboot the system. Please find the attachments: > > > > > > - dom0 dmesg > > > - domU dmesg > > > - domU configuration > > > > > > Recall: > > > > > > - dom0 is Debian GNU/Linux 7.1 with Debian kernel 3.2.0-4-amd64 (3.2.46-1) > > > - domU is Debian GNU/Linux 6.0.7 with the same kernel > > > > > > The "address space collision" shows up for both the devices I am > > > trying to pass as I have been doing for years. > > > > So you are using ''xm'', but ''xm'' does not support ''e820_hole=1''. You need > > to use ''xl''. The domU E820 is as I suspected without the host E820 which > > is why you are hitting the issue. > > > > Note, I did at some point post an implementation of ''e820_hole=1'' > > argument for Xend, but since Xen is being deprecated ... it didn''t make > > much sense adding it in. > > > > Awaiting your response with the usage of ''xl''. > > Do you really mean e820_hole=1 or do you mean e820_host=1?Oh boy. Thank you for pointing this out to me. I meant ''e820_host'' <sigh> No wonder my suggestions did not work :-(> > Thank you > > Andrea
Konrad Rzeszutek Wilk
2013-Aug-02 12:44 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
> >>>>The RAM region is pretty much all of the memory. This looks like > >>>>the ''e820_hole'' > >>>>parameter is not being used? (It only works for xl btw). > >> > >>Where is the e820_hole option documented and what does it do? > > > >It should be in the manpage (man xl.cfg). Here is a copy-n-paste: > > e820_host=BOOLEAN.. snip..> > Ah, so this was a typo above. s/e820_hole/e820_host/Yes. It is suppose to be ''e820_host=1''. Thank you for helping me realize my mistake. <sigh>
Andrea Brugiolo
2013-Aug-20 14:56 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
Good afternoon On Fri, Aug 02, 2013 at 08:04:09AM -0400, Konrad Rzeszutek Wilk wrote:> On Fri, Aug 02, 2013 at 11:07:35AM +0200, Andrea Brugiolo wrote: > > On Mon, Jul 29, 2013 at 01:55:16PM -0400, Konrad Rzeszutek Wilk wrote: > > > On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote: > > > > On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote: > > > > > Good Morning > > > > > > > > > > I cannot do pciback anymore for both my second scsi controller and my > > > > > second network card: when I try to pass the device to the domU I get > > > > > this error in system logs: > > > > > > > > > > ... address space collision: [mem ...] conflicts with System RAM [mem ...] > > > > > > > > By eliding the actually addresses you''ve omitted something which I think > > > > might be interesting: > > > > [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > > > > > > > > Note that there is not any actual overlap in those two sets of addresses... > > > > > > I think it is: > > > mem 0xf9e00000-0xf9e1ffff > > > mem 0x00100000-0x4007fffff > > > > > > The RAM region is pretty much all of the memory. This looks like the ''e820_hole'' > > > parameter is not being used? (It only works for xl btw). > > > > > > > > > > > Might be that the check is truncating something, or maybe it is > > > > confusing MFN and PFN and so getting a false +ve. Both wild guesses > > > > having not even looked at the code... > > > > > > > > > The problem is described here: > > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717353 and is > > > > > blocking my backup system which is based on a scsi tape changer > > > > > attached to the domU. > > > > > > > > What do the guest and host e820 map look like? Actually the full dmesg > > > > for the hypervisor, dom0 and domU kernels would be useful to provide, I > > > > expect. > > > > > > And the guest config pls. > > > > At last I have managed to reboot the system. Please find the attachments: > > > > - dom0 dmesg > > - domU dmesg > > - domU configuration > > > > Recall: > > > > - dom0 is Debian GNU/Linux 7.1 with Debian kernel 3.2.0-4-amd64 (3.2.46-1) > > - domU is Debian GNU/Linux 6.0.7 with the same kernel > > > > The "address space collision" shows up for both the devices I am > > trying to pass as I have been doing for years. > > So you are using ''xm'', but ''xm'' does not support ''e820_hole=1''. You need > to use ''xl''. The domU E820 is as I suspected without the host E820 which > is why you are hitting the issue. > > Note, I did at some point post an implementation of ''e820_hole=1'' > argument for Xend, but since Xen is being deprecated ... it didn''t make > much sense adding it in. > > Awaiting your response with the usage of ''xl''.Now I am using `xl'' and the e820_host = 1 option in the domU configuration but I get the same result as before and no device attached:> [ 152.098815] pcifront pci-0: Installing PCI frontend > [ 152.099141] pcifront pci-0: Creating PCI Frontend Bus 0000:09 > [ 152.100134] pci 0000:09:08.0: [1000:0030] type 0 class 0x000100 > [ 152.100666] pci 0000:09:08.0: reg 10: [io 0x5000-0x50ff] > [ 152.101055] pci 0000:09:08.0: reg 14: [mem 0xf9e00000-0xf9e1ffff 64bit] > [ 152.101465] pci 0000:09:08.0: reg 1c: [mem 0xf9e20000-0xf9e3ffff 64bit] > [ 152.103112] pci 0000:09:08.0: supports D1 D2 > [ 152.109991] pcifront pci-0: claiming resource 0000:09:08.0/0 > [ 152.110002] pcifront pci-0: claiming resource 0000:09:08.0/1 > [ 152.110010] pci 0000:09:08.0: address space collision: [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > [ 152.110023] pcifront pci-0: Could not claim resource 0000:09:08.0/1! Device offline. Try using e820_host=1 in the guest config. > [ 152.110032] pcifront pci-0: claiming resource 0000:09:08.0/3 > [ 152.110040] pci 0000:09:08.0: address space collision: [mem 0xf9e20000-0xf9e3ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > [ 152.110051] pcifront pci-0: Could not claim resource 0000:09:08.0/3! Device offline. Try using e820_host=1 in the guest config. > [ 152.110359] mptspi 0000:09:08.0: device not available (can''t reserve [mem 0xf9e00000-0xf9e1ffff 64bit]) > [ 152.110370] mptbase: ioc0: ERROR - pci_enable_device_mem() failedIs there anything else I should provide (again)? Thanks Andrea
Konrad Rzeszutek Wilk
2013-Aug-23 18:54 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
> > Awaiting your response with the usage of ''xl''. > > Now I am using `xl'' and the > > e820_host = 1 > > option in the domU configuration but I get the same result as before > and no device attached:And this is with Xen 4.2 I presume? What does your guest config look like and if you do ''xl -vvvv create '' can you attach the output? Also can you provide the full guest bootup log (xl console output).> > > [ 152.098815] pcifront pci-0: Installing PCI frontend > > [ 152.099141] pcifront pci-0: Creating PCI Frontend Bus 0000:09 > > [ 152.100134] pci 0000:09:08.0: [1000:0030] type 0 class 0x000100 > > [ 152.100666] pci 0000:09:08.0: reg 10: [io 0x5000-0x50ff] > > [ 152.101055] pci 0000:09:08.0: reg 14: [mem 0xf9e00000-0xf9e1ffff 64bit] > > [ 152.101465] pci 0000:09:08.0: reg 1c: [mem 0xf9e20000-0xf9e3ffff 64bit] > > [ 152.103112] pci 0000:09:08.0: supports D1 D2 > > [ 152.109991] pcifront pci-0: claiming resource 0000:09:08.0/0 > > [ 152.110002] pcifront pci-0: claiming resource 0000:09:08.0/1 > > [ 152.110010] pci 0000:09:08.0: address space collision: [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff]So a 16GB guest right?> > [ 152.110023] pcifront pci-0: Could not claim resource 0000:09:08.0/1! Device offline. Try using e820_host=1 in the guest config. > > [ 152.110032] pcifront pci-0: claiming resource 0000:09:08.0/3 > > [ 152.110040] pci 0000:09:08.0: address space collision: [mem 0xf9e20000-0xf9e3ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > > [ 152.110051] pcifront pci-0: Could not claim resource 0000:09:08.0/3! Device offline. Try using e820_host=1 in the guest config. > > [ 152.110359] mptspi 0000:09:08.0: device not available (can''t reserve [mem 0xf9e00000-0xf9e1ffff 64bit]) > > [ 152.110370] mptbase: ioc0: ERROR - pci_enable_device_mem() failed > > Is there anything else I should provide (again)?I am still puzzled why the ''e820_host=1'' option did not trigger for you. Did you also have ''pci=[blabla]'' in your guest config or did you do it via pci hotplugging? Thanks.
Andrea Brugiolo
2013-Aug-27 21:03 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Fri, Aug 23, 2013 at 02:54:30PM -0400, Konrad Rzeszutek Wilk wrote:> > > Awaiting your response with the usage of ''xl''. > > > > Now I am using `xl'' and the > > > > e820_host = 1 > > > > option in the domU configuration but I get the same result as before > > and no device attached: > > And this is with Xen 4.2 I presume?No, Xen 4.1 (Debian 4.1.4-3+deb7u1 Xen hypervisor and libs)> What does your guest config look like and > if you do ''xl -vvvv create '' can you attach the output? > > Also can you provide the full guest bootup log (xl console output).Please find attached: - domU configuration -> efferax.cfg - output of `xl -vvvv create'' (dom0 console) -> xl-vvvv-create.log - output of `dmesg'' in domU -> domU-dmesg.log Recall: - dom0 is Debian GNU/Linux 7.1 with Debian kernel 3.2.0-4-amd64 (3.2.46-1) and Xen 4.1.4-3+deb7u1 machinery - domU is Debian GNU/Linux 6.0.7 with the same kernel> > > [ 152.098815] pcifront pci-0: Installing PCI frontend > > > [ 152.099141] pcifront pci-0: Creating PCI Frontend Bus 0000:09 > > > [ 152.100134] pci 0000:09:08.0: [1000:0030] type 0 class 0x000100 > > > [ 152.100666] pci 0000:09:08.0: reg 10: [io 0x5000-0x50ff] > > > [ 152.101055] pci 0000:09:08.0: reg 14: [mem 0xf9e00000-0xf9e1ffff 64bit] > > > [ 152.101465] pci 0000:09:08.0: reg 1c: [mem 0xf9e20000-0xf9e3ffff 64bit] > > > [ 152.103112] pci 0000:09:08.0: supports D1 D2 > > > [ 152.109991] pcifront pci-0: claiming resource 0000:09:08.0/0 > > > [ 152.110002] pcifront pci-0: claiming resource 0000:09:08.0/1 > > > [ 152.110010] pci 0000:09:08.0: address space collision: [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > > So a 16GB guest right?Right, as you can see it in the domU config: maxmem = ''16384'' memory = ''2048'' but the ''conflict'' is still there even if I set maxmem to 2048 or leave it unset.> I am still puzzled why the ''e820_host=1'' option did not trigger for you. > Did you also have ''pci=[blabla]'' in your guest config or did you do > it via pci hotplugging?I tried both and got the same result. This last time I set the pci=[...] option in the domU config (just for the scsi controller, as you can see). Thank you very much for your attention, I really don''t have a clue! Andrea _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Konrad Rzeszutek Wilk
2013-Aug-28 15:45 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Tue, Aug 27, 2013 at 11:03:02PM +0200, Andrea Brugiolo wrote:> On Fri, Aug 23, 2013 at 02:54:30PM -0400, Konrad Rzeszutek Wilk wrote: > > > > Awaiting your response with the usage of ''xl''. > > > > > > Now I am using `xl'' and the > > > > > > e820_host = 1 > > > > > > option in the domU configuration but I get the same result as before > > > and no device attached: > > > > And this is with Xen 4.2 I presume? > > No, Xen 4.1 (Debian 4.1.4-3+deb7u1 Xen hypervisor and libs)OK, Xen 4.1 did not have the code to handle the e820_host so hence the reason for this not working :-(. You will need to upgrade to Xen 4.2 at least. I don''t know how that is done under Debian.> > > What does your guest config look like and > > if you do ''xl -vvvv create '' can you attach the output? > > > > Also can you provide the full guest bootup log (xl console output). > > Please find attached: > > - domU configuration -> efferax.cfg > - output of `xl -vvvv create'' (dom0 console) -> xl-vvvv-create.log > - output of `dmesg'' in domU -> domU-dmesg.log > > Recall: > > - dom0 is Debian GNU/Linux 7.1 with Debian kernel 3.2.0-4-amd64 > (3.2.46-1) and Xen 4.1.4-3+deb7u1 machinery > > - domU is Debian GNU/Linux 6.0.7 with the same kernel > > > > > [ 152.098815] pcifront pci-0: Installing PCI frontend > > > > [ 152.099141] pcifront pci-0: Creating PCI Frontend Bus 0000:09 > > > > [ 152.100134] pci 0000:09:08.0: [1000:0030] type 0 class 0x000100 > > > > [ 152.100666] pci 0000:09:08.0: reg 10: [io 0x5000-0x50ff] > > > > [ 152.101055] pci 0000:09:08.0: reg 14: [mem 0xf9e00000-0xf9e1ffff 64bit] > > > > [ 152.101465] pci 0000:09:08.0: reg 1c: [mem 0xf9e20000-0xf9e3ffff 64bit] > > > > [ 152.103112] pci 0000:09:08.0: supports D1 D2 > > > > [ 152.109991] pcifront pci-0: claiming resource 0000:09:08.0/0 > > > > [ 152.110002] pcifront pci-0: claiming resource 0000:09:08.0/1 > > > > [ 152.110010] pci 0000:09:08.0: address space collision: [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > > > > So a 16GB guest right? > > Right, as you can see it in the domU config: > > maxmem = ''16384'' > memory = ''2048'' > > but the ''conflict'' is still there even if I set maxmem to 2048 or > leave it unset. > > > I am still puzzled why the ''e820_host=1'' option did not trigger for you. > > Did you also have ''pci=[blabla]'' in your guest config or did you do > > it via pci hotplugging? > > I tried both and got the same result. > > This last time I set the pci=[...] option in the domU config (just for > the scsi controller, as you can see). > > Thank you very much for your attention, I really don''t have a clue! > > Andrea> # > # Configuration file for the Xen instance efferax, created > # by xen-tools 3.9 on Tue Mar 4 20:42:19 2008. > # > > # > # Kernel + memory size > # > kernel = ''/boot/vmlinuz-3.2.0-4-amd64'' > ramdisk = ''/boot/initrd.img-3.2.0-4-amd64'' > maxmem = ''16384'' > memory = ''2048'' > vcpus = 4 > > # > # Disk device(s). > # > root = ''/dev/xvda1 ro'' > disk = [ > ''phy:/dev/grp_ext02/efferax-disk,xvda1,w'', > ''phy:/dev/grp_ext02/efferax-swap,xvda2,w'', > ''phy:/dev/grp_ext02/efferax-homes,xvda3,w'', > ''phy:/dev/grp_ext12/efferax-bacula-storage,xvdb1,w'', > ''phy:/dev/grp_ext14/efferax-images-storage,xvdc1,w'', > ''phy:/dev/grp_ext15/efferax-postgresql,xvdd1,w'', > ''phy:/dev/grp_ext16/efferax-homes,xvde1,w'' > ] > > # > # Hostname > # > name = ''efferax'' > > e820_host = 1 > > # Don''t delegate the second nic > vif = [ ''ip=192.168.1.1,mac=00:16:3e:49:52:e6,bridge=xenbr1'' ] > > # Delegate just the scsi controller for the tape changer > pci = [ ''0000:09:08.0'' ] > > # Linux kernel >= 2.6.32-5-xen > extra = "iommu=soft" > > # > # Behaviour > # > on_poweroff = ''destroy'' > on_reboot = ''restart'' > on_crash = ''restart''> srv01:~# xl -vvvv create -c /etc/xen/efferax.cfg > Parsing config file /etc/xen/efferax.cfg > domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/xvda1 ro iommu=soft", features="(null)" > domainbuilder: detail: xc_dom_kernel_file: filename="/boot/vmlinuz-3.2.0-4-amd64" > domainbuilder: detail: xc_dom_malloc_filemap : 2769 kB > domainbuilder: detail: xc_dom_ramdisk_file: filename="/boot/initrd.img-3.2.0-4-amd64" > domainbuilder: detail: xc_dom_malloc_filemap : 11040 kB > domainbuilder: detail: xc_dom_boot_xen_init: ver 4.1, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 > domainbuilder: detail: xc_dom_parse_image: called > domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... > domainbuilder: detail: loader probe failed > domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... > domainbuilder: detail: xc_dom_malloc : 11430 kB > domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x2a93a1 -> 0xb299c0 > domainbuilder: detail: loader probe OK > xc: detail: elf_parse_binary: phdr: paddr=0x1000000 memsz=0x553000 > xc: detail: elf_parse_binary: phdr: paddr=0x1600000 memsz=0x950e0 > xc: detail: elf_parse_binary: phdr: paddr=0x1696000 memsz=0x14400 > xc: detail: elf_parse_binary: phdr: paddr=0x16ab000 memsz=0x292000 > xc: detail: elf_parse_binary: memory: 0x1000000 -> 0x193d000 > xc: detail: elf_xen_parse_note: GUEST_OS = "linux" > xc: detail: elf_xen_parse_note: GUEST_VERSION = "2.6" > xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0" > xc: detail: elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 > xc: detail: elf_xen_parse_note: ENTRY = 0xffffffff816ab200 > xc: detail: elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 > xc: detail: elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" > xc: detail: elf_xen_parse_note: PAE_MODE = "yes" > xc: detail: elf_xen_parse_note: LOADER = "generic" > xc: detail: elf_xen_parse_note: unknown xen elf note (0xd) > xc: detail: elf_xen_parse_note: SUSPEND_CANCEL = 0x1 > xc: detail: elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 > xc: detail: elf_xen_parse_note: PADDR_OFFSET = 0x0 > xc: detail: elf_xen_addr_calc_check: addresses: > xc: detail: virt_base = 0xffffffff80000000 > xc: detail: elf_paddr_offset = 0x0 > xc: detail: virt_offset = 0xffffffff80000000 > xc: detail: virt_kstart = 0xffffffff81000000 > xc: detail: virt_kend = 0xffffffff8193d000 > xc: detail: virt_entry = 0xffffffff816ab200 > xc: detail: p2m_base = 0xffffffffffffffff > domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0xffffffff81000000 -> 0xffffffff8193d000 > domainbuilder: detail: xc_dom_mem_init: mem 2048 MB, pages 0x80000 pages, 4k each > domainbuilder: detail: xc_dom_mem_init: 0x80000 pages > domainbuilder: detail: xc_dom_boot_mem_init: called > domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64 > domainbuilder: detail: xc_dom_malloc : 4096 kB > domainbuilder: detail: xc_dom_build_image: called > domainbuilder: detail: xc_dom_alloc_segment: kernel : 0xffffffff81000000 -> 0xffffffff8193d000 (pfn 0x1000 + 0x93d pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x1000+0x93d at 0x7fa55b123000 > xc: detail: elf_load_binary: phdr 0 at 0x0x7fa55b123000 -> 0x0x7fa55b676000 > xc: detail: elf_load_binary: phdr 1 at 0x0x7fa55b723000 -> 0x0x7fa55b7b80e0 > xc: detail: elf_load_binary: phdr 2 at 0x0x7fa55b7b9000 -> 0x0x7fa55b7cd400 > xc: detail: elf_load_binary: phdr 3 at 0x0x7fa55b7ce000 -> 0x0x7fa55b84c000 > domainbuilder: detail: xc_dom_alloc_segment: ramdisk : 0xffffffff8193d000 -> 0xffffffff8392e000 (pfn 0x193d + 0x1ff1 pages) > domainbuilder: detail: xc_dom_malloc : 191 kB > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x193d+0x1ff1 at 0x7fa559132000 > domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0xac836c -> 0x1ff0810 > domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0xffffffff8392e000 -> 0xffffffff83d2e000 (pfn 0x392e + 0x400 pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x392e+0x400 at 0x7fa558d32000 > domainbuilder: detail: xc_dom_alloc_page : start info : 0xffffffff83d2e000 (pfn 0x3d2e) > domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xffffffff83d2f000 (pfn 0x3d2f) > domainbuilder: detail: xc_dom_alloc_page : console : 0xffffffff83d30000 (pfn 0x3d30) > domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0xffff000000000000 -> 0xffffffffffffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0xffffff8000000000 -> 0xffffffffffffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0xffffffff80000000 -> 0xffffffffbfffffff, 1 table(s) > domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0xffffffff80000000 -> 0xffffffff83ffffff, 32 table(s) > domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xffffffff83d31000 -> 0xffffffff83d54000 (pfn 0x3d31 + 0x23 pages) > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x3d31+0x23 at 0x7fa55f564000 > domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xffffffff83d54000 (pfn 0x3d54) > domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xffffffff83d55000 > domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xffffffff84000000 > domainbuilder: detail: xc_dom_boot_image: called > domainbuilder: detail: arch_setup_bootearly: doing nothing > domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 <= matches > domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p > domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 > domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p > domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64 > domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x80000 > domainbuilder: detail: clear_page: pfn 0x3d30, mfn 0x61eae2 > domainbuilder: detail: clear_page: pfn 0x3d2f, mfn 0x32b887 > domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x3d2e+0x1 at 0x7fa55f599000 > domainbuilder: detail: start_info_x86_64: called > domainbuilder: detail: setup_hypercall_page: vaddr=0xffffffff81001000 pfn=0x1001 > domainbuilder: detail: domain builder memory footprint > domainbuilder: detail: allocated > domainbuilder: detail: malloc : 15801 kB > domainbuilder: detail: anon mmap : 0 bytes > domainbuilder: detail: mapped > domainbuilder: detail: file mmap : 13810 kB > domainbuilder: detail: domU mmap : 45 MB > domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xcfc4e > domainbuilder: detail: shared_info_x86_64: called > domainbuilder: detail: vcpu_x86_64: called > domainbuilder: detail: vcpu_x86_64: cr3: pfn 0x3d31 mfn 0x32b886 > domainbuilder: detail: launch_vm: called, ctxt=0x7fff0bfcd3d0 > domainbuilder: detail: xc_dom_release: called > libxl: debug: libxl_pci.c:254:libxl_create_pci_backend Creating pci backend > Daemon running with PID 18058 > [ 0.000000] Initializing cgroup subsys cpuset > [ 0.000000] Initializing cgroup subsys cpu > [ 0.000000] Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.46-1 > [ 0.000000] Command line: root=/dev/xvda1 ro iommu=soft > [ 0.000000] ACPI in unprivileged domain disabled > [ 0.000000] Released 0 pages of unused memory > [ 0.000000] Set 0 page(s) to 1-1 mapping > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable) > [ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved) > [ 0.000000] Xen: 0000000000100000 - 0000000400800000 (usable) > [ 0.000000] NX (Execute Disable) protection: active > [ 0.000000] DMI not present or invalid. > [ 0.000000] No AGP bridge found > [ 0.000000] last_pfn = 0x400800 max_arch_pfn = 0x400000000 > [ 0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000 > [ 0.000000] init_memory_mapping: 0000000000000000-0000000100000000 > [ 0.000000] init_memory_mapping: 0000000100000000-0000000400800000 > [ 0.000000] RAMDISK: 0193d000 - 0392e000 > [ 0.000000] NUMA turned off > [ 0.000000] Faking a node at 0000000000000000-0000000400800000 > [ 0.000000] Initmem setup node 0 0000000000000000-0000000400800000 > [ 0.000000] NODE_DATA [000000007e7e9000 - 000000007e7edfff] > [ 0.000000] Zone PFN ranges: > [ 0.000000] DMA 0x00000010 -> 0x00001000 > [ 0.000000] DMA32 0x00001000 -> 0x00100000 > [ 0.000000] Normal 0x00100000 -> 0x00400800 > [ 0.000000] Movable zone start PFN for each node > [ 0.000000] early_node_map[2] active PFN ranges > [ 0.000000] 0: 0x00000010 -> 0x000000a0 > [ 0.000000] 0: 0x00000100 -> 0x00400800 > [ 0.000000] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org > [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs > [ 0.000000] No local APIC present > [ 0.000000] APIC: disable apic facility > [ 0.000000] APIC: switched to apic NOOP > [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000 > [ 0.000000] PCI: Warning: Cannot find a gap in the 32bit address range > [ 0.000000] PCI: Unassigned devices with 32bit resource registers may break! > [ 0.000000] Allocating PCI resources starting at 400900000 (gap: 400900000:400000) > [ 0.000000] Booting paravirtualized kernel on Xen > [ 0.000000] Xen version: 4.1.4 (preserve-AD) > [ 0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:4 nr_node_ids:1 > [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88007e400000 s82944 r8192 d23552 u524288 > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 4136848 > [ 0.000000] Policy zone: Normal > [ 0.000000] Kernel command line: root=/dev/xvda1 ro iommu=soft > [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) > [ 0.000000] Placing 64MB software IO TLB between ffff880069c00000 - ffff88006dc00000 > [ 0.000000] software IO TLB at phys 0x69c00000 - 0x6dc00000 > [ 0.000000] Memory: 1720324k/16785408k available (3425k kernel code, 448k absent, 15064636k reserved, 3314k data, 576k init) > [ 0.000000] Hierarchical RCU implementation. > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > [ 0.000000] NR_IRQS:33024 nr_irqs:304 16 > [ 0.000000] Console: colour dummy device 80x25 > [ 0.000000] console [tty0] enabled > [ 0.000000] console [hvc0] enabled > [ 0.000000] installing Xen timer for CPU 0 > [ 0.000000] Detected 2400.188 MHz processor. > [ 0.000000] Marking TSC unstable due to TSCs unsynchronized > [ 0.004000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4800.37 BogoMIPS (lpj=9600752) > [ 0.004000] pid_max: default: 32768 minimum: 301 > [ 0.004000] Security Framework initialized > [ 0.004000] AppArmor: AppArmor disabled by boot time parameter > [ 0.006262] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) > [ 0.020001] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) > [ 0.025607] Mount-cache hash table entries: 256 > [ 0.025813] Initializing cgroup subsys cpuacct > [ 0.025826] Initializing cgroup subsys memory > [ 0.025850] Initializing cgroup subsys devices > [ 0.025857] Initializing cgroup subsys freezer > [ 0.025863] Initializing cgroup subsys net_cls > [ 0.025869] Initializing cgroup subsys blkio > [ 0.025883] Initializing cgroup subsys perf_event > [ 0.026040] CPU: Physical Processor ID: 1 > [ 0.026046] CPU: Processor Core ID: 0 > [ 0.026077] SMP alternatives: switching to UP code > [ 0.043264] Performance Events: > [ 0.043273] no APIC, boot with the "lapic" boot parameter to force-enable it. > [ 0.043281] no hardware sampling interrupt available. > [ 0.043303] Broken PMU hardware detected, using software events only. > [ 0.043537] NMI watchdog disabled (cpu0): hardware events not enabled > [ 0.043732] installing Xen timer for CPU 1 > [ 0.043790] SMP alternatives: switching to SMP code > [ 0.060336] NMI watchdog disabled (cpu1): hardware events not enabled > [ 0.060525] installing Xen timer for CPU 2 > [ 0.060735] NMI watchdog disabled (cpu2): hardware events not enabled > [ 0.060908] installing Xen timer for CPU 3 > [ 0.061170] NMI watchdog disabled (cpu3): hardware events not enabled > [ 0.061207] Brought up 4 CPUs > [ 0.061373] devtmpfs: initialized > [ 0.066314] Grant table initialized > [ 0.066314] print_constraints: dummy: > [ 0.066314] NET: Registered protocol family 16 > [ 0.066314] PCI: setting up Xen PCI frontend stub > [ 0.068914] bio: create slab <bio-0> at 0 > [ 0.068914] ACPI: Interpreter disabled. > [ 0.068914] xen/balloon: Initialising balloon driver. > [ 0.172065] xen-balloon: Initialising balloon driver. > [ 0.173044] vgaarb: loaded > [ 0.173044] PCI: System does not support PCI > [ 0.173044] PCI: System does not support PCI > [ 0.173044] Switching to clocksource xen > [ 0.174395] pnp: PnP ACPI: disabled > [ 0.179206] NET: Registered protocol family 2 > [ 0.180947] IP route cache hash table entries: 524288 (order: 10, 4194304 bytes) > [ 0.187833] TCP established hash table entries: 524288 (order: 11, 8388608 bytes) > [ 0.193673] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) > [ 0.194302] TCP: Hash tables configured (established 524288 bind 65536) > [ 0.194315] TCP reno registered > [ 0.194439] UDP hash table entries: 8192 (order: 6, 262144 bytes) > [ 0.194721] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes) > [ 0.195093] NET: Registered protocol family 1 > [ 0.195181] Unpacking initramfs... > [ 0.265248] Freeing initrd memory: 32708k freed > [ 0.288426] platform rtc_cmos: registered platform RTC device (no PNP device found) > [ 0.289021] audit: initializing netlink socket (disabled) > [ 0.289054] type=2000 audit(1377634607.461:1): initialized > [ 0.305251] HugeTLB registered 2 MB page size, pre-allocated 0 pages > [ 0.305935] VFS: Disk quotas dquot_6.5.2 > [ 0.306016] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > [ 0.306161] msgmni has been set to 3423 > [ 0.306592] alg: No test for stdrng (krng) > [ 0.306684] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) > [ 0.306700] io scheduler noop registered > [ 0.306705] io scheduler deadline registered > [ 0.306770] io scheduler cfq registered (default) > [ 0.306892] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > [ 0.306930] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 > [ 0.306938] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > [ 0.307726] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > [ 0.476269] Linux agpgart interface v0.103 > [ 0.476397] i8042: PNP: No PS/2 controller found. Probing ports directly. > [ 1.486246] i8042: No controller found > [ 1.486489] mousedev: PS/2 mouse device common for all mice > [ 1.526382] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 > [ 1.526467] rtc_cmos: probe of rtc_cmos failed with error -38 > [ 1.526786] TCP cubic registered > [ 1.526982] NET: Registered protocol family 10 > [ 1.527604] Mobile IPv6 > [ 1.527614] NET: Registered protocol family 17 > [ 1.527623] Registering the dns_resolver key type > [ 1.527989] registered taskstats version 1 > [ 1.528031] XENBUS: Device with no driver: device/vbd/51713 > [ 1.528038] XENBUS: Device with no driver: device/vbd/51714 > [ 1.528044] XENBUS: Device with no driver: device/vbd/51715 > [ 1.528050] XENBUS: Device with no driver: device/vbd/51729 > [ 1.528080] XENBUS: Device with no driver: device/vbd/51745 > [ 1.528087] XENBUS: Device with no driver: device/vbd/51761 > [ 1.528093] XENBUS: Device with no driver: device/vbd/51777 > [ 1.528099] XENBUS: Device with no driver: device/vif/0 > [ 1.528105] XENBUS: Device with no driver: device/pci/0 > [ 1.528121] /build/linux-s5x2oE/linux-3.2.46/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) > [ 1.528157] Initializing network drop monitor service > [ 1.528627] Freeing unused kernel memory: 576k freed > [ 1.528948] Write protecting the kernel read-only data: 6144k > [ 1.533486] Freeing unused kernel memory: 652k freed > [ 1.534419] Freeing unused kernel memory: 692k freed > Loading, please wait... > [ 1.575804] udevd[60]: starting version 175 > [ 1.591209] input: PC Speaker as /devices/platform/pcspkr/input/input0 > [ 1.612023] Initialising Xen virtual ethernet driver. > [ 1.673559] blkfront: xvda1: barrier or flush: disabled > [ 1.679525] blkfront: xvda2: barrier or flush: disabled > [ 1.681532] Setting capacity to 62914560 > [ 1.685275] blkfront: xvda3: barrier or flush: disabled > [ 1.690960] blkfront: xvdb1: barrier or flush: disabled > [ 1.694827] blkfront: xvdc1: barrier or flush: disabled > [ 1.702850] blkfront: xvdd1: barrier or flush: disabled > [ 1.705665] Setting capacity to 4194304 > [ 1.706653] blkfront: xvde1: barrier or flush: disabled > [ 1.713448] Setting capacity to 587198464 > [ 1.713741] Setting capacity to 69197824 > [ 1.714187] Setting capacity to 446685184 > [ 1.714627] Setting capacity to 232775680 > [ 1.714642] xvdd1: detected capacity change from 0 to 119181148160 > [ 1.715104] Setting capacity to 1331683328 > Begin: Loading essential drivers ... [ 2.322690] SCSI subsystem initialized > [ 2.323661] SCSI Media Changer driver v0.25 > [ 2.364323] RPC: Registered named UNIX socket transport module. > [ 2.364341] RPC: Registered udp transport module. > [ 2.364346] RPC: Registered tcp transport module. > [ 2.364352] RPC: Registered tcp NFSv4.1 backchannel transport module. > [ 2.376933] Fusion MPT base driver 3.04.20 > [ 2.376950] Copyright (c) 1999-2008 LSI Corporation > [ 2.390208] Fusion MPT SPI Host driver 3.04.20 > [ 2.396782] FS-Cache: Loaded > [ 2.409835] FS-Cache: Netfs ''nfs'' registered for caching > [ 2.424190] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). > [ 2.453341] st: Version 20101219, fixed bufsize 32768, s/g segs 256 > done. > Begin: Running /scripts/init-premount ... done. > Begin: Mounting root file system ... Begin: Running /scripts/local-top ... [ 2.467341] device-mapper: uevent: version 1.0.3 > [ 2.467536] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com > done. > Begin: Running /scripts/local-premount ... done. > [ 2.683099] kjournald starting. Commit interval 5 seconds > [ 2.683129] EXT3-fs (xvda1): mounted filesystem with ordered data mode > Begin: Running /scripts/local-bottom ... done. > done. > Begin: Running /scripts/init-bottom ... done. > INIT: version 2.88 booting > Using makefile-style concurrent boot in runlevel S. > Starting the hotplug events dispatcher: udevd[ 5.344134] udev[221]: starting version 164 > . > Synthesizing the initial hotplug events...done. > Waiting for /dev to be fully populated...[ 5.866353] pcifront pci-0: Installing PCI frontend > [ 5.866651] pcifront pci-0: Creating PCI Frontend Bus 0000:09 > [ 5.871583] pcifront pci-0: claiming resource 0000:09:08.0/0 > [ 5.871595] pcifront pci-0: claiming resource 0000:09:08.0/1 > [ 5.871603] pci 0000:09:08.0: address space collision: [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > [ 5.871616] pcifront pci-0: Could not claim resource 0000:09:08.0/1! Device offline. Try using e820_host=1 in the guest config. > [ 5.871626] pcifront pci-0: claiming resource 0000:09:08.0/3 > [ 5.871634] pci 0000:09:08.0: address space collision: [mem 0xf9e20000-0xf9e3ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > [ 5.871646] pcifront pci-0: Could not claim resource 0000:09:08.0/3! Device offline. Try using e820_host=1 in the guest config. > [ 5.872618] mptspi 0000:09:08.0: device not available (can''t reserve [mem 0xf9e00000-0xf9e1ffff 64bit]) > [ 5.872630] mptbase: ioc0: ERROR - pci_enable_device_mem() failed > [ 6.159193] powernow-k8: Found 1 Dual-Core AMD Opteron(tm) Processor 2216 (4 cpu cores) (version 2.20.00) > [ 6.159226] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects found. > [ 6.159228] [Firmware Bug]: powernow-k8: Try again with latest BIOS. > done. > hwclockfirst.sh: Permission denied > Activating swap...[ 6.850939] Adding 2097148k swap on /dev/xvda2. Priority:-1 extents:1 across:2097148k SS > [ 6.862659] Adding 34598908k swap on /dev/xvdb1. Priority:-2 extents:1 across:34598908k SS > done. > Checking root file system...fsck from util-linux-ng 2.17.2 > /dev/xvda1: clean, 169122/1966080 files, 5041466/7864320 blocks > done. > [ 7.508893] EXT3-fs (xvda1): using internal journal > hwclock.sh: Permission denied > Loading kernel modules...done. > Cleaning up ifupdown.... > Setting up networking.... > Activating lvm and md swap...done. > Checking file systems...fsck from util-linux-ng 2.17.2 > /dev/xvda3: clean, 458413/18350080 files, 54337315/73399808 blocks > /dev/xvdc1: clean, 360/13959168 files, 37131025/55835648 blocks > /dev/xvdd1: clean, 2291/7274496 files, 13387767/29096960 blocks > /dev/xvde1: clean, 837456/41615360 files, 79713261/166460416 blocks > done. > Mounting local filesystems...[ 10.411287] kjournald starting. Commit interval 5 seconds > [ 10.411746] EXT3-fs (xvda3): using internal journal > [ 10.411766] EXT3-fs (xvda3): mounted filesystem with ordered data mode > mount: il mount point /home/images non esiste > [ 10.969165] kjournald starting. Commit interval 5 seconds > [ 10.969552] EXT3-fs (xvdd1): using internal journal > [ 10.969566] EXT3-fs (xvdd1): mounted filesystem with ordered data mode > [ 11.048772] kjournald starting. Commit interval 5 seconds > [ 11.049945] EXT3-fs (xvde1): using internal journal > [ 11.049960] EXT3-fs (xvde1): mounted filesystem with ordered data mode > failed. > Activating swapfile swap...done. > Cleaning up temporary files.... > Setting kernel variables ...done. > Configuring network interfaces...done. > Starting portmap daemon.... > Starting NFS common utilities: statd idmapd gssd. > Cleaning up temporary files.... > Setting up ALSA...done (none loaded). > Setting console screen modes and fonts. > cannot (un)set powersave mode > ng sensors limits. > startpar: service(s) returned failure: hwclockfirst.sh hwclock.sh ... failed! > INIT: Entering runlevel: 2 > Using makefile-style concurrent boot in runlevel 2. > Starting portmap daemon...Already running.. > Starting uptime daemon: ud. > ud[767]: Uptime daemon starting... > Starting NFS common utilities: statd idmapd gssd. > [ 22.208282] svc: failed to register lockdv1 RPC service (errno 97). > [ 22.208411] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory > [ 22.246487] NFSD: starting 90-second grace period > Exporting directories for NFS kernel daemon.... > Starting NFS kernel daemon: nfsd svcgssd mountd. > Starting enhanced syslogd: rsyslogd. > Turning on process accounting, file set to ''/var/log/account/pacct''. > Done.. > Starting Samba daemons: nmbd smbd. > Starting web server: apache2. > Starting Ethernet/FDDI station monitor daemon: (chown arpwatch /var/lib/arpwatch/arp.dat) arpwatch. > Starting deferred execution scheduler: atd. > Starting Bacula Storage daemon...:. > Starting Bacula File daemon...:. > Starting Bacula Director...:. > Starting internet superserver: inetd. > Starting Name Service Cache Daemon: nscd. > Starting NTP server: ntpd. > Starting ClamAV daemon: clamd LibClamAV Warning: ************************************************** > LibClamAV Warning: *** The virus database is older than 7 days! *** > LibClamAV Warning: *** Please update it as soon as possible. *** > LibClamAV Warning: ************************************************** > LibClamAV Warning: *********************************************************** > LibClamAV Warning: *** This version of the ClamAV engine is outdated. *** > LibClamAV Warning: *** DON''T PANIC! Read http://www.clamav.net/support/faq *** > LibClamAV Warning: *********************************************************** > . > Starting virtual private network daemon:. > Starting ClamAV virus database updater: freshclam. > Starting periodic command scheduler: cron. > Starting the system activity data collector: sadc. > [ 51.248126] sshd (1438): /proc/1438/oom_adj is deprecated, please use /proc/1438/oom_score_adj instead. > Starting OpenBSD Secure Shell server: sshd. > Starting postfix greylisting daemon: postgrey. > Starting PostgreSQL 8.4 database server: main. > Starting Slony-I daemon:. > Starting Postfix Mail Transport Agent: postfix. > Starting Munin-Node: done. > > Debian GNU/Linux 6.0 efferax hvc0 > > efferax login:> [ 0.000000] Initializing cgroup subsys cpuset > [ 0.000000] Initializing cgroup subsys cpu > [ 0.000000] Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.46-1 > [ 0.000000] Command line: root=/dev/xvda1 ro iommu=soft > [ 0.000000] ACPI in unprivileged domain disabled > [ 0.000000] Released 0 pages of unused memory > [ 0.000000] Set 0 page(s) to 1-1 mapping > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable) > [ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved) > [ 0.000000] Xen: 0000000000100000 - 0000000400800000 (usable) > [ 0.000000] NX (Execute Disable) protection: active > [ 0.000000] DMI not present or invalid. > [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) > [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable) > [ 0.000000] No AGP bridge found > [ 0.000000] last_pfn = 0x400800 max_arch_pfn = 0x400000000 > [ 0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000 > [ 0.000000] initial memory mapped : 0 - 0392e000 > [ 0.000000] Base memory trampoline at [ffff88000009b000] 9b000 size 20480 > [ 0.000000] init_memory_mapping: 0000000000000000-0000000100000000 > [ 0.000000] 0000000000 - 0100000000 page 4k > [ 0.000000] kernel direct mapping tables up to 100000000 @ 7fb000-1000000 > [ 0.000000] xen: setting RW the range fda000 - 1000000 > [ 0.000000] init_memory_mapping: 0000000100000000-0000000400800000 > [ 0.000000] 0100000000 - 0400800000 page 4k > [ 0.000000] kernel direct mapping tables up to 400800000 @ 7e7ee000-80000000 > [ 0.000000] xen: setting RW the range 7ffff000 - 80000000 > [ 0.000000] RAMDISK: 0193d000 - 0392e000 > [ 0.000000] NUMA turned off > [ 0.000000] Faking a node at 0000000000000000-0000000400800000 > [ 0.000000] Initmem setup node 0 0000000000000000-0000000400800000 > [ 0.000000] NODE_DATA [000000007e7e9000 - 000000007e7edfff] > [ 0.000000] Zone PFN ranges: > [ 0.000000] DMA 0x00000010 -> 0x00001000 > [ 0.000000] DMA32 0x00001000 -> 0x00100000 > [ 0.000000] Normal 0x00100000 -> 0x00400800 > [ 0.000000] Movable zone start PFN for each node > [ 0.000000] early_node_map[2] active PFN ranges > [ 0.000000] 0: 0x00000010 -> 0x000000a0 > [ 0.000000] 0: 0x00000100 -> 0x00400800 > [ 0.000000] On node 0 totalpages: 4196240 > [ 0.000000] DMA zone: 56 pages used for memmap > [ 0.000000] DMA zone: 2020 pages reserved > [ 0.000000] DMA zone: 1908 pages, LIFO batch:0 > [ 0.000000] DMA32 zone: 14280 pages used for memmap > [ 0.000000] DMA32 zone: 1030200 pages, LIFO batch:31 > [ 0.000000] Normal zone: 43036 pages used for memmap > [ 0.000000] Normal zone: 3104740 pages, LIFO batch:31 > [ 0.000000] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org > [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs > [ 0.000000] No local APIC present > [ 0.000000] APIC: disable apic facility > [ 0.000000] APIC: switched to apic NOOP > [ 0.000000] nr_irqs_gsi: 16 > [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000 > [ 0.000000] PCI: Warning: Cannot find a gap in the 32bit address range > [ 0.000000] PCI: Unassigned devices with 32bit resource registers may break! > [ 0.000000] Allocating PCI resources starting at 400900000 (gap: 400900000:400000) > [ 0.000000] Booting paravirtualized kernel on Xen > [ 0.000000] Xen version: 4.1.4 (preserve-AD) > [ 0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:4 nr_node_ids:1 > [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88007e400000 s82944 r8192 d23552 u524288 > [ 0.000000] pcpu-alloc: s82944 r8192 d23552 u524288 alloc=1*2097152 > [ 0.000000] pcpu-alloc: [0] 0 1 2 3 > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 4136848 > [ 0.000000] Policy zone: Normal > [ 0.000000] Kernel command line: root=/dev/xvda1 ro iommu=soft > [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) > [ 0.000000] Placing 64MB software IO TLB between ffff880069c00000 - ffff88006dc00000 > [ 0.000000] software IO TLB at phys 0x69c00000 - 0x6dc00000 > [ 0.000000] Memory: 1720324k/16785408k available (3425k kernel code, 448k absent, 15064636k reserved, 3314k data, 576k init) > [ 0.000000] Hierarchical RCU implementation. > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > [ 0.000000] NR_IRQS:33024 nr_irqs:304 16 > [ 0.000000] Console: colour dummy device 80x25 > [ 0.000000] console [tty0] enabled > [ 0.000000] console [hvc0] enabled > [ 0.000000] Xen: using vcpuop timer interface > [ 0.000000] installing Xen timer for CPU 0 > [ 0.000000] Detected 2400.188 MHz processor. > [ 0.000000] Marking TSC unstable due to TSCs unsynchronized > [ 0.004000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4800.37 BogoMIPS (lpj=9600752) > [ 0.004000] pid_max: default: 32768 minimum: 301 > [ 0.004000] Security Framework initialized > [ 0.004000] AppArmor: AppArmor disabled by boot time parameter > [ 0.006262] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) > [ 0.020001] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) > [ 0.025607] Mount-cache hash table entries: 256 > [ 0.025813] Initializing cgroup subsys cpuacct > [ 0.025826] Initializing cgroup subsys memory > [ 0.025850] Initializing cgroup subsys devices > [ 0.025857] Initializing cgroup subsys freezer > [ 0.025863] Initializing cgroup subsys net_cls > [ 0.025869] Initializing cgroup subsys blkio > [ 0.025883] Initializing cgroup subsys perf_event > [ 0.026029] tseg: 0000000000 > [ 0.026040] CPU: Physical Processor ID: 1 > [ 0.026046] CPU: Processor Core ID: 0 > [ 0.026077] SMP alternatives: switching to UP code > [ 0.043264] Performance Events: > [ 0.043273] no APIC, boot with the "lapic" boot parameter to force-enable it. > [ 0.043281] no hardware sampling interrupt available. > [ 0.043303] Broken PMU hardware detected, using software events only. > [ 0.043537] NMI watchdog disabled (cpu0): hardware events not enabled > [ 0.043732] installing Xen timer for CPU 1 > [ 0.043790] SMP alternatives: switching to SMP code > [ 0.060336] NMI watchdog disabled (cpu1): hardware events not enabled > [ 0.060525] installing Xen timer for CPU 2 > [ 0.060735] NMI watchdog disabled (cpu2): hardware events not enabled > [ 0.060908] installing Xen timer for CPU 3 > [ 0.061170] NMI watchdog disabled (cpu3): hardware events not enabled > [ 0.061207] Brought up 4 CPUs > [ 0.061373] devtmpfs: initialized > [ 0.066314] Grant table initialized > [ 0.066314] print_constraints: dummy: > [ 0.066314] NET: Registered protocol family 16 > [ 0.066314] PCI: setting up Xen PCI frontend stub > [ 0.066314] PCI: pci_cache_line_size set to 64 bytes > [ 0.068914] bio: create slab <bio-0> at 0 > [ 0.068914] ACPI: Interpreter disabled. > [ 0.068914] xen/balloon: Initialising balloon driver. > [ 0.172065] xen-balloon: Initialising balloon driver. > [ 0.173044] vgaarb: loaded > [ 0.173044] PCI: System does not support PCI > [ 0.173044] PCI: System does not support PCI > [ 0.173044] Switching to clocksource xen > [ 0.174395] pnp: PnP ACPI: disabled > [ 0.179072] PCI: max bus depth: 0 pci_try_num: 1 > [ 0.179206] NET: Registered protocol family 2 > [ 0.180947] IP route cache hash table entries: 524288 (order: 10, 4194304 bytes) > [ 0.187833] TCP established hash table entries: 524288 (order: 11, 8388608 bytes) > [ 0.193673] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) > [ 0.194302] TCP: Hash tables configured (established 524288 bind 65536) > [ 0.194315] TCP reno registered > [ 0.194439] UDP hash table entries: 8192 (order: 6, 262144 bytes) > [ 0.194721] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes) > [ 0.195093] NET: Registered protocol family 1 > [ 0.195109] PCI: CLS 0 bytes, default 64 > [ 0.195181] Unpacking initramfs... > [ 0.265248] Freeing initrd memory: 32708k freed > [ 0.288426] platform rtc_cmos: registered platform RTC device (no PNP device found) > [ 0.289021] audit: initializing netlink socket (disabled) > [ 0.289054] type=2000 audit(1377634607.461:1): initialized > [ 0.305251] HugeTLB registered 2 MB page size, pre-allocated 0 pages > [ 0.305935] VFS: Disk quotas dquot_6.5.2 > [ 0.306016] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > [ 0.306161] msgmni has been set to 3423 > [ 0.306592] alg: No test for stdrng (krng) > [ 0.306684] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) > [ 0.306700] io scheduler noop registered > [ 0.306705] io scheduler deadline registered > [ 0.306770] io scheduler cfq registered (default) > [ 0.306892] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > [ 0.306930] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 > [ 0.306938] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > [ 0.307726] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > [ 0.476269] Linux agpgart interface v0.103 > [ 0.476397] i8042: PNP: No PS/2 controller found. Probing ports directly. > [ 1.486246] i8042: No controller found > [ 1.486489] mousedev: PS/2 mouse device common for all mice > [ 1.526382] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 > [ 1.526467] rtc_cmos: probe of rtc_cmos failed with error -38 > [ 1.526786] TCP cubic registered > [ 1.526982] NET: Registered protocol family 10 > [ 1.527604] Mobile IPv6 > [ 1.527614] NET: Registered protocol family 17 > [ 1.527623] Registering the dns_resolver key type > [ 1.527960] PM: Hibernation image not present or could not be loaded. > [ 1.527989] registered taskstats version 1 > [ 1.528031] XENBUS: Device with no driver: device/vbd/51713 > [ 1.528038] XENBUS: Device with no driver: device/vbd/51714 > [ 1.528044] XENBUS: Device with no driver: device/vbd/51715 > [ 1.528050] XENBUS: Device with no driver: device/vbd/51729 > [ 1.528080] XENBUS: Device with no driver: device/vbd/51745 > [ 1.528087] XENBUS: Device with no driver: device/vbd/51761 > [ 1.528093] XENBUS: Device with no driver: device/vbd/51777 > [ 1.528099] XENBUS: Device with no driver: device/vif/0 > [ 1.528105] XENBUS: Device with no driver: device/pci/0 > [ 1.528121] /build/linux-s5x2oE/linux-3.2.46/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) > [ 1.528157] Initializing network drop monitor service > [ 1.528627] Freeing unused kernel memory: 576k freed > [ 1.528948] Write protecting the kernel read-only data: 6144k > [ 1.533486] Freeing unused kernel memory: 652k freed > [ 1.534419] Freeing unused kernel memory: 692k freed > [ 1.575804] udevd[60]: starting version 175 > [ 1.591209] input: PC Speaker as /devices/platform/pcspkr/input/input0 > [ 1.612023] Initialising Xen virtual ethernet driver. > [ 1.673559] blkfront: xvda1: barrier or flush: disabled > [ 1.679525] blkfront: xvda2: barrier or flush: disabled > [ 1.681532] Setting capacity to 62914560 > [ 1.685275] blkfront: xvda3: barrier or flush: disabled > [ 1.690960] blkfront: xvdb1: barrier or flush: disabled > [ 1.694827] blkfront: xvdc1: barrier or flush: disabled > [ 1.702850] blkfront: xvdd1: barrier or flush: disabled > [ 1.705665] Setting capacity to 4194304 > [ 1.706653] blkfront: xvde1: barrier or flush: disabled > [ 1.713448] Setting capacity to 587198464 > [ 1.713741] Setting capacity to 69197824 > [ 1.714187] Setting capacity to 446685184 > [ 1.714627] Setting capacity to 232775680 > [ 1.714642] xvdd1: detected capacity change from 0 to 119181148160 > [ 1.715104] Setting capacity to 1331683328 > [ 2.322690] SCSI subsystem initialized > [ 2.323661] SCSI Media Changer driver v0.25 > [ 2.364323] RPC: Registered named UNIX socket transport module. > [ 2.364341] RPC: Registered udp transport module. > [ 2.364346] RPC: Registered tcp transport module. > [ 2.364352] RPC: Registered tcp NFSv4.1 backchannel transport module. > [ 2.376933] Fusion MPT base driver 3.04.20 > [ 2.376950] Copyright (c) 1999-2008 LSI Corporation > [ 2.390208] Fusion MPT SPI Host driver 3.04.20 > [ 2.396782] FS-Cache: Loaded > [ 2.409835] FS-Cache: Netfs ''nfs'' registered for caching > [ 2.424190] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). > [ 2.453341] st: Version 20101219, fixed bufsize 32768, s/g segs 256 > [ 2.467341] device-mapper: uevent: version 1.0.3 > [ 2.467536] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com > [ 2.683099] kjournald starting. Commit interval 5 seconds > [ 2.683129] EXT3-fs (xvda1): mounted filesystem with ordered data mode > [ 5.344134] udev[221]: starting version 164 > [ 5.866353] pcifront pci-0: Installing PCI frontend > [ 5.866651] pcifront pci-0: Creating PCI Frontend Bus 0000:09 > [ 5.867025] pci 0000:09:08.0: [1000:0030] type 0 class 0x000100 > [ 5.867283] pci 0000:09:08.0: reg 10: [io 0x5000-0x50ff] > [ 5.867449] pci 0000:09:08.0: reg 14: [mem 0xf9e00000-0xf9e1ffff 64bit] > [ 5.867618] pci 0000:09:08.0: reg 1c: [mem 0xf9e20000-0xf9e3ffff 64bit] > [ 5.868598] pci 0000:09:08.0: supports D1 D2 > [ 5.871583] pcifront pci-0: claiming resource 0000:09:08.0/0 > [ 5.871595] pcifront pci-0: claiming resource 0000:09:08.0/1 > [ 5.871603] pci 0000:09:08.0: address space collision: [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > [ 5.871616] pcifront pci-0: Could not claim resource 0000:09:08.0/1! Device offline. Try using e820_host=1 in the guest config. > [ 5.871626] pcifront pci-0: claiming resource 0000:09:08.0/3 > [ 5.871634] pci 0000:09:08.0: address space collision: [mem 0xf9e20000-0xf9e3ffff 64bit] conflicts with System RAM [mem 0x00100000-0x4007fffff] > [ 5.871646] pcifront pci-0: Could not claim resource 0000:09:08.0/3! Device offline. Try using e820_host=1 in the guest config. > [ 5.872618] mptspi 0000:09:08.0: device not available (can''t reserve [mem 0xf9e00000-0xf9e1ffff 64bit]) > [ 5.872630] mptbase: ioc0: ERROR - pci_enable_device_mem() failed > [ 6.159193] powernow-k8: Found 1 Dual-Core AMD Opteron(tm) Processor 2216 (4 cpu cores) (version 2.20.00) > [ 6.159226] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects found. > [ 6.159228] [Firmware Bug]: powernow-k8: Try again with latest BIOS. > [ 6.850939] Adding 2097148k swap on /dev/xvda2. Priority:-1 extents:1 across:2097148k SS > [ 6.862659] Adding 34598908k swap on /dev/xvdb1. Priority:-2 extents:1 across:34598908k SS > [ 7.508893] EXT3-fs (xvda1): using internal journal > [ 10.411287] kjournald starting. Commit interval 5 seconds > [ 10.411746] EXT3-fs (xvda3): using internal journal > [ 10.411766] EXT3-fs (xvda3): mounted filesystem with ordered data mode > [ 10.969165] kjournald starting. Commit interval 5 seconds > [ 10.969552] EXT3-fs (xvdd1): using internal journal > [ 10.969566] EXT3-fs (xvdd1): mounted filesystem with ordered data mode > [ 11.048772] kjournald starting. Commit interval 5 seconds > [ 11.049945] EXT3-fs (xvde1): using internal journal > [ 11.049960] EXT3-fs (xvde1): mounted filesystem with ordered data mode > [ 22.208282] svc: failed to register lockdv1 RPC service (errno 97). > [ 22.208411] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory > [ 22.246487] NFSD: starting 90-second grace period > [ 22.880072] eth0: no IPv6 routers present > [ 51.248126] sshd (1438): /proc/1438/oom_adj is deprecated, please use /proc/1438/oom_score_adj instead.
Andrea Brugiolo
2013-Aug-28 16:44 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Wed, Aug 28, 2013 at 11:45:01AM -0400, Konrad Rzeszutek Wilk wrote:> On Tue, Aug 27, 2013 at 11:03:02PM +0200, Andrea Brugiolo wrote: > > On Fri, Aug 23, 2013 at 02:54:30PM -0400, Konrad Rzeszutek Wilk wrote: > > > > > Awaiting your response with the usage of ''xl''. > > > > > > > > Now I am using `xl'' and the > > > > > > > > e820_host = 1 > > > > > > > > option in the domU configuration but I get the same result as before > > > > and no device attached: > > > > > > And this is with Xen 4.2 I presume? > > > > No, Xen 4.1 (Debian 4.1.4-3+deb7u1 Xen hypervisor and libs) > > OK, Xen 4.1 did not have the code to handle the e820_host so hence the > reason for this not working :-(. > > You will need to upgrade to Xen 4.2 at least. I don''t know how that > is done under Debian.Argh... the 4.2 hypervisor is still in the Debian unstable release so I am not sure about how I could put that into production without relevant breaks. As a last resort, would you suggest tecniques other than pciback to delegate a device to a guest in Xen 4.1? Thank you very much for your attention and the time you dedicated do this issue Andrea
Konrad Rzeszutek Wilk
2013-Aug-30 16:08 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Wed, Aug 28, 2013 at 06:44:50PM +0200, Andrea Brugiolo wrote:> On Wed, Aug 28, 2013 at 11:45:01AM -0400, Konrad Rzeszutek Wilk wrote: > > On Tue, Aug 27, 2013 at 11:03:02PM +0200, Andrea Brugiolo wrote: > > > On Fri, Aug 23, 2013 at 02:54:30PM -0400, Konrad Rzeszutek Wilk wrote: > > > > > > Awaiting your response with the usage of ''xl''. > > > > > > > > > > Now I am using `xl'' and the > > > > > > > > > > e820_host = 1 > > > > > > > > > > option in the domU configuration but I get the same result as before > > > > > and no device attached: > > > > > > > > And this is with Xen 4.2 I presume? > > > > > > No, Xen 4.1 (Debian 4.1.4-3+deb7u1 Xen hypervisor and libs) > > > > OK, Xen 4.1 did not have the code to handle the e820_host so hence the > > reason for this not working :-(. > > > > You will need to upgrade to Xen 4.2 at least. I don''t know how that > > is done under Debian. > > Argh... the 4.2 hypervisor is still in the Debian unstable release so > I am not sure about how I could put that into production without > relevant breaks. > > As a last resort, would you suggest tecniques other than pciback to > delegate a device to a guest in Xen 4.1?The other option is to limit the amount of memory the guest will use from 16GB to say 2GB. That would work as well.> > Thank you very much for your attention and the time you dedicated do > this issueSure thing. Sadly the patch did not make Xen 4.1 hence the need to use a more modern version of Xen stack.> > Andrea
Andrea Brugiolo
2013-Sep-04 17:22 UTC
Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
On Fri, Aug 30, 2013 at 12:08:05PM -0400, Konrad Rzeszutek Wilk wrote:> On Wed, Aug 28, 2013 at 06:44:50PM +0200, Andrea Brugiolo wrote: > > On Wed, Aug 28, 2013 at 11:45:01AM -0400, Konrad Rzeszutek Wilk wrote: > > > On Tue, Aug 27, 2013 at 11:03:02PM +0200, Andrea Brugiolo wrote: > > > > On Fri, Aug 23, 2013 at 02:54:30PM -0400, Konrad Rzeszutek Wilk wrote: > > > > > > > Awaiting your response with the usage of ''xl''. > > > > > > > > > > > > Now I am using `xl'' and the > > > > > > > > > > > > e820_host = 1 > > > > > > > > > > > > option in the domU configuration but I get the same result as before > > > > > > and no device attached: > > > > > > > > > > And this is with Xen 4.2 I presume? > > > > > > > > No, Xen 4.1 (Debian 4.1.4-3+deb7u1 Xen hypervisor and libs) > > > > > > OK, Xen 4.1 did not have the code to handle the e820_host so hence the > > > reason for this not working :-(. > > > > > > You will need to upgrade to Xen 4.2 at least. I don''t know how that > > > is done under Debian. > > > > Argh... the 4.2 hypervisor is still in the Debian unstable release so > > I am not sure about how I could put that into production without > > relevant breaks. > > > > As a last resort, would you suggest tecniques other than pciback to > > delegate a device to a guest in Xen 4.1? > > The other option is to limit the amount of memory the guest will use > from 16GB to say 2GB. That would work as well.I confirm, I have limited the guest memory to 2 GB and now I can attach the device as I used to do.> Sure thing. Sadly the patch did not make Xen 4.1 hence the need to use > a more modern version of Xen stack.I am looking forward to have Xen 4.2 or higher in Debian stable.. :) Thank you again Andrea