Re: iommu must be enabled for PVH hardware domain
Roger Pau Monné wrote on 05/12/15 18:50: Hello, El 12/05/15 a les 17.20, Ruslan Makhmatkhanov ha escrit: Hello, we have machine with VT-d and EPT-capable CPU: Intel(R) Xeon(R) CPU E5504 [1] The system is FreeBSD 11.0-CURRENT r282694 installed from ftp.freebsd.org iso. But dom0 fails to boot at this hardware with "iommu must be enabled for PVH hardware domain" [2]. VT-d support is indeed not detected at kernel level. Here is dmesg with VT-d enabled in BIOS [3] and dmesg with VT-d disabled in BIOS [4]. It's look like there is no difference on both outputs. Here is the proofpic of that the system is VT-d capable and the support is enabled in BIOS [5]. Here is acpidump -t output [6] My bet right now is be that Xen detects that your IOMMU contains erratas and disables it. Can you add "iommu=debug,force" to your xen_cmdline and try again? Also, can you paste the contents of your /boot/loader.conf? Roger. You are right: [VT-D] Disabling IOMMU due to Intel 5500/5520/X58 Chipset errata #47, #53 and after that: -- Panic on CPU 0: Couldn't enable IOMMU and iommu=required/force -- Reboot in five seconds. But what this means practically? Some chipset bugs preventing us to use this feature. Can this circumvented somehow? Thanks. -- Regards, Ruslan T.O.S. Of Reality ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: iommu must be enabled for PVH hardware domain
Hello, El 13/05/15 a les 10.04, Ruslan Makhmatkhanov ha escrit: > Roger Pau Monné wrote on 05/12/15 18:50: >> Hello, >> >> El 12/05/15 a les 17.20, Ruslan Makhmatkhanov ha escrit: >>> Hello, >>> >>> we have machine with VT-d and EPT-capable CPU: >>> Intel(R) Xeon(R) CPU E5504 [1] >>> >>> The system is FreeBSD 11.0-CURRENT r282694 installed from >>> ftp.freebsd.org iso. >>> >>> But dom0 fails to boot at this hardware with "iommu must be enabled for >>> PVH hardware domain" [2]. VT-d support is indeed not detected at kernel >>> level. Here is dmesg with VT-d enabled in BIOS [3] and dmesg with VT-d >>> disabled in BIOS [4]. It's look like there is no difference on both >>> outputs. Here is the proofpic of that the system is VT-d capable and the >>> support is enabled in BIOS [5]. Here is acpidump -t output [6] >> >> My bet right now is be that Xen detects that your IOMMU contains erratas >> and disables it. Can you add "iommu=debug,force" to your xen_cmdline and >> try again? >> >> Also, can you paste the contents of your /boot/loader.conf? >> >> Roger. > > You are right: > > [VT-D] Disabling IOMMU due to Intel 5500/5520/X58 Chipset errata #47, #53 > > and after that: > > -- > Panic on CPU 0: > Couldn't enable IOMMU and iommu=required/force > -- > > Reboot in five seconds. > > But what this means practically? Some chipset bugs preventing us to use > this feature. Can this circumvented somehow? Thanks. AFAIK iommu=force should force the usage of the IOMMU even if erratas are detected. You can also try with iommu=force,no-intremap. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Xen dom0 "interrupt storm detected on "irq16:"; throttling interrupt source"
Hi, with Xen from git and a recent -CURRENT, I get "interrupt storm detected on "irq16:"; throttling interrupt source" messages on the dom0 console about once a second. irq16 is used for ehci: # vmstat -i | grep irq16 irq16: ehci0 1229805 6559 Any ideas? Thanks, Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: iommu must be enabled for PVH hardware domain
Roger Pau Monné wrote on 05/13/15 11:14: Hello, El 13/05/15 a les 10.04, Ruslan Makhmatkhanov ha escrit: Roger Pau Monné wrote on 05/12/15 18:50: Hello, El 12/05/15 a les 17.20, Ruslan Makhmatkhanov ha escrit: Hello, we have machine with VT-d and EPT-capable CPU: Intel(R) Xeon(R) CPU E5504 [1] The system is FreeBSD 11.0-CURRENT r282694 installed from ftp.freebsd.org iso. But dom0 fails to boot at this hardware with "iommu must be enabled for PVH hardware domain" [2]. VT-d support is indeed not detected at kernel level. Here is dmesg with VT-d enabled in BIOS [3] and dmesg with VT-d disabled in BIOS [4]. It's look like there is no difference on both outputs. Here is the proofpic of that the system is VT-d capable and the support is enabled in BIOS [5]. Here is acpidump -t output [6] My bet right now is be that Xen detects that your IOMMU contains erratas and disables it. Can you add "iommu=debug,force" to your xen_cmdline and try again? Also, can you paste the contents of your /boot/loader.conf? Roger. You are right: [VT-D] Disabling IOMMU due to Intel 5500/5520/X58 Chipset errata #47, #53 and after that: -- Panic on CPU 0: Couldn't enable IOMMU and iommu=required/force -- Reboot in five seconds. But what this means practically? Some chipset bugs preventing us to use this feature. Can this circumvented somehow? Thanks. AFAIK iommu=force should force the usage of the IOMMU even if erratas are detected. You can also try with iommu=force,no-intremap. Roger. Yes, the system is now booted successfully! But `xl list` doesn't work with: root@:~ # xl list libxl: error: libxl.c:669:libxl_list_domain: getting domain info list: Cannot allocate memory libxl_list_domain failed. I googled for this error, and make ktrace/kdump on `xl list`. Here is the output: https://dpaste.de/mAyX/raw It referencing many shared libraries, that is not available on this system. Dunno if this is cause of problem. And here is the `xl info` and `xl dmesg`: https://dpaste.de/H1dV/raw Max wired pages is unlimited: root@:~ # sysctl vm.max_wired vm.max_wired: -1 Also tried to set: vm.max_wired=1048576, but error is the same. Shell memory values are unlimited too: root@:~ # ulimit -a cpu time (seconds, -t) unlimited file size (512-blocks, -f) unlimited data seg size (kbytes, -d) 33554432 stack size (kbytes, -s) 524288 core file size (512-blocks, -c) unlimited max memory size (kbytes, -m) unlimited locked memory (kbytes, -l) 64 max user processes (-u) 6656 open files (-n) 57987 virtual mem size(kbytes, -v) unlimited swap limit (kbytes, -w) unlimited sbsize (bytes, -b) unlimited pseudo-terminals(-p) unlimited kqueues (-k) unlimited The same error when we trying to create new guest domain: http://dpaste.com/1PD63M9 Domain configuration is taken here: http://wiki.xen.org/wiki/FreeBSD_Dom0 Can anything be done to solve this? Thank you. -- Regards, Ruslan T.O.S. Of Reality ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: iommu must be enabled for PVH hardware domain
Hello, El 13/05/15 a les 10.46, Ruslan Makhmatkhanov ha escrit: > Yes, the system is now booted successfully! But `xl list` doesn't work > with: > > root@:~ # xl list > libxl: error: libxl.c:669:libxl_list_domain: getting domain info list: > Cannot allocate memory > libxl_list_domain failed. [...] > Shell memory values are unlimited too: > > root@:~ # ulimit -a > cpu time (seconds, -t) unlimited > file size (512-blocks, -f) unlimited > data seg size (kbytes, -d) 33554432 > stack size (kbytes, -s) 524288 > core file size (512-blocks, -c) unlimited > max memory size (kbytes, -m) unlimited > locked memory (kbytes, -l) 64 Shell memory is not unlimited, as the output above shows. `ulimit -l unlimited` should fix that. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen dom0 "interrupt storm detected on "irq16:"; throttling interrupt source"
Hello, El 13/05/15 a les 10.20, Eggert, Lars ha escrit: > Hi, > > with Xen from git and a recent -CURRENT, I get "interrupt storm detected on > "irq16:"; throttling interrupt source" messages on the dom0 console about > once a second. irq16 is used for ehci: > > # vmstat -i | grep irq16 > irq16: ehci0 1229805 6559 > > Any ideas? Can you post the full output of vmstat -i and the log of Xen and FreeBSD booting (with boot_verbose=YES)? If you don't have a serial console setup you can get the Xen boot log using xl dmesg. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [solved] iommu must be enabled for PVH hardware domain
Roger Pau Monné wrote on 05/13/15 11:51:
Hello,
El 13/05/15 a les 10.46, Ruslan Makhmatkhanov ha escrit:
Yes, the system is now booted successfully! But `xl list` doesn't work
with:
root@:~ # xl list
libxl: error: libxl.c:669:libxl_list_domain: getting domain info list:
Cannot allocate memory
libxl_list_domain failed.
[...]
Shell memory values are unlimited too:
root@:~ # ulimit -a
cpu time (seconds, -t) unlimited
file size (512-blocks, -f) unlimited
data seg size (kbytes, -d) 33554432
stack size (kbytes, -s) 524288
core file size (512-blocks, -c) unlimited
max memory size (kbytes, -m) unlimited
locked memory (kbytes, -l) 64
Shell memory is not unlimited, as the output above shows. `ulimit -l
unlimited` should fix that.
Roger.
My bad. `ulimit -l unlimited` doesn't worked for me, but changing the
limit via /etc/login.conf did. Now it works flawlessly. Thank you!
Is there any resource where these cases covered ("Cannot allocate
memory" and disabling IOMMU because of erratas)? Just want to know
bloody details.
And one more question, am I right that PV-guests are no more supported
in FreeBSD? We tried to run Debian guest in PV mode like described here:
http://wiki.xen.org/wiki/FreeBSD_Dom0#Creating_your_first_PV_guest
but guest's kernel panicking like that:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
Full log: http://dpaste.com/2GZTJMH
Or it's some bad zfs setup on dom0 system?
This is FreeBSD HVM attempt:
libxl: error: libxl_dm.c:1482:device_model_spawn_outcome: domain 5
device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1319:domcreate_devmodel_started: device
model did not start: -3
libxl: error: libxl_dm.c:1586:kill_device_model: Device Model already exited
Full log: http://dpaste.com/0499WH8
--
Regards,
Ruslan
T.O.S. Of Reality
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [solved] iommu must be enabled for PVH hardware domain
El 13/05/15 a les 12.34, Ruslan Makhmatkhanov ha escrit:
> My bad. `ulimit -l unlimited` doesn't worked for me, but changing the
> limit via /etc/login.conf did. Now it works flawlessly. Thank you!
> Is there any resource where these cases covered ("Cannot allocate
> memory" and disabling IOMMU because of erratas)? Just want to know
> bloody details.
I don't thinks there's any generic resource about this issues, your best
bet is to google for them, this is for example the patch related to that
hw errata:
http://lists.xen.org/archives/html/xen-devel/2013-01/msg01016.html
It contains a link to the Intel SDM that has more info about the erratas.
> And one more question, am I right that PV-guests are no more supported
> in FreeBSD? We tried to run Debian guest in PV mode like described here:
> http://wiki.xen.org/wiki/FreeBSD_Dom0#Creating_your_first_PV_guest
>
> but guest's kernel panicking like that:
>
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
>
> Full log: http://dpaste.com/2GZTJMH
> Or it's some bad zfs setup on dom0 system?
Can you paste the DomU configuration file (debian.cfg)?
> This is FreeBSD HVM attempt:
> libxl: error: libxl_dm.c:1482:device_model_spawn_outcome: domain 5
> device model: spawn failed (rc=-3)
> libxl: error: libxl_create.c:1319:domcreate_devmodel_started: device
> model did not start: -3
> libxl: error: libxl_dm.c:1586:kill_device_model: Device Model already
> exited
Can you run the same command with xl -vvv instead (it will print more
verbose debug info)? Also, can you paste the contents of
/var/log/xen/qemu-dm-freebsd.log?
Roger.
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [solved] iommu must be enabled for PVH hardware domain
Roger Pau Monné wrote on 05/13/15 13:44: I don't thinks there's any generic resource about this issues, your best bet is to google for them, this is for example the patch related to that hw errata: http://lists.xen.org/archives/html/xen-devel/2013-01/msg01016.html It contains a link to the Intel SDM that has more info about the erratas. Thanks! Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Full log: http://dpaste.com/2GZTJMH Or it's some bad zfs setup on dom0 system? Can you paste the DomU configuration file (debian.cfg)? Here it is: https://dpaste.de/wneF/raw This is FreeBSD HVM attempt: Can you run the same command with xl -vvv instead (it will print more http://dpaste.com/2AGRN13 verbose debug info)? Also, can you paste the contents of /var/log/xen/qemu-dm-freebsd.log? Roger. This log-file contains only one line: "VNC support is disabled" -- Regards, Ruslan T.O.S. Of Reality ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [solved] iommu must be enabled for PVH hardware domain
El 13/05/15 a les 13.12, Ruslan Makhmatkhanov ha escrit: >>> Kernel panic - not syncing: VFS: Unable to mount root fs on >>> unknown-block(0,0) >>> >>> Full log: http://dpaste.com/2GZTJMH >>> Or it's some bad zfs setup on dom0 system? >> >> Can you paste the DomU configuration file (debian.cfg)? > > Here it is: https://dpaste.de/wneF/raw This is weird, I don't see anything obviously wrong. Could you try to increase the DomU memory to 512Mb and boot again? >>> This is FreeBSD HVM attempt: >> >> Can you run the same command with xl -vvv instead (it will print more > > http://dpaste.com/2AGRN13 > >> verbose debug info)? Also, can you paste the contents of >> /var/log/xen/qemu-dm-freebsd.log? >> >> Roger. > > This log-file contains only one line: > "VNC support is disabled" I think this is fixed in the last version of the xen-tools package, can you make sure you are using xen-tools-4.5.0_4? Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [solved] iommu must be enabled for PVH hardware domain
Roger Pau Monné wrote on 05/13/15 14:21: El 13/05/15 a les 13.12, Ruslan Makhmatkhanov ha escrit: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Full log: http://dpaste.com/2GZTJMH Or it's some bad zfs setup on dom0 system? Can you paste the DomU configuration file (debian.cfg)? Here it is: https://dpaste.de/wneF/raw This is weird, I don't see anything obviously wrong. Could you try to increase the DomU memory to 512Mb and boot again? Yes, it is helped. So 512Mb is the minimal RAM quantity? This is FreeBSD HVM attempt: Can you run the same command with xl -vvv instead (it will print more http://dpaste.com/2AGRN13 verbose debug info)? Also, can you paste the contents of /var/log/xen/qemu-dm-freebsd.log? Roger. This log-file contains only one line: "VNC support is disabled" I think this is fixed in the last version of the xen-tools package, can you make sure you are using xen-tools-4.5.0_4? Roger. You are right. It's xen-tools-4.5.0_3 installed from packages. Will build own package later and response back. Thank you much for all your help! -- Regards, Ruslan T.O.S. Of Reality ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [solved] iommu must be enabled for PVH hardware domain
El 13/05/15 a les 13.40, Ruslan Makhmatkhanov ha escrit: > Roger Pau Monné wrote on 05/13/15 14:21: >> El 13/05/15 a les 13.12, Ruslan Makhmatkhanov ha escrit: > Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(0,0) > > Full log: http://dpaste.com/2GZTJMH > Or it's some bad zfs setup on dom0 system? Can you paste the DomU configuration file (debian.cfg)? >>> >>> Here it is: https://dpaste.de/wneF/raw >> >> This is weird, I don't see anything obviously wrong. Could you try to >> increase the DomU memory to 512Mb and boot again? > > Yes, it is helped. So 512Mb is the minimal RAM quantity? No idea, you can try with 256 also, maybe that's enough? It looks like 128 isn't, but that's a debian issue unrelated to FreeBSD. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen dom0 "interrupt storm detected on "irq16:"; throttling interrupt source"
On 2015-5-13, at 10:54, Roger Pau Monné wrote: > Can you post the full output of vmstat -i and the log of Xen and FreeBSD > booting (with boot_verbose=YES)? If you don't have a serial console > setup you can get the Xen boot log using xl dmesg. Here you go: Xen 4.6-unstabletcp.ko size 0x2f90 at 0xfc6`` (XEN) Xen version 4.6-unstable (el...@netapp.com) (gcc47 (FreeBSD Ports Collection) 4.7.4) debug=y Tue May 12 09:31:08 CEST 2015.el/cc_hd.ko size 0x2c00 at 0xfc3o .--` /y:` +. (XEN) Latest ChangeSet: Fri Apr 10 11:26:18 2015 -0400 git:123c779 `+- (XEN) Bootloader: FreeBSD Loader | y/ -/` -o/ (XEN) Command line: dom0_mem=4096M dom0pvh=1 com1=115200,8n1 console=com1. (XEN) Video information:r prompt | / `-- / (XEN) VGA is text mode 80x25, font 8x16 | `: :` (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds :` (XEN) EDID info not retrieved because no DDC retrieval method detected / (XEN) Disc information: (1 of 2) | .--. (XEN) Found 1 MBR signaturesns... | -- -. (XEN) Found 1 EDD information structures |`:` `:` (XEN) Xen-e820 RAM map:| .-- `--. (XEN) - 0009ac00 (usable) .---.. (XEN) 0009ac00 - 000a (reserved) (XEN) 000e - 0010 (reserved) (XEN) 0010 - 7de19000 (usable) (XEN) 7de19000 - 7dea8000 (reserved) (XEN) 7dea8000 - 7dfb1000 (ACPI data) (XEN) 7dfb1000 - 7e1cb000 (ACPI NVS) (XEN) 7e1cb000 - 7f355000 (reserved) (XEN) 7f355000 - 7f80 (ACPI NVS) (XEN) 8000 - 9000 (reserved) (XEN) fed1c000 - fed4 (reserved) (XEN) ff00 - 0001 (reserved) (XEN) 0001 - 00208000 (usable) (XEN) ACPI: RSDP 000F04A0, 0024 (r2 SUPERM) (XEN) ACPI: XSDT 7DEDD090, 009C (r1 SUPERM SMCI--MB1 AMI 10013) (XEN) ACPI: FACP 7DEE8110, 00F4 (r4 SUPERM SMCI--MB1 AMI 10013) (XEN) ACPI: DSDT 7DEDD1B8, AF53 (r2 SUPERM SMCI--MB0 INTL 20091112) (XEN) ACPI: FACS 7E1C2080, 0040 (XEN) ACPI: APIC 7DEE8208, 0224 (r31 AMI 10013) (XEN) ACPI: FPDT 7DEE8430, 0044 (r11 AMI 10013) (XEN) ACPI: SRAT 7DEE8478, 04B0 (r1 A M I AMI SRAT1 AMI.0) (XEN) ACPI: SLIT 7DEE8928, 0030 (r1 A M I AMI SLIT0 AMI.0) (XEN) ACPI: HPET 7DEE8958, 0038 (r1 SUPERM SMCI--MB1 AMI.5) (XEN) ACPI: PRAD 7DEE8990, 00BE (r2 PRADID PRADTID1 MSFT 400) (XEN) ACPI: SPMI 7DEE8A50, 0040 (r5 A M I OEMSPMI0 AMI.0) (XEN) ACPI: SSDT 7DEE8A90, C7AE8 (r2 INTELCpuPm 4000 INTL 20091112) (XEN) ACPI: EINJ 7DFB0578, 0130 (r1AMI AMI EINJ0 0) (XEN) ACPI: ERST 7DFB06A8, 0230 (r1 AMIER AMI ERST0 0) (XEN) ACPI: HEST 7DFB08D8, 00A8 (r1AMI AMI HEST0 0) (XEN) ACPI: BERT 7DFB0980, 0030 (r1AMI AMI BERT0 0) (XEN) ACPI: DMAR 7DFB09B0, 0168 (r1 A M I OEMDMAR1 INTL1) (XEN) ACPI: MCFG 7DFB0B18, 003C (r1 SUPERM SMCI--MB1 MSFT 97) (XEN) System RAM: 131037MB (134182604kB) (XEN) SRAT: PXM 0 -> APIC 0 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 1 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 2 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 3 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 4 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 5 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 6 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 7 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 8 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 9 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 10 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 11 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 12 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 13 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 14 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 15 -> Node 0 (XEN) SRAT: PXM 1 -> APIC 32 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 33 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 34 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 35 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 36 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 37 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 38 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 39 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 40 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 41 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 42 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 43 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 44 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 45 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 46 -> Node 1 (XEN) SRAT: PXM 1 -> APIC 47 -> Node 1 (XEN) SRAT: Node 0 PXM 0 0-8000 (XEN) SRAT: Node 0 PXM 0 1-108000 (XEN) SRAT: Node 1 PXM 1 108000-208000 (XEN) NUMA: Allocated memnodemap from 207f3d2000 - 207f3d3000 (XEN) NUMA: Using 19 for the hash shift. (XEN) Domain heap initialised DMA width 32 bits (XEN) f
Re: Xen dom0 "interrupt storm detected on "irq16:"; throttling interrupt source"
Also, building the xen tools currently seems to fail with: gmake[3]: Entering directory '/usr/home/elars/xen/tools/qemu-xen-dir-remote' GEN config-host.h GEN trace/generated-tracers.h GEN trace/generated-tcg-tracers.h GEN trace/generated-helpers-wrappers.h GEN trace/generated-helpers.h CCqapi-types.o CCqapi-visit.o CCqapi-event.o CCtrace/generated-events.o ARlibqemuutil.a ARlibqemustub.a LINK qemu-nbd CCqemu-img.o LINK qemu-img LINK qemu-io CCmigration-rdma.o migration-rdma.c: In function 'qemu_rdma_broken_ipv6_kernel': migration-rdma.c:795:26: warning: unused variable 'port_attr' [-Wunused-variable] migration-rdma.c: In function 'qemu_rdma_resolve_host': migration-rdma.c:912:5: warning: implicit declaration of function 'rdma_getaddrinfo' [-Wimplicit-function-declaration] migration-rdma.c:912:5: warning: nested extern declaration of 'rdma_getaddrinfo' [-Wnested-externs] migration-rdma.c:918:35: error: dereferencing pointer to incomplete type migration-rdma.c:919:20: error: dereferencing pointer to incomplete type migration-rdma.c:920:39: error: dereferencing pointer to incomplete type migration-rdma.c:923:53: error: dereferencing pointer to incomplete type migration-rdma.c:926:18: error: dereferencing pointer to incomplete type migration-rdma.c: In function 'qemu_rdma_dest_init': migration-rdma.c:2456:39: error: dereferencing pointer to incomplete type migration-rdma.c:2457:24: error: dereferencing pointer to incomplete type migration-rdma.c:2458:43: error: dereferencing pointer to incomplete type migration-rdma.c:2460:46: error: dereferencing pointer to incomplete type migration-rdma.c:2462:22: error: dereferencing pointer to incomplete type /usr/home/elars/xen/tools/qemu-xen-dir/rules.mak:57: recipe for target 'migration-rdma.o' failed gmake[3]: *** [migration-rdma.o] Error 1 gmake[3]: Leaving directory '/usr/home/elars/xen/tools/qemu-xen-dir-remote' Makefile:201: recipe for target 'subdir-all-qemu-xen-dir' failed gmake[2]: *** [subdir-all-qemu-xen-dir] Error 2 gmake[2]: Leaving directory '/usr/home/elars/xen/tools' /usr/home/elars/xen/tools/../tools/Rules.mk:111: recipe for target 'subdirs-install' failed gmake[1]: *** [subdirs-install] Error 2 gmake[1]: Leaving directory '/usr/home/elars/xen/tools' Makefile:69: recipe for target 'install-tools' failed gmake: *** [install-tools] Error 2 Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Xen dom0 "interrupt storm detected on "irq16:"; throttling interrupt source"
Hello, El 13/05/15 a les 16.40, Eggert, Lars ha escrit: > Also, building the xen tools currently seems to fail with: > > gmake[3]: Entering directory '/usr/home/elars/xen/tools/qemu-xen-dir-remote' > GEN config-host.h > GEN trace/generated-tracers.h > GEN trace/generated-tcg-tracers.h > GEN trace/generated-helpers-wrappers.h > GEN trace/generated-helpers.h > CCqapi-types.o > CCqapi-visit.o > CCqapi-event.o > CCtrace/generated-events.o > ARlibqemuutil.a > ARlibqemustub.a > LINK qemu-nbd > CCqemu-img.o > LINK qemu-img > LINK qemu-io > CCmigration-rdma.o > migration-rdma.c: In function 'qemu_rdma_broken_ipv6_kernel': > migration-rdma.c:795:26: warning: unused variable 'port_attr' > [-Wunused-variable] > migration-rdma.c: In function 'qemu_rdma_resolve_host': > migration-rdma.c:912:5: warning: implicit declaration of function > 'rdma_getaddrinfo' [-Wimplicit-function-declaration] > migration-rdma.c:912:5: warning: nested extern declaration of > 'rdma_getaddrinfo' [-Wnested-externs] > migration-rdma.c:918:35: error: dereferencing pointer to incomplete type > migration-rdma.c:919:20: error: dereferencing pointer to incomplete type > migration-rdma.c:920:39: error: dereferencing pointer to incomplete type > migration-rdma.c:923:53: error: dereferencing pointer to incomplete type > migration-rdma.c:926:18: error: dereferencing pointer to incomplete type > migration-rdma.c: In function 'qemu_rdma_dest_init': > migration-rdma.c:2456:39: error: dereferencing pointer to incomplete type > migration-rdma.c:2457:24: error: dereferencing pointer to incomplete type > migration-rdma.c:2458:43: error: dereferencing pointer to incomplete type > migration-rdma.c:2460:46: error: dereferencing pointer to incomplete type > migration-rdma.c:2462:22: error: dereferencing pointer to incomplete type > /usr/home/elars/xen/tools/qemu-xen-dir/rules.mak:57: recipe for target > 'migration-rdma.o' failed > gmake[3]: *** [migration-rdma.o] Error 1 > gmake[3]: Leaving directory '/usr/home/elars/xen/tools/qemu-xen-dir-remote' > Makefile:201: recipe for target 'subdir-all-qemu-xen-dir' failed > gmake[2]: *** [subdir-all-qemu-xen-dir] Error 2 > gmake[2]: Leaving directory '/usr/home/elars/xen/tools' > /usr/home/elars/xen/tools/../tools/Rules.mk:111: recipe for target > 'subdirs-install' failed > gmake[1]: *** [subdirs-install] Error 2 > gmake[1]: Leaving directory '/usr/home/elars/xen/tools' > Makefile:69: recipe for target 'install-tools' failed > gmake: *** [install-tools] Error 2 I guess migration-rdma gets compiled because Qemu detects that you have some library and assumes that you want it enabled. Did you install something new between your previous build of Xen and this one? Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen dom0 "interrupt storm detected on "irq16:"; throttling interrupt source"
El 13/05/15 a les 15.48, Eggert, Lars ha escrit:
> isci0: port
> 0x6000-0x60ff mem 0xde07c000-0xde07,0xddc0-0xddff irq 16 at
> device 0.0 on pci10
> isci0: attempting to allocate 2 MSI-X vectors (2 supported)
> isci: 1:89 ISCI bus_alloc_resource failed
This device is sharing the same IRQ#16 with ehci0, and I have a feeling
it's not properly setting up it's interrupt sources. First, FreeBSD
Dom0 still doesn't support MSI-X (only MSI), but isci doesn't check the
errors returned by pci_alloc_msix. I have a patch for FreeBSD which
might solve it, however I don't have any similar box I can use to test
it, would you mind giving it a spin?
Thanks, Roger.
---
diff --git a/sys/x86/xen/xen_msi.c b/sys/x86/xen/xen_msi.c
index 0f678b1..181b956 100644
--- a/sys/x86/xen/xen_msi.c
+++ b/sys/x86/xen/xen_msi.c
@@ -114,6 +114,7 @@ int
xen_msix_alloc(device_t dev, int *irq)
{
+ *irq = -1;
return (ENXIO);
}
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen dom0 "interrupt storm detected on "irq16:"; throttling interrupt source"
On 2015-5-13, at 16:46, Roger Pau Monné wrote: > I guess migration-rdma gets compiled because Qemu detects that you have > some library and assumes that you want it enabled. Did you install > something new between your previous build of Xen and this one? Yes, this box has world built with OFED. I'll try on a more standard world build Friday. (I hadn't previously tried to build tools; was using the pkg but that caused errors, probably due to version incompatibility.) Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Xen dom0 "interrupt storm detected on "irq16:"; throttling interrupt source"
I'll test Friday, thanks.
On 2015-5-13, at 16:52, Roger Pau Monné wrote:
>
> El 13/05/15 a les 15.48, Eggert, Lars ha escrit:
>> isci0: port
>> 0x6000-0x60ff mem 0xde07c000-0xde07,0xddc0-0xddff irq 16 at
>> device 0.0 on pci10
>> isci0: attempting to allocate 2 MSI-X vectors (2 supported)
>> isci: 1:89 ISCI bus_alloc_resource failed
>
> This device is sharing the same IRQ#16 with ehci0, and I have a feeling
> it's not properly setting up it's interrupt sources. First, FreeBSD
> Dom0 still doesn't support MSI-X (only MSI), but isci doesn't check the
> errors returned by pci_alloc_msix. I have a patch for FreeBSD which
> might solve it, however I don't have any similar box I can use to test
> it, would you mind giving it a spin?
>
> Thanks, Roger.
>
> ---
> diff --git a/sys/x86/xen/xen_msi.c b/sys/x86/xen/xen_msi.c
> index 0f678b1..181b956 100644
> --- a/sys/x86/xen/xen_msi.c
> +++ b/sys/x86/xen/xen_msi.c
> @@ -114,6 +114,7 @@ int
> xen_msix_alloc(device_t dev, int *irq)
> {
>
> + *irq = -1;
> return (ENXIO);
> }
>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Xen dom0 "interrupt storm detected on "irq16:"; throttling interrupt source"
El 13/05/15 a les 18.00, Eggert, Lars ha escrit: > On 2015-5-13, at 16:46, Roger Pau Monné wrote: >> I guess migration-rdma gets compiled because Qemu detects that you have >> some library and assumes that you want it enabled. Did you install >> something new between your previous build of Xen and this one? > > Yes, this box has world built with OFED. I'll try on a more standard world > build Friday. > > (I hadn't previously tried to build tools; was using the pkg but that caused > errors, probably due to version incompatibility.) Yes, Xen kernel and tools need to be build with the same exact version. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
