similar to: c7 xen-4.6 crash.

?I wrote about this a couple months back.? George asked me to submit to the Xen developers list, but I never had the time due to work demands on getting the new server set up.? In my case, I had to use a different server.? The new motherboard/CPU had no issues with the second CPU.? If you turn off and unplug the second CPU, it will work. Check the archives for my e-mail address and see

?Not sure if this actually made it to the list the first time.? Here is the SERIAL output (bottom of message after your questions).? Googling the error indicates it's something people ran into a few years back but was supposedly fixed.? Any ideas? I can verify that if I REMOVE the second CPU, it boots into Xen kernel no problem.? The CPU itself doesn't matter, as I can swap either

This issue I am encountering seems to only happen on multi-socket machines. It also does not help that the only multi-socket box I have is an Romley-EP (so two socket SandyBridge CPUs). The other SandyBridge boxes I''ve (one socket) are not showing this. Granted they are also a different model (42). The problem is that when I run ''perf top'' within an SMP PVHVM guest,

while doing "while xm migrate --live domU localhost;do sleep 1;done" I just got the crash shown below. And it can be reproduced. The guest has 2 vcpus and 512mb, it runs pvops 3.7.9 (XEN) ----[ Xen-4.3.26579-20130219.172714 x86_64 debug=n Not tainted ]---- (XEN) CPU: 14 (XEN) RIP: e008:[<ffff82c4c01dd197>] nvmx_vcpu_destroy+0xb7/0x150 (XEN) RFLAGS: 0000000000010282

Hello, I''m attempting to boot Xen 4.0.1 on a SuperMicro H8DGi-F motherboard and having not much luck. I can boot the 2.6.32.26 (or .27) kernels alone, but when I add Xen into the mix, I get consistent boot failure. I''ve tried Xen 4.0.1-release, 4.0.2-rc1-pre and 4.0.2-rc2-pre, all get the same failure. xen/next-2.6.37 works and boots great, but since netback isn''t

Hi Folks: I run into a problem when enabling Xen in next generation server platforms with Xen c/s is 21380. Xen reported "CPU Not responding" when booting up 32 CPUs( 2 sockets with 8 cores/16threads total). The log files belonging showed something wrong with APCI. So I added x2apic=0 in the xen grub line, but the symptom remained. However, Native RHEL5.5 can

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-1 Severity: important The amd64 Dom0 crashes in early boot-stage. For debugging purpose I logged Kernel-Dump with minicom over Serial Console: System is: Dell Poweredge R710 2x Intel XEON X5650 96GB RAM Perc H200 SAS Controller 3x SAS-Drive I see a possible conjunction with Bug #600241 but acpi=off doesn't solve this problem. Regards,

Hi, I''ve not tried pv_ops for a long time but just got a new system (Supermicro X9DRL-iF) so decided to try 3.5.0 with the latest Xen 4.2-unstable, unfortunately the system crashes immediately after loading dom0: traps.c:486:d0 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000] I''ve tried loading both bzImage and vmlinuz (gzip compressed vmlinuz) with the same

Package: xen-hypervisor-4.0-i386 Version: 4.0.1-5.8 Severity: normal Tags: upstream *** Please type your report below this line *** -- System Information: Debian Release: 6.0.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-xen-686 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8,

OK, here's the info Bastian asked for. Transcript: rob at thismachine:~$ dmesg Bootdata ok (command line is root=/dev/sda1 ro ) Linux version 2.6.18-5-amd64 (Debian 2.6.18.dfsg.1-13) (dannf at debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Thu May 31 23:51:05 UTC 2007 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009c800 (usable)

On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote: >Hi Linus, > >Up to now we see the below boot error/warnings when testing v4.14-rc6. > >They hit the RC release mainly due to various imperfections in 0day's >auto bisection. So I manually list them here and CC the likely easy to >debug ones to the corresponding maintainers in the followup emails. >

On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote: >Hi Linus, > >Up to now we see the below boot error/warnings when testing v4.14-rc6. > >They hit the RC release mainly due to various imperfections in 0day's >auto bisection. So I manually list them here and CC the likely easy to >debug ones to the corresponding maintainers in the followup emails. >

Package: xen-hypervisor-3.4-amd64 Version: 3.4.2-2 Severity: critical Justification: breaks the whole system -- Dump: (XEN) Xen version 3.4 (Debian 3.4.2-29 (XEN) Command line: com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=all noreboot (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 1 seconds (XEN) EDID info not

Package: xen-hypervisor-3.4-amd64 Version: 3.4.2-2 Severity: critical Justification: breaks the whole system -- Dump: (XEN) Xen version 3.4 (Debian 3.4.2-29 (XEN) Command line: com1=115200,8n1 console=com1,vga loglvl=all guest_loglvl=all noreboot (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-1 Severity: normal My 32Bit Dom0-crashes with error "Out of SW-IOMMU space for 65536 bytes" after doing moderate I/O on the local storage, which is a software-raid1 over 3 harddrives, connected to the builtin Perc H200 controller with ext3-fs. The error is reproduceable with "dd if=/dev/zero of=bigfile bs=1024 count=1000000"

On Mon 02-03-20 14:49:31, David Hildenbrand wrote: > Will be needed by virtio-mem to identify the node from a pxm. No objection to export the symbol. But it is almost always better to add the export in the patch that actually uses it. The intention is much more clear that way. > Acked-by: "Rafael J. Wysocki" <rafael at kernel.org> > Cc: Len Brown <lenb at

On 12.12.19 22:43, Rafael J. Wysocki wrote: > On Thursday, December 12, 2019 6:11:25 PM CET David Hildenbrand wrote: >> Will be needed by virtio-mem to identify the node from a pxm. >> >> Cc: "Rafael J. Wysocki" <rjw at rjwysocki.net> >> Cc: Len Brown <lenb at kernel.org> >> Cc: linux-acpi at vger.kernel.org >> Signed-off-by: David

Will be needed by virtio-mem to identify the node from a pxm. Acked-by: "Rafael J. Wysocki" <rafael at kernel.org> Cc: Len Brown <lenb at kernel.org> Cc: linux-acpi at vger.kernel.org Signed-off-by: David Hildenbrand <david at redhat.com> --- drivers/acpi/numa/srat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/acpi/numa/srat.c

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9+deb8u1 Severity: important I already posted this on the xen-devel-mailinglist but no one seems to have an answer. I'm posting it here because perhaps someone using Debian and Virtualization might have an idea about this? Since Debian 8 I observe that live migrating a PVM on XEN 4.4.1 (also 4.5.1) and Linux Kernel 4.1.0 (also 3.18) requires

[Moving the conversation on @xen-devel and adding Jan, as that seems more appropriate] [Jan, this came up as I''m implementing some NUMA bits in libvirt but, as you see, the core of Jim''s question is purely about Xen] On lun, 2013-07-01 at 16:47 -0600, Jim Fehlig wrote: > On my non-NUMA test machine I have the cell memory reported as > > <memory