From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sander Eikelenboom Subject: Re: Issue about domU missing interrupt Date: Wed, 5 Dec 2012 16:34:01 +0100 Message-ID: <32870747.20121205163401@eikelenboom.it> References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> <50BCAFEF.7040300@citrix.com> <50BDDB6E02000078000ADA98@nat28.tlf.novell.com> <20121204110105.GX8912@reaktio.net> <28369388.20121205000539@eikelenboom.it> <1662073313.20121205130222@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Mats Petersson , Ian Jackson , "G.R." , xen-devel , Jan Beulich , Anthony Perard List-Id: xen-devel@lists.xenproject.org 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." 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 >> >> >> > 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 >> >> >> >>>> > >> >> > >> >> >> >> >>>> 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@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 >> >> >> >> >> >> >> >>