Re: Issue about domU missing interrupt

Sander Eikelenboom
Wed, 05 Dec 2012 15:34:01 -0000

Wednesday, December 5, 2012, 1:07:07 PM, you wrote:

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

Using msi_translate=0 didn''t change a thing, still got
"unsupported delivery mode" and a non working passthrough device.
lspci in the HVM shows MSI-X enabled for the device, but it doesn''t
function properly.

00:05.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev
03) (prog-if 30 [XHCI])
        Subsystem: Micro-Star International Co., Ltd. Device 4257
        Physical Slot: 5
        Flags: bus master, fast devsel, latency 0, IRQ 36
        Memory at f3250000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [50] Power Management version 3
        Capabilities: [70] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
        Capabilities: [a0] Express Endpoint, MSI 00
        Capabilities: [100] #1033
        Kernel driver in use: xhci_hcd


Disabling MSI completly for the HVM (by using pci=nomsi for the HVM kernel)
makes passthrough device work ok with normal interrupts.

Looking into qemu-xen-dir/hw i do see xen-msi.c, so there seems to be work done
in that area ?

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

You were right, all though it lacks a bit in verbosity i guess ... the only 2
lines i''m getting are:

char device redirected to /dev/pts/17
Issued domain 25 poweroff

Instead of the 99 lines of output when using qemu-xen-traditional.


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