From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mats Petersson Subject: Re: Issue about domU missing interrupt Date: Mon, 3 Dec 2012 13:58:07 +0000 Message-ID: <50BCAFEF.7040300@citrix.com> References: <50BC7BAC.8050107@citrix.com> <50BCA6F3.8060804@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50BCA6F3.8060804@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 > >