Bug#810964: [Xen-devel] [BUG] EDAC infomation partially missing

>>> On 16.05.17 at 05:47, <ehem+deb...@m5p.com> wrote: > On Mon, May 15, 2017 at 02:02:53AM -0600, Jan Beulich wrote: >> >>> On 14.05.17 at 00:36, <ehem+deb...@m5p.com> wrote: >> > I haven't yet done as much experimentation as Andreas Pf

Bug#810964: [Xen-devel] [BUG] EDAC infomation partially missing

>>> On 14.05.17 at 00:36, wrote: > I haven't yet done as much experimentation as Andreas Pflug has, but I > can confirm I'm also running into this bug with Xen 4.4.1. > > I've only tried Linux kernel 3.16.43, but as Dom0: > > EDAC MC: Ver: 3.0.0 > AMD64 EDAC driver v3.4.0 >

Bug#853710: [Xen-devel] Bug#853710: xen: ftbfs with GCC-7

>>> On 31.01.17 at 13:09, wrote: > Matthias Klose of the Debian Project reports that the Xen package in > Debian stretch, which is based on a snapshot of xen.git#stable-4.8, > does not build with GCC-7. > > Matthias Klose writes ("Bug#853710: xen: ftbfs with GCC-7"):

Bug#810964: [Xen-devel] [BUG] EDAC infomation partially missing

>>> On 22.01.16 at 10:09, wrote: > When booting with Xen 4.4.1: > > AMD64 EDAC driver v3.4.0 > EDAC amd64: DRAM ECC enabled. > EDAC amd64: NB MCE bank disabled, set MSR 0x017b[4] on node 0 to enable. I wonder how valid his message is. We actually write this MSR

Bug#810964: [Xen-devel] [BUG] EDAC infomation partially missing

>>> On 20.01.16 at 16:01, wrote: > Initially reported to debian > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810964), redirected here: > > With AMD Opteron 6xxx processors, half of the memory controllers are > missing from /sys/devices/system/edac/mc > Checked with

Bug#795330: [Xen-devel] [Pkg-xen-devel] Bug#795330: Suggests noapic but doesn't support it

>>> On 04.09.15 at 16:13, wrote: > On Fri, 2015-09-04 at 15:04 +0100, David Vrabel wrote: >> On 04/09/15 14:38, Ian Campbell wrote: >> > On Thu, 2015-08-13 at 00:59 +0200, Guido Günther wrote: >> > > Package: xen-hypervisor-4.5-amd64 >> > > Severity: normal >> > > >> > > Hi, >>

Bug#795330: [Xen-devel] [Pkg-xen-devel] Bug#795330: Suggests noapic but doesn't support it

>>> On 04.09.15 at 16:22, wrote: > Oh, in which case removing (from Xen) the recommendation to try noapic > might be useful. Hmm - so far I didn't the option was not working. I also don't understand the reference to pv-ops kernels in the doc. Sadly it's not clear where

Bug#785187: [PATCH] xen: earlycpio: Pull in latest linux earlycpio.[ch]

-by: Stephan Seitz stse+debianb...@fsing.rootsland.net Signed-off-by: Ian Campbell ian.campb...@citrix.com Not that it really matters for a Linux import refresh, but anyway: Acked-by: Jan Beulich jbeul...@suse.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject

Bug#748052: [Xen-devel] dom0 USB failing with ehci-pci: probe of 0000:00:1d.0 faile

On 22.05.14 at 19:19, m...@estone.ca wrote: Jan Beulich jbeul...@suse.com writes: #Okay, this at least clarifies there is a (relatively big) RMRR. There is #a change to the handling of these among the ones that'll become #4.3.3 - mind giving #http://xenbits.xen.org/gitweb/?p=xen.git

Bug#748052: [Xen-devel] dom0 USB failing with ehci-pci: probe of 0000:00:1d.0 faile

On 23.05.14 at 11:21, ian.campb...@citrix.com wrote: On Fri, 2014-05-23 at 08:52 +0100, Jan Beulich wrote: I am a noob when working with source code. How do I bump my xen up to 4.3.3? I guess this http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source should help you. Since

Bug#748052: [Xen-devel] dom0 USB failing with ehci-pci: probe of 0000:00:1d.0 faile

On 23.05.14 at 12:08, ian.campb...@citrix.com wrote: On Fri, 2014-05-23 at 10:35 +0100, Jan Beulich wrote: On 23.05.14 at 11:21, ian.campb...@citrix.com wrote: On Fri, 2014-05-23 at 08:52 +0100, Jan Beulich wrote: I am a noob when working with source code. How do I bump my xen up

Bug#748052: [Xen-devel] dom0 USB failing with ehci-pci: probe of 0000:00:1d.0 faile

On 20.05.14 at 18:25, m...@estone.ca wrote: I've added iommu=debug to the XEN CMD Line under grub. Attached is the xl dmesg log and system dmesg. Okay, this at least clarifies there is a (relatively big) RMRR. There is a change to the handling of these among the ones that'll become 4.3.3 -

Bug#748052: [Xen-devel] dom0 USB failing with ehci-pci: probe of 0000:00:1d.0 faile

On 16.05.14 at 18:04, m...@estone.ca wrote: Attached are the most recent boot logs. All tests have been on the same system, an Intel S1200BTL motherboard. I did 2 boots, both with kernel 3.13. First one into xen 4.3 and the 2nd into xen 4.1. The keyboard works on xen 4.1, not on 4.3.

Bug#748052: [Xen-devel] dom0 USB failing with ehci-pci: probe of 0000:00:1d.0 failed with error -110

On 16.05.14 at 10:58, i...@hellion.org.uk wrote: So it seems like dom0 is unable to (correctly) bind to some hardware interrupts. I wonder if these messages from Xen's dmesg are relevant. (XEN) Not enabling x2APIC: depends on iommu_supports_eim. (XEN) I/O virtualisation disabled (XEN)

Bug#748052: [Xen-devel] dom0 USB failing with ehci-pci: probe of 0000:00:1d.0 failed with error -110

On 16.05.14 at 16:48, ross.philip...@citrix.com wrote: On 05/16/2014 06:08 AM, Jan Beulich wrote: On 16.05.14 at 10:58, i...@hellion.org.uk wrote: So it seems like dom0 is unable to (correctly) bind to some hardware interrupts. I wonder if these messages from Xen's dmesg are relevant. (XEN

Bug#748052: [Xen-devel] dom0 USB failing with ehci-pci: probe of 0000:00:1d.0 failed with error -110

On 16.05.14 at 17:31, i...@hellion.org.uk wrote: On Fri, 2014-05-16 at 11:08 +0100, Jan Beulich wrote: And finally, looking at the IRQ usage, this [2.087722] xen: registering gsi 22 triggering 0 polarity 1 [2.087731] xen: -- pirq=22 - irq=22 (gsi=22) [2.100161] xen: registering

Bug#748052: [Xen-devel] dom0 USB failing with ehci-pci: probe of 0000:00:1d.0 failed with error -110

On 16.05.14 at 17:31, i...@hellion.org.uk wrote: On Fri, 2014-05-16 at 11:08 +0100, Jan Beulich wrote: And finally, looking at the IRQ usage, this [2.087722] xen: registering gsi 22 triggering 0 polarity 1 [2.087731] xen: -- pirq=22 - irq=22 (gsi=22) [2.100161] xen: registering

Bug#695056: [Xen-devel] [Pkg-xen-devel] Bug#695056: xen - Missing support for XZ compressed bzimage kernels

On 04.12.12 at 11:12, Ian Campbell i...@hellion.org.uk wrote: On Tue, 2012-12-04 at 09:51 +, Jan Beulich wrote: On 04.12.12 at 10:33, Ian Campbell i...@hellion.org.uk wrote: On Mon, 2012-12-03 at 19:47 +0100, Bastian Blank wrote: Package: src:xen Version: 4.1.3-4 Severity: serious

Bug#695056: [Pkg-xen-devel] Bug#695056: xen - Missing support for XZ compressed bzimage kernels

On 04.12.12 at 10:33, Ian Campbell i...@hellion.org.uk wrote: On Mon, 2012-12-03 at 19:47 +0100, Bastian Blank wrote: Package: src:xen Version: 4.1.3-4 Severity: serious The bzimage loader used in both libxc and the hypervisor lacks XZ support. Debian kernels since 3.6 are compressed with

Bug#599161: [Xen-devel] #599161: Xen debug patch for the clock shifts by 50 minutes bug.

On 09.11.12 at 10:05, philippe.simo...@swisscom.com wrote: Since it looks like this got stalled again, attached is a slightly extended version of Keir's debugging patch, allowing to rule out any inconsistencies of the globals between the first and second instances of the two invocations of

Bug#599161: [Xen-devel] #599161: Xen debug patch for the clock shifts by 50 minutes bug.

On 09.11.12 at 10:05, philippe.simo...@swisscom.com wrote: oops, excuse me, here is a description : I have the problem on 4 systems, all with same hardware. the problem occured on each system, 1 time each 2 month in average. since January 2012, I decided to reboot them all monthly, and

Bug#599161: [Xen-devel] #599161: Xen debug patch for the clock shifts by 50 minutes bug.

On 07.11.12 at 18:40, Keir Fraser k...@xen.org wrote: On 07/11/2012 13:22, Ian Campbell i...@hellion.org.uk wrote: (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306 now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5 plt_stamp64=15b800366a5 plt_mask=

Bug#599161: [Xen-devel] #599161: Xen debug patch for the clock shifts by 50 minutes bug.

On 08.11.12 at 11:38, Keir Fraser k...@xen.org wrote: On 08/11/2012 09:39, Jan Beulich jbeul...@suse.com wrote: (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306 now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5 plt_stamp64=15b800366a5 plt_mask= tsc=e3839fd23854

Bug#599161: [Xen-devel] #599161: Xen debug patch for the clock shifts by 50 minutes bug.

On 07.11.12 at 11:10, philippe.simo...@swisscom.com wrote: i compiled a patched hypervisor for Mauro, it is running since many days and the overflow occured, without clock jumps (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306 now=5ece12d16292 old_stamp=35c7c

Bug#676360: [Xen-devel] xen: oops at atomic64_read_cx8+0x4

Andrea Arcangeli aarca...@redhat.com 06/07/12 12:35 PM Oops, sorry I didn't imagine atomic64_read on a pmd would trip. The problem really is that the cmpxchg8b is a write, and hence won't go through without faulting on a write protected page (which all page table pages necessarily are). I

Bug#642154: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000

On 10.10.11 at 18:49, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Sat, Oct 08, 2011 at 10:13:14AM +0400, rush wrote: OK, I tried it again, but Oops didn't gone. .. snip.. echo'Loading Xen 4.0-amd64 ...' multiboot /boot/xen-4.0-amd64.gz placeholder xsave=0

Bug#642154: [Xen-devel] Re: BUG: unable to handle kernel paging request at ffff8803bb6ad000

On 11.10.11 at 10:02, Ian Campbell i...@hellion.org.uk wrote: On Tue, 2011-10-11 at 08:07 +0100, Jan Beulich wrote: On 10.10.11 at 18:49, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Sat, Oct 08, 2011 at 10:13:14AM +0400, rush wrote: OK, I tried it again, but Oops didn't gone

Bug#625438: [Xen-devel] [PATCH] xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables

an entire IO APIC entry using an explicit union to allow gcc to spot the initialisation. Reported as Debian bug #625438, thanks to Matthias Klose. Signed-off-by: Ian Campbell ian.campb...@citrix.com Acked-by: Jan Beulich jbeul...@novell.com diff -r 4b0692880dfa -r 35abcbcdf8bc xen/arch/x86

Bug#544145: [Xen-devel] Crash with paravirt-ops 2.6.31.6 kernel

Ian Campbell ian.campb...@citrix.com 23.11.09 17:44 On Mon, 2009-11-23 at 16:31 +, Jan Beulich wrote: It does not happen on XenSource 2.6.18 kernel I assume that this kernel (perhaps coincidentally) manages to use FLAT_USER_CS32 for compat mode processes. , or the Debian 2.6.26

Bug#544145: [Xen-devel] Crash with paravirt-ops 2.6.31.6 kernel

Jeremy Fitzhardinge jer...@goop.org 25.11.09 22:24 On 11/25/09 02:22, Jan Beulich wrote: Okay, I think I spotted the relevant difference: 2.6.18 and forward ports set VGCF_in_syscall only when returning from 64-bit system calls (through ret_from_sys_call) - 32-bit syscalls (regardless

Bug#544145: [Xen-devel] Crash with paravirt-ops 2.6.31.6 kernel

Ian Campbell ian.campb...@citrix.com 23.11.09 16:25 Perhaps simply not returning guest userspace with sysret (as above) makes most sense, a syscall already takes a trap through the hypervisor on both entry and exit so I'm not sure the difference between sysret and iret is going to be noticeable.