Re: Issue about domU missing interrupt

G.R.
Tue, 04 Dec 2012 15:20:28 -0000

On Tue, Dec 4, 2012 at 7:01 PM, Pasi Kärkkäinen <pasik@iki.fi> 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.
>
>
Hi, it seems that the patch has some side effect on pure HVM guest.
For openelec 2.0 guest, which is based on linux 3.2.x with PVOP disabled, I
see such syndrome in qemu-dm-xxx.log:

pt_msgaddr64_reg_write: Error: why comes to Upper Address without 64 bit
support??
pt_pci_write_config: Internal error: Invalid write emulation return
value[-1]. I/O emulator exit.

The guest dies immediately after the log, I have no way to check guest
kernel log.
Without the patch, this guest can boot without obvious error log even the
VGA passthrough does not quite work.
I''ll check the code to see what does these log mean...

Thanks,
Timothy


> -- 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
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org