[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] High CPU temp, suspend problem - xen 4.1.5-pre, linux 3.7.x
On 28.03.2013 17:25, Jan Beulich wrote: >>>> On 27.03.13 at 15:31, Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx> > wrote: >> On 27.03.2013 09:52, Jan Beulich wrote: >>>>>> On 26.03.13 at 19:50, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: >>>> So vector e9 doesn't appear to be programmed in anywhere. >>> >>> Quite obviously, as it's the 8259A vector for IRQ 9. The question >>> really is why an IRQ appears on that vector in the first place. The >>> 8259A resume code _should_ leave all IRQs masked on a fully >>> IO-APIC system (see my question raised yesterday). >>> >>> And that's also why I suggested, for an experiment, to fiddle with >>> the loop exit condition to exclude legacy vectors (which wouldn't >>> be a final solution, but would at least tell us whether the direction >>> is the right one). In the end, besides understanding why an >>> interrupt on vector E9 gets raised at all, we may also need to >>> tweak the IRQ migration logic to not do anything on legacy IRQs, >>> but that would need to happen earlier than in >>> smp_irq_move_cleanup_interrupt(). Considering that 4.3 >>> apparently doesn't have this problem, we may need to go hunt for >>> a change that isn't directly connected to this, yet deals with the >>> problem as a side effect (at least I don't recall any particular fix >>> since 4.2). One aspect here is the double mapping of legacy IRQs >>> (once to their IO-APIC vector, and once to their legacy vector, >>> i.e. vector_irq[] having two entries pointing to the same IRQ). >> >> So tried change loop condition to LAST_DYNAMIC_VECTOR and it doesn't hit >> that >> BUG/ASSERT. But still it doesn't work - only CPU0 used by scheduler, also >> some >> errors from dom0 kernel, and errors about PCI devices used by domU(1). >> >> Messages from resume (different tries): >> http://duch.mimuw.edu.pl/~marmarek/qubes/xen-4.1-last-dynamic-vector.log >> http://duch.mimuw.edu.pl/~marmarek/qubes/xen-4.1-last-dynamic-vector2.log > > Is that a sensible usage scenario at all? I would think that a > prerequisite to host S3 is that all guests get suspended. What do you mean by "suspended"? I haven't found any sane method to do that with xl (only some manual xenstore write to control/shutdown). For now I do: - shutdown all network adapters in VMs - pause all VMs > If you > do that, do you still have these interrupt re-setup problems? Yes, even when no guest is running (which was the case on 4.2)... -- Best Regards / Pozdrawiam, Marek Marczykowski Invisible Things Lab Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |