On 11.08.2024 11:24, Bernhard Übelacker wrote:
> On Wed, 24 Jul 2024 12:50:23 +0200 Santiago Vila wrote:
>> Package: src:win32-loader
>> Version: 0.10.6
>> Severity: serious
>> Tags: ftbfs
>
>> During a rebuild of all packages in unstable, your package failed to build:
>
>> i686-w64-mingw32-as -
>>> On 16.05.17 at 05:47, wrote:
> On Mon, May 15, 2017 at 02:02:53AM -0600, Jan Beulich wrote:
>> >>> 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 run
>>> 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
> EDAC amd64: DRAM ECC
>>> 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"):
>> The package fails to build
>>> 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 with
all ones during boot.
Ho
>>> 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 single 6120 (dual memory
>>> 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,
>> > > when running x
>>> 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 this comes from, since Ian
sor to look for the Intel path.
>
> Reported-by: Stephan Seitz
> Signed-off-by: Ian Campbell
Not that it really matters for a Linux import refresh, but anyway:
Acked-by: Jan Beulich
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>>> On 23.05.14 at 12:08, wrote:
> On Fri, 2014-05-23 at 10:35 +0100, Jan Beulich wrote:
>> >>> On 23.05.14 at 11:21, 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
>>> On 23.05.14 at 11:21, 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
>>> On 22.05.14 at 19:19, wrote:
> "Jan Beulich" 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.x
>>> On 20.05.14 at 18:25, 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 - mind giving
h
>>> On 16.05.14 at 18:04, 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.
Following
>>> On 16.05.14 at 17:31, 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 (
>>> On 16.05.14 at 17:31, 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 (
>>> On 16.05.14 at 16:48, wrote:
> On 05/16/2014 06:08 AM, Jan Beulich wrote:
>>>>> On 16.05.14 at 10:58, wrote:
>>> So it seems like dom0 is unable to (correctly) bind to some hardware
>>> interrupts. I wonder if these messages from Xen's
>>> On 16.05.14 at 10:58, 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) Enabled directed E
>>> On 04.12.12 at 11:12, Ian Campbell wrote:
> On Tue, 2012-12-04 at 09:51 +, Jan Beulich wrote:
>> >>> On 04.12.12 at 10:33, Ian Campbell wrote:
>> > On Mon, 2012-12-03 at 19:47 +0100, Bastian Blank wrote:
>> >> Package: src:xe
>>> On 04.12.12 at 10:33, Ian Campbell 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 XZ
>>> On 09.11.12 at 10:05, 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 __read_platform_stime().
Should
>>> On 09.11.12 at 10:05, 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 the clock jump occurred
>>> On 08.11.12 at 11:38, Keir Fraser wrote:
> On 08/11/2012 09:39, "Jan Beulich" wrote:
>
>>>>>> (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
>>>>>> now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
>
>>> On 07.11.12 at 18:40, Keir Fraser wrote:
> On 07/11/2012 13:22, "Ian Campbell" 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
tsc_st
>>> On 07.11.12 at 11:10, 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 new_stamp=800366a5
>> plt_st
>>> Andrea Arcangeli 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 guess if Xen can
>>> On 11.10.11 at 10:02, Ian Campbell wrote:
> On Tue, 2011-10-11 at 08:07 +0100, Jan Beulich wrote:
>> >>> On 10.10.11 at 18:49, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > On Sat, Oct 08, 2011 at 10:13:14AM +0400, rush wrote:
>> &g
>>> On 10.10.11 at 18:49, Konrad Rzeszutek Wilk 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
> .. snip..
#x27; was declared here
> cc1: all warnings being treated as errors
>
> Add functions to read/write 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-
>>> Jeremy Fitzhardinge 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_cal
>>> Ian Campbell 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
>>> Ian Campbell 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.
But this is
32 matches
Mail list logo
