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

[Mats Petersson <mats.petersson@xxxxxxxxxx>]

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@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
> >          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