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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 5 Dec 2012, Sander Eikelenboom wrote:
> Wednesday, December 5, 2012, 12:51:13 PM, you wrote:
> 
> > On Tue, 4 Dec 2012, Sander Eikelenboom wrote:
> >> 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.
> >> 
> 
> > The patch is supposed to fix a bug affecting msi_translate but in
> > upstream QEMU we haven't implemented msi_translate at all! So in this
> > case the cause of the bug (and as a consequence the fix) must be a
> > different one.
> 
> Ok will see if i can find out what is going on. Probably have to force 
> msi_translate=0.
> 
> I noticed "qemu-xen" doesn't make a log file in /var/log/xen as "qemu-dm" 
> does, is this expected ?

No, it is not. You should get the usual /var/log/xen/qemu-dm-domainname.log 
file.


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