Xen project Mailing List

On Tue, Dec 4, 2012 at 7:01 PM, Pasi Kärkkäinen <pasik@xxxxxx> wrote:

On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich wrote:
> >>> On 04.12.12 at 04:07, "G.R." <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote:
> >> I had a quick look, and it doesn't look that hard to backport that patch.
> >
> > Thanks, Mat.
> > I'm glad to report that the patch do fix my problem.
> >
> > And yest it is really easy to port since the code did not change across the
> > two release.
> > The only change would be line numbers (3841 vs 3803) and one extra comments
> > before this line:
> >
> > static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)
> >
> > I'm not sure if you are going to release another maintenance version that
> > include this patch,
> > but I'll report this to Debain maintainer since it's about to freeze for
> > v7.0 release and v4.2.0 will not make it.
>
> Any thoughts on backporting this to 4.1.x, now or after 4.1.4 is
> out?
>

It's already in Xen 4.2, it's confirmed to fix a bug in Xen 4.1,
so I'd say it should be a candidate for Xen 4.1.4.

Hi, it seems that the patch has some side effect on pure HVM guest.
For openelec 2.0 guest, which is based on linux 3.2.x with PVOP disabled, I see such syndrome in qemu-dm-xxx.log:

pt_msgaddr64_reg_write: Error: why comes to Upper Address without 64 bit support??
pt_pci_write_config: Internal error: Invalid write emulation return value[-1]. I/O emulator exit.

The guest dies immediately after the log, I have no way to check guest kernel log.
Without the patch, this guest can boot without obvious error log even the VGA passthrough does not quite work.
I'll check the code to see what does these log mean...

Thanks,
Timothy

-- Pasi

> Jan
>
> > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson
> > <mats.petersson@xxxxxxxxxx>wrote:
> >
> >> On 03/12/12 13:19, Mats Petersson wrote:
> >>
> >>> On 03/12/12 13:14, G.R. wrote:
> >>>
> >>>> On Mon, Dec 3, 2012 at 6:15 PM, Mats Petersson
> >>>> <mats.petersson@xxxxxxxxxx
> > <mailto:mats.petersson@citrix.**com<mats.petersson@xxxxxxxxxx>>>
> >>>> wrote:
> >>>>
> >>>> On 03/12/12 03:47, G.R. wrote:
> >>>>
> >>>> Hi developers,
> >>>> I met some domU issues and the log suggests missing interrupt.
> >>>> Details from here:
> >>>> http://www.gossamer-threads.**com/lists/xen/users/263938#**
> >>>> 263938 <http://www.gossamer-threads.com/lists/xen/users/263938#263938>
> >>>> In summary, this is the suspicious log:
> >>>>
> >>>> (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3
> >>>>
> >>>> I've checked the code in question and found that mode 3 is an
> >>>> 'reserved_1' mode.
> >>>> I want to trace down the source of this mode setting to
> >>>> root-cause the issue.
> >>>> But I'm not an xen developer, and am even a newbie as a xen
> >>>> user.
> >>>> Could anybody give me instructions about how to enable
> >>>> detailed debug log?
> >>>> It could be better if I can get advice about experiments to
> >>>> perform / switches to try out etc.
> >>>>
> >>>> My SW config:
> >>>> dom0: Debian wheezy (3.6 experimental kernel, xen 4.1.3-4)
> >>>> domU: Debian wheezy 3.2.x stock kernel.
> >>>>
> >>>> Thanks,
> >>>> Timothy
> >>>>
> >>>> Are you passing hardware (PCI Passthrough) to the HVM guest?
> >>>> What are the exact messages in the DomU?
> >>>>
> >>>>
> >>>> Yes, I'm doing PCI passthrough (the IGD, audio && USB controller).
> >>>> But this is actually a PVHVM guest since debian stock kernel has PVOP
> >>>> enabled.
> >>>> And when I tried another PVOP disabled linux distro (openelec v2.0), I
> >>>> did not see such msi related error message.
> >>>> Actually, with that domU I do not see anything obvious wrong from the
> >>>> log, but I also see nothing from panel (panel receive no signal and go
> >>>> power-saving) :-(
> >>>>
> >>>>
> >>>> Back to the issue I was reporting, the domU log looks like this:
> >>>>
> >>>> Dec 2 21:52:44 debvm kernel: [ 1085.604071]
> >>>> [drm:i915_hangcheck_ring_idle]
> >>>> *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 3354, at
> >>>> 3354], missed IRQ?
> >>>> Dec 2 21:56:50 debvm kernel: [ 1332.076071]
> >>>> [drm:i915_hangcheck_ring_idle]
> >>>> *ERROR* Hangcheck timer elapsed... render ring idle [waiting on 11297, at
> >>>> 11297], missed IRQ?
> >>>> Dec 2 22:32:48 debvm kernel: [ 7.220073] hda-intel: azx_get_response
> >>>> timeout, switching to polling mode: last cmd=0x000f0000
> >>>> Dec 2 22:45:32 debvm kernel: [ 776.392084] hda-intel: No response from
> >>>> codec, disabling MSI: last cmd=0x002f0600
> >>>> Dec 2 22:45:33 debvm kernel: [ 777.400075] hda_intel: azx_get_response
> >>>> timeout, switching to single_cmd mode: last cmd=0x002f0600
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Timothy
> >>>>
> >>> It does sound like there is a fix in 4.2.0, as indicated by Jan, that
> >>> fixes this. I'm not fully clued up to what the policy for backporting
> >>> fixes are, and I haven't looked at the complexity of the fix itself, but
> >>> either updating to the 4.2.0 or a (personal) backport sounds like the
> >>> right solution here.
> >>>
> >> I had a quick look, and it doesn't look that hard to backport that patch.
> >>
> >> --
> >> Mats
> >>
> >>
> >>> Unfortunately, I hadn't seen Jan's reply by the time I wrote my response
> >>> to your original email.
> >>>
> >>> --
> >>> Mats
> >>>
> >>> ______________________________**_________________
> >>> Xen-devel mailing list
> >>> Xen-devel@xxxxxxxxxxxxx
> >>> http://lists.xen.org/xen-devel
> >>>
> >>>
> >>>
> >>
> >> ______________________________**_________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxx
> >> http://lists.xen.org/xen-devel
> >>
>
>
>

> _______________________________________________

> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________

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

Re: [Xen-devel] Issue about domU missing interrupt