>>> On 27.11.15 at 23:51, wrote:
> Am 24.11.15 um 11:43 schrieb Jan Beulich:
>> Taking a random object out of that log, I can't see any non-standard
>> option passed to the compiler, so I have to assume this is its default
>> behavior (i.e. determined at build time, or established by extra
>> patc
Am 24.11.15 um 11:43 schrieb Jan Beulich:
Taking a random object out of that log, I can't see any non-standard
option passed to the compiler, so I have to assume this is its default
behavior (i.e. determined at build time, or established by extra
patches). Did you check the result of a random, no
Am 20.11.15 um 00:53 schrieb Andrew Cooper:
On 19/11/2015 20:02, Atom2 wrote:
Am 19.11.15 um 02:06 schrieb Andrew Cooper:
Thanks! That is what I was looking for.
Sadly, it is less useful than I was hoping. The guest is not appearing
to do anything interesting which causes the bad state; it is
>>> On 24.11.15 at 11:32, wrote:
> Am 20.11.15 um 08:57 schrieb Jan Beulich:
>> What you list above seems pretty normal indeed. However, why don't you
>> simply look at the options actually passed to gcc when building the
>> hypervisor. And you should also not forget that your distro's gcc
>> b
Am 20.11.15 um 08:57 schrieb Jan Beulich:
What you list above seems pretty normal indeed. However, why don't you
simply look at the options actually passed to gcc when building the
hypervisor. And you should also not forget that your distro's gcc
build itself may have certain non-standard optio
>>> On 19.11.15 at 20:51, wrote:
> In terms of non-standard options passed to gcc I have tried to make sense of
> what flags are actually being used during the build process. I am not
> absolutely sure, but I think the options passed to gcc are as follows:
>
> I do have system wide flags which
On 19/11/2015 20:02, Atom2 wrote:
> Am 19.11.15 um 02:06 schrieb Andrew Cooper:
>> Thanks! That is what I was looking for.
>>
>> Sadly, it is less useful than I was hoping. The guest is not appearing
>> to do anything interesting which causes the bad state; it is almost a
>> full second between th
Am 19.11.15 um 02:06 schrieb Andrew Cooper:
Thanks! That is what I was looking for.
Sadly, it is less useful than I was hoping. The guest is not appearing
to do anything interesting which causes the bad state; it is almost a
full second between the previous action of note, and the crash.
Can y
Am 19.11.15 um 11:38 schrieb Andrew Cooper:
On 19/11/15 10:24, Jan Beulich wrote:
On 19.11.15 at 00:17, wrote:
The disassembly of do_IRQ now looks like a plausible function, but the
consistently faulting address has no plausible way of generating a
double fault. I suspect therefore that somet
On 19/11/15 10:24, Jan Beulich wrote:
On 19.11.15 at 00:17, wrote:
>> The disassembly of do_IRQ now looks like a plausible function, but the
>> consistently faulting address has no plausible way of generating a
>> double fault. I suspect therefore that something has caused memory
>> corrupti
>>> On 19.11.15 at 00:17, wrote:
> The disassembly of do_IRQ now looks like a plausible function, but the
> consistently faulting address has no plausible way of generating a
> double fault. I suspect therefore that something has caused memory
> corruption in Xen .text section.
Dump of assembler
On 19/11/2015 00:31, Atom2 wrote:
> Am 19.11.15 um 00:17 schrieb Andrew Cooper:
>> On 18/11/2015 22:51, Atom2 wrote:
>>> Am 17.11.15 um 00:10 schrieb Atom2:
> [big snip]
>>> Hi Andrew,
>>> as promised I have again tried with a debug build and the results are
>>> very mixed. I initially tried to bet
Am 19.11.15 um 00:17 schrieb Andrew Cooper:
On 18/11/2015 22:51, Atom2 wrote:
Am 17.11.15 um 00:10 schrieb Atom2:
[big snip]
Hi Andrew,
as promised I have again tried with a debug build and the results are
very mixed. I initially tried to better understand what the debug USE
flag actually does
On 18/11/2015 22:51, Atom2 wrote:
> Am 17.11.15 um 00:10 schrieb Atom2:
>> Am 17.11.15 um 00:01 schrieb Andrew Cooper:
>>> On 16/11/2015 19:16, Atom2 wrote:
Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk:
Your analysis was absolutely spot on. After re-thinking this for a
Am 17.11.15 um 00:10 schrieb Atom2:
Am 17.11.15 um 00:01 schrieb Andrew Cooper:
On 16/11/2015 19:16, Atom2 wrote:
Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk:
Your analysis was absolutely spot on. After re-thinking this for a
moment, I thought going down that route first would make a l
Am 17.11.15 um 00:01 schrieb Andrew Cooper:
On 16/11/2015 19:16, Atom2 wrote:
Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk:
Your analysis was absolutely spot on. After re-thinking this for a
moment, I thought going down that route first would make a lot of
sense
as PV guests still do wor
On 16/11/2015 19:16, Atom2 wrote:
>
>
> Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk:
> Your analysis was absolutely spot on. After re-thinking this for a
> moment, I thought going down that route first would make a lot of
> sense
> as PV guests still do work and one of the di
Am 16.11.15 um 20:47 schrieb Doug Goldstein:
I'm a little late to the thread but can you send me (you can do it
off-list if you'd like) the USE flags you used for xen, xen-tools and
seabios? Also emerge --info. You can kill two birds with one stone by
using emerge --info xen.
Hi Doug,
here you g
On 11/15/15 7:05 PM, Atom2 wrote:
> Am 15.11.15 um 21:12 schrieb Doug Goldstein:
>> On 11/14/15 6:14 PM, Atom2 wrote:
>>> Am 14.11.15 um 21:32 schrieb Andrew Cooper:
On 14/11/2015 00:16, Atom2 wrote:
> Am 13.11.15 um 11:09 schrieb Andrew Cooper:
>> On 13/11/15 07:25, Jan Beulich wrote:
On Mon, Nov 16, 2015 at 01:39:08PM -0600, Doug Goldstein wrote:
> On 11/16/15 1:25 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 16, 2015 at 08:16:33PM +0100, Atom2 wrote:
> >>
> >>
> >> Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk:
> >> Your analysis was absolutely spot on. After re-t
Am 16.11.15 um 20:25 schrieb Konrad Rzeszutek Wilk:
[snip]
I thought Gentoo was all about rebuilding from source and not
taking binary blobs.
Well, you probably caught Gentoo on the wrong foot here, but generally
it is what you thought it was. And IMHO that's the beauty of it.
Applying a patch
On 11/16/15 1:25 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 16, 2015 at 08:16:33PM +0100, Atom2 wrote:
>>
>>
>> Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk:
>> Your analysis was absolutely spot on. After re-thinking this for a
>> moment, I thought going down that route first woul
On Mon, Nov 16, 2015 at 08:16:33PM +0100, Atom2 wrote:
>
>
> Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk:
> Your analysis was absolutely spot on. After re-thinking this for a
> moment, I thought going down that route first would make a lot of sense
> as PV guests still do work
Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk:
Your analysis was absolutely spot on. After re-thinking this for a
moment, I thought going down that route first would make a lot of sense
as PV guests still do work and one of the differences to HVM domUs is
that the former do _not_ require S
> >>Your analysis was absolutely spot on. After re-thinking this for a
> >>moment, I thought going down that route first would make a lot of sense
> >>as PV guests still do work and one of the differences to HVM domUs is
> >>that the former do _not_ require SeaBIOS. Looking at my log files of
> >>i
On 16/11/15 00:39, Atom2 wrote:
> Am 15.11.15 um 16:12 schrieb Andrew Cooper:
> [big snip]
>> Great - so confirms the issue as a SeaBIOS interaction issue, rather
>> than a hypervisor regression.
>>
>> As I said before, I am still certain that a guest should not be able
>> to get itself into the cr
Am 15.11.15 um 21:12 schrieb Doug Goldstein:
On 11/14/15 6:14 PM, Atom2 wrote:
Am 14.11.15 um 21:32 schrieb Andrew Cooper:
On 14/11/2015 00:16, Atom2 wrote:
Am 13.11.15 um 11:09 schrieb Andrew Cooper:
On 13/11/15 07:25, Jan Beulich wrote:
On 13.11.15 at 00:00, wrote:
Am 12.11.15 um 17:43 s
Am 15.11.15 um 16:12 schrieb Andrew Cooper:
[big snip]
Great - so confirms the issue as a SeaBIOS interaction issue, rather
than a hypervisor regression.
As I said before, I am still certain that a guest should not be able
to get itself into the crashing state (short of a hardware errata), so
On 11/14/15 6:14 PM, Atom2 wrote:
> Am 14.11.15 um 21:32 schrieb Andrew Cooper:
>> On 14/11/2015 00:16, Atom2 wrote:
>>> Am 13.11.15 um 11:09 schrieb Andrew Cooper:
On 13/11/15 07:25, Jan Beulich wrote:
On 13.11.15 at 00:00, wrote:
>> Am 12.11.15 um 17:43 schrieb Andrew Cooper:
>
On 15/11/15 00:14, Atom2 wrote:
>
>> Right - it would appear that the USE flag is definitely not what you
>> wanted, and causes bad compilation for Xen. The do_IRQ disassembly
>> you sent is a the result of disassembling a whole block of zeroes.
>> Sorry for leading you on a goose chase - the dou
Am 14.11.15 um 21:32 schrieb Andrew Cooper:
On 14/11/2015 00:16, Atom2 wrote:
Am 13.11.15 um 11:09 schrieb Andrew Cooper:
On 13/11/15 07:25, Jan Beulich wrote:
On 13.11.15 at 00:00, wrote:
Am 12.11.15 um 17:43 schrieb Andrew Cooper:
On 12/11/15 14:29, Atom2 wrote:
Hi Andrew,
thanks for you
On 14/11/2015 00:16, Atom2 wrote:
> Am 13.11.15 um 11:09 schrieb Andrew Cooper:
>> On 13/11/15 07:25, Jan Beulich wrote:
>> On 13.11.15 at 00:00, wrote:
Am 12.11.15 um 17:43 schrieb Andrew Cooper:
> On 12/11/15 14:29, Atom2 wrote:
>> Hi Andrew,
>> thanks for your reply. Answer
Am 13.11.15 um 11:09 schrieb Andrew Cooper:
On 13/11/15 07:25, Jan Beulich wrote:
On 13.11.15 at 00:00, wrote:
Am 12.11.15 um 17:43 schrieb Andrew Cooper:
On 12/11/15 14:29, Atom2 wrote:
Hi Andrew,
thanks for your reply. Answers are inline further down.
Am 12.11.15 um 14:01 schrieb Andrew C
On 13/11/15 07:25, Jan Beulich wrote:
On 13.11.15 at 00:00, wrote:
>> Am 12.11.15 um 17:43 schrieb Andrew Cooper:
>>> On 12/11/15 14:29, Atom2 wrote:
Hi Andrew,
thanks for your reply. Answers are inline further down.
Am 12.11.15 um 14:01 schrieb Andrew Cooper:
> On 12/
>>> On 13.11.15 at 00:00, wrote:
> Am 12.11.15 um 17:43 schrieb Andrew Cooper:
>> On 12/11/15 14:29, Atom2 wrote:
>>> Hi Andrew,
>>> thanks for your reply. Answers are inline further down.
>>>
>>> Am 12.11.15 um 14:01 schrieb Andrew Cooper:
On 12/11/15 12:52, Jan Beulich wrote:
On 12
Am 12.11.15 um 17:43 schrieb Andrew Cooper:
On 12/11/15 14:29, Atom2 wrote:
Hi Andrew,
thanks for your reply. Answers are inline further down.
Am 12.11.15 um 14:01 schrieb Andrew Cooper:
On 12/11/15 12:52, Jan Beulich wrote:
On 12.11.15 at 02:08, wrote:
After the upgrade HVM domUs appear to
On 12/11/15 14:29, Atom2 wrote:
> Hi Andrew,
> thanks for your reply. Answers are inline further down.
>
> Am 12.11.15 um 14:01 schrieb Andrew Cooper:
>> On 12/11/15 12:52, Jan Beulich wrote:
>> On 12.11.15 at 02:08, wrote:
After the upgrade HVM domUs appear to no longer work - regardless
>>> On 12.11.15 at 15:29, wrote:
> Another question is whether prior to enabling the debug USE flag it
> might make sense to re-compile with gcc-4.8.5 (please see my previous
> list reply) to rule out any compiler related issues. Jan, Andrew - what
> are your thoughts?
The order of things you
Hi Andrew,
thanks for your reply. Answers are inline further down.
Am 12.11.15 um 14:01 schrieb Andrew Cooper:
On 12/11/15 12:52, Jan Beulich wrote:
On 12.11.15 at 02:08, wrote:
After the upgrade HVM domUs appear to no longer work - regardless of the
dom0 kernel (tested with both 3.18.9 and 4
Hi Jan,
many thanks for your reply. Answers are further down inline.
Am 12.11.15 um 13:52 schrieb Jan Beulich:
On 12.11.15 at 02:08, wrote:
After the upgrade HVM domUs appear to no longer work - regardless of the
dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV
domUs, howe
On 12/11/15 12:52, Jan Beulich wrote:
On 12.11.15 at 02:08, wrote:
>> After the upgrade HVM domUs appear to no longer work - regardless of the
>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV
>> domUs, however, work just fine as before on both dom0 kernels.
>>
>> xl
>>> On 12.11.15 at 02:08, wrote:
> After the upgrade HVM domUs appear to no longer work - regardless of the
> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV
> domUs, however, work just fine as before on both dom0 kernels.
>
> xl dmesg shows the following information afte
Hi guys,
today I have upgraded from XEN 4.5.1 to XEN 4.5.2 and also upgraded the
dom0 kernel from 3.18.9 to 4.1.7
After the upgrade HVM domUs appear to no longer work - regardless of the
dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV
domUs, however, work just fine as b
43 matches
Mail list logo
