Re: Issue about domU missing interrupt

Pasi Kärkkäinen
Tue, 04 Dec 2012 11:01:05 -0000

On Tue, Dec 04, 2012 at 10:15:58AM +0000, Jan Beulich
wrote:
> >>> On 04.12.12 at 04:07, "G.R."
<firemeteor@users.sourceforge.net> 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.

-- Pasi

> Jan
>
> > On Mon, Dec 3, 2012 at 9:58 PM, Mats Petersson
> > <mats.petersson@citrix.com>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@citrix.com
> >
<mailto:mats.petersson@citrix.**com<mats.petersson@citrix.com>>>
> >>>> 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@lists.xen.org
> >>> http://lists.xen.org/xen-devel
> >>>
> >>>
> >>>
> >>
> >> ______________________________**_________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> >>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel