On Tue, May 3, 2016 at 3:11 PM, Miguel C wrote:
> This was reported by me and others a few times its was actually fixed in
> some 10.0 (current build at the time) but we could never track it, however
> it always seemed related to tso, netbsd backhend (as I was told back
That's starting to sound like a bug in NetBSD's netback driver.
Particularly since it doesn't happen with a Linux dom0 (AFAIK).
-M
On Tuesday, May 3, 2016, Stephen Jones
wrote:
> > > >Can you try with a HEAD snapshot? netfront has been recently reworked
>
It is possible to grab a coredump through xen. That would simplify
diagnosis. I also wrote a patch to gdbserver that allowed one to treat
a running VM or a core as a process.
Cheers
On Wed, Jul 27, 2011 at 6:52 PM, Sean Bruno sean...@yahoo-inc.com wrote:
Simple left my xen domu running over
Correct, I put much of the infrastructure in place but did not end up
debugging it in to existence.
Cheers
On Tuesday, July 26, 2011, Sean Bruno sean...@yahoo-inc.com wrote:
I assume then, that the i386 PV instance cannot do more than 1 CPU at
this time?
sean
Started domain ref8-xen32
It's an artifact of the initialization code and how the xen domain builder
configures the initial mapped memory. I've come against this and fixed this
issue in the past but I guess either the domain builder has changed or the
initial code has bit rotted. I can't commit so ask Colin if he can fix.
I think that sort of makes sense to me. That is, there would need to be
a PV framebuffer driver for PV mode to use it. I guess.
Someone(TM) just needs to port the driver. FBs are fairly trivial to
support.
Cheers
Sean
___
Just to verify, other guests (e.g. Linux || NetBSD) don't exhibit this
problems? It sounds almost as if xend isn't configuring the domain
properly.
-Kip
On Sun, May 29, 2011 at 1:02 PM, Hugo Silva h...@barafranca.com wrote:
On 05/25/11 17:20, Hugo Silva wrote:
On 05/24/11 21:14, Hugo Silva