[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] [Xen-devel] Cannot Start Linux Paravirtualized (PV) Guests with Xen 4.2-unstable



On Thu, 2012-03-29 at 18:05 +0100, Teo En Ming (Zhang Enming) wrote:
> 2) I was NOT able to start Fedora 16 x86-64 Paravirtualized domU in
> Xen 4.2-unstable with xl. The above Youtube video demonstrates it. But
> I was able to start Fedora 16 x86-64 PV domU in Xen 4.1.3-rc1-pre with
> xl. This is clearly a bug. 

I am only going to consider this bug for the time being. We can get to
the others later on. Considering multiple bugs in a single thread simply
leads to confusion.

I'm afraid that I am not going to watch youtube videos in order to find
out the details of a bug though. Please stick to plain text emails.

> I have already provided all the information you guys have requested in
> my previous emails. So why won't you reply to me?

Often when a user reports a bug it is necessary for a developer to ask
follow up questions in order to get it straight in their head what the
issue is and to ensure that everyone is on the same page with respect to
what the symptoms observed are and what the relevant information about
the bug is. This dialogue is often far more important than the original
bug report in order for a developer to be able to properly understand an
issue and is an important part of the mechanism by which bugs are
understood and fixed.

However this will sometimes mean that a bug reporter is being asked to
repeat information which they have already provided. Sometimes it may
even become necessary to reset the whole process and start again from
first principles, starting from a more specific set of initial
questions. This should not be construed as a criticism of the original
bug report, it is simply sometimes necessary in order for developers to
make progress on a bug.

If a developer asks a follow up question to a bug report then that is
because they are asking for your help because they feel that the answer
to the question will help them to make progress on understanding the bug
and work towards a fix.

Now, with regard to this bug. I read your original email and went
through all the logs which you provided. I was not able to spot anything
which gave me a clue as to what the bug which you described was or to
correlate the contents of the logs which you provided with the
occurrence of that bug. I also tried to reproduce the issue and was
unable to do so. I explained this in
<1332165544.9223.85.camel@xxxxxxxxxxxxxxxxxxxxxx>, and asked you to
please provide a targeted set of logs and the output of the commands
which were failing with some extra debug enabled (which may well repeat
some information already provided) which would help me to better
understand the issue and hopefully provide me with the insight necessary
to understand the bug. Here is what I asked for in that mail:

        Please can you provide a single guest configuration file which
        demonstrates the issue which you are seeing and the output of
        running "xl -vvv create -c <cfg>" for that precisely that <cfg>
        file. Please also attach exactly
        the /var/log/xen/qemu-dm-<name>.log
        and /var/log/xen/xl-<name>.log produced by exactly that
        invocation of xl.

I am not asking these questions to be difficult or to somehow avoid
fixing the bug, nor am I criticising your original bug report. You can
be sure that if I were able to understand and fix the bug based on the
information you have already provided or by reproducing it myself I
would have done so immediately. I'm afraid that I cannot make any more
progress on this bug without help from someone such as yourself who is
experiencing the issue. I hope you will be willing to provide that
information (yes, this may well mean repeating information which you
have provided before, I am sorry about that).

Ian.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.