xming wrote:
Thanks, that answers that particular question; the vcpu is blocked
waiting for something to happen, which probably means it missed the
event which was supposed to wake it up. Why is another question. At
least there's a workaround, and that workaround gives me some clue where
to loo
On Jan 20, 2008 7:37 PM, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> xming wrote:
> > ok I have done some of them, but I still don't know what I should be looking
> > at. Do you mean code related to xen or code related to
> > have_vcpu_info_placement?
> > Please be patient with me :)
> >
> >
xming wrote:
ok I have done some of them, but I still don't know what I should be looking
at. Do you mean code related to xen or code related to have_vcpu_info_placement?
Please be patient with me :)
I just paste some of the result (around those addresses) here:
Thanks, that answers that pa
On Jan 18, 2008 6:26 PM, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> >> Would it be possible to map the eip and some top parts of the stack back
> >> to kernel symbols? Seems to be the same place in both traces, which is
> >> interesting.
> Do "nm -n vmlinux" on the kernel to set an address
xming wrote:
Would it be possible to map the eip and some top parts of the stack back
to kernel symbols? Seems to be the same place in both traces, which is
interesting.
Can you tell me how, or show me some pointers?
Do "nm -n vmlinux" on the kernel to set an address sorted list of
On Jan 18, 2008 5:19 PM, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > First of all this patch solves the lock-ups, it works as advertised :)
>
> OK, good. I guess events are getting lost somewhere with vcpu_info
> placement.
> Would it be possible to map the eip and some top parts of the
xming wrote:
OK, I misunderstood your original report to mean that something was
complaining about "too much" output. You're saying that lots of console
output seems to lock the domain.
Sorry about that, and yes that is the case.
I've had a report about heavy disk IO seems to lock up
> OK, I misunderstood your original report to mean that something was
> complaining about "too much" output. You're saying that lots of console
> output seems to lock the domain.
Sorry about that, and yes that is the case.
> I've had a report about heavy disk IO seems to lock up as well. Perhap
xming wrote:
The symptom is (with a lot of subjective judgment) when there is a lot (or
too quick) output on the console of the domU (hvc0 connected with either
"xm crea file.cfg -c" or "xm cons id") the whole PV domU hangs. It will
really hang at random places, sometimes right after init and som
On Jan 17, 2008 6:15 PM, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Uh, that's very strange. That patch fixes an outright bug, unless
> you're using one specific changeset out of the xen-unstable mercurial
> tree. What version of Xen are you using? Is it one you've built from
> xenbits, o
xming wrote:
Hi,
I finally found the piece of code that prevents me from booting Xen DomU
with vallina kernel > 2.6.23.1.
The problem is that with every kernel (> 2.6.32.1 including 2.6.24 RCs)
will just hang with "too much" console activity. Sometimes (well most
of the time) boot msg is too mu
Hi,
I finally found the piece of code that prevents me from booting Xen DomU
with vallina kernel > 2.6.23.1.
The problem is that with every kernel (> 2.6.32.1 including 2.6.24 RCs)
will just hang with "too much" console activity. Sometimes (well most
of the time) boot msg is too much. When I can
12 matches
Mail list logo
