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

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



Tuesday, December 4, 2012, 12:01:05 PM, you 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.

Just tried switching the device model to "qemu-xen", seems this one isn't 
upstream either.
(XEN) [2012-12-04 22:49:25] vmsi.c:108:d32767 Unsupported delivery mode 3

Running xen-unstable as of today, with device-model "qemu-xen" for this hvm 
guest.

--
Sander

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


 


Rackspace

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