Bug#604096: Bug#601341: Bug#602418: #601341, #602418 and #604096 seem to be duplicates

On 12/22/2010 10:35 AM, Konrad Rzeszutek Wilk wrote: >> Thanks. S since the Debian kernel has has DRM/TTM from 2.6.33 I assume I >> want the NEEDS_IOREMAP (95518271) version. >> >> I'm about to try my backport of devel/ttm.pci-api-v2 which contains: >> drm/ttm: Add ttm_tt_free_page >>

Bug#603632: [Xen-devel] PVops domain 0 crash on NUMA system only Node==1 present (Was: Re: Bug#603632: linux-image-2.6.32-5-xen-amd64: Linux kernel 2.6.32/xen/amd64 booting fine on bare metal, but not

On 12/02/2010 03:47 PM, Vincent Caron wrote: > It just happens that your kernel above (2.6.32-27+numa1) boots fine > under hypervisor _when_ passed 'numa=noacpi'. Yeah ! > > I then tried again with Debian Squeeze's latest 2.6.32-28, which > crashes as -27 under hypervisor (and changelog show no

Bug#603632: [Xen-devel] PVops domain 0 crash on NUMA system only Node==1 present (Was: Re: Bug#603632: linux-image-2.6.32-5-xen-amd64: Linux kernel 2.6.32/xen/amd64 booting fine on bare metal, but not

On 11/23/2010 03:51 AM, Ian Campbell wrote: > I'm not sure but looking at the complete bootlog it looks as if the > system may only have node==1 i.e. no 0 node which could plausibly lead > to this sort of issue: > [0.00] Bootmem setup node 1 -4000 >

Bug#599089: linux-image-2.6.32-5-xen-686: Kernel Panics when using NFS from DomU to Dom0

On 10/05/2010 11:22 AM, Ian Campbell wrote: > On Tue, 2010-10-05 at 09:54 -0700, Jeremy Fitzhardinge wrote: >> On 10/05/2010 02:52 AM, Ian Campbell wrote: >>> On Tue, 2010-10-05 at 10:47 +0100, Ian Campbell wrote: >>>> In addition to the kernel logging of

Bug#599089: linux-image-2.6.32-5-xen-686: Kernel Panics when using NFS from DomU to Dom0

On 10/05/2010 02:52 AM, Ian Campbell wrote: > On Tue, 2010-10-05 at 10:47 +0100, Ian Campbell wrote: >> In addition to the kernel logging of the error I get this from the >> hypervisor: >> (XEN) mm.c:2062:d0 Error pfn 16d99: rd=83011fefa000, >> od=, caf=180, taf=000

Bug#597828: linux-image-2.6.32-5-amd64: [xen] debug options + sysrq-t => sending NMI to all CPUs: BUG: unable to handle kernel paging request

On 09/24/2010 01:28 PM, Ian Campbell wrote: >> I think the Intel MCE people have made NMI work in pvops, but I didn't >> look closely. >> >> But from a pvops perspective, I think the tricky part is sending an NMI >> rather than receiving. > It's not just "HYPERVISOR_vcpu_op(VCPUOP_send_nmi, cpu, N

Bug#597828: linux-image-2.6.32-5-amd64: [xen] debug options + sysrq-t => sending NMI to all CPUs: BUG: unable to handle kernel paging request

On 09/24/2010 01:07 AM, Ian Campbell wrote: > NMI injection on 2.6.18 was one of the first Xen things I worked on (for > injecting h/w NMI button faults) so something worked once upon a time. I > can see CALLBACKTYPE_nmi and VCPUOP_send_nmi which seems promising that > it's still around (and exten

Bug#597828: linux-image-2.6.32-5-amd64: [xen] debug options + sysrq-t => sending NMI to all CPUs: BUG: unable to handle kernel paging request

On 09/23/2010 10:11 PM, Timo Juhani Lindfors wrote: > Ian Campbell writes: >> I guess the right thing to do would be to using some existing paravirt >> interface to send the IPI instead of tweaking the APIC directly, or if > Is > > void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector);

Bug#592428: Fix 2.6.32 XEN guest on old buggy RHEL5/EC2 hypervisor (XSAVE)

On 08/11/2010 07:23 PM, Ben Hutchings wrote: Your patch had mangled spacing around operators. This seems to be a bug in recent versions of Thunderbird, possibly related to . I was able to fix it up in this case as the context is obvious, but

Bug#592428: Fix 2.6.32 XEN guest on old buggy RHEL5/EC2 hypervisor (XSAVE)

On 08/11/2010 08:17 AM, Ian Campbell wrote: On Wed, 2010-08-11 at 07:55 -0700, Jeremy Fitzhardinge wrote: It's not clear that xsave could ever be usable by PV guests, even in principle, so its probably all completely over-engineered. If setting X86_CR4_OSXSAVE is problematic, then s

Bug#592428: Fix 2.6.32 XEN guest on old buggy RHEL5/EC2 hypervisor (XSAVE)

now why. The patch referred to by those two links says that old versions of Xen will simply kill the domain if they try to set CR4 bits the hypervisor doesn't understand, so this patch will not work. commit e826fe1ba1563a9272345da8e3279a930ac160a7 Author: Jeremy Fitzhardinge Date: Sat

Bug#592487: (no subject)

What kind of CPU is it? What's /proc/cpuinfo? Thanks, J -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c618195.1030...@goop.org

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

and does a 32b sysret if it is FLAT_USER_CS32. However, this is different from __USER32_CS, so it fails to return properly if we use the normal Linux segment. So avoid the whole mess by dropping VCGF_in_syscall and simply use plain iret to return to usermode. Signed-off-by: Jeremy Fitzhardinge diff --

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

On 11/23/09 09:23, Bastian Blank wrote: >> I don't believe that is the case (the processor would have to carry some >> state for the entire duration of a syscall for it to make any >> difference). I think the spec simply assumes that an OS author would >> want to use sysret if they used syscall. >>

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

On 11/23/09 07:25, Ian Campbell wrote: > On Sun, 2009-11-22 at 09:54 +, Bastian Blank wrote: > >> On Tue, Nov 17, 2009 at 10:04:36PM +0300, William Pitcock wrote: >> >>> [1.254927] init[1] general protection ip:f779042f sp:ff9b0340 error:0 >>> >> Hmm, this looks like the old

Bug#544145: 32bit binaries on x86_64/Xen segfaults in syscall-vdso

On 09/04/09 09:20, Bastian Blank wrote: > On Fri, Sep 04, 2009 at 09:07:39AM -0700, Jeremy Fitzhardinge wrote: > >> But for some reason that's triggering a failsafe callback, which invokes >> a GP. >> > Hmm, not in my tests. It always returned to use

Bug#544145: 32bit binaries on x86_64/Xen segfaults in syscall-vdso

On 09/03/09 15:36, Bastian Blank wrote: > This function looks weird. It tries to restores the user code segment. > But the documentation from AMD explicitely stat that the CS and SS are > restored from the STAR register. And STAR is always set with: wrmsrl(MSR_STAR, ((u64)__USER32_CS)<<48 |

Bug#544145: 32bit binaries on x86_64/Xen segfaults in syscall-vdso

On 09/03/09 15:02, Bastian Blank wrote: > AFAIK only AMD support the syscall instruction, so yes it is an AMD > machine. And yes, disabling the only thing that make the glibc call this > instruction works around it. > The bug actually appears to be in xen_sysret32, ie the crash happens on the w

Bug#544145: 32bit binaries on x86_64/Xen segfaults in syscall-vdso

On 08/30/09 11:16, Bastian Blank wrote: > Hi folks > > I upgraded one of my 32bit chroots on a x86-64 machine runing under Xen > lately. All binaries started to segfault. Some extensive checks later > show the vdso as the culprit. Later I found > with the same problem. The full story can be found