[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Bug: Windows 2003 fails to install on xen-unstable tip

>>> On 23.04.13 at 13:52, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 23/04/13 12:33, Jan Beulich wrote:
>>>>> On 23.04.13 at 12:38, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
>>> Do you not have boot images of Windows 2003 that you can test yourself?
>> In fact I don't have any non-machine-bound Windows images at
>> all. Let me go see whether my American colleagues could help out
>> here...
> So I manually broke the patch down into 5 component parts (attached).  
> The installer works just fine for the first 3 -- the ones actually 
> mentioned in the patch changeset.  It breaks when the handler is moved 
> into the generic IRQ timer code rather than having its own callback (I 
> think that's what's happening there, anyway).

Just went through that change again: The only thing that changes
is that while rtc_periodic_cb() (simply setting REG_C flags) got
called at the end of pt_intr_post(), rtc_periodic_interrupt() now
gets called from pt_update_irq(), and therefore takes care of
asserting the IRQ itself (which originally happened inside
pt_update_irq()) along with setting REG_C flags. Bottom line -
all the patch changes is when exactly REG_PF (and possibly
REG_IRQF) get set, and whether the IRQ actually gets asserted.

And of course we're now suppressing redundantly re-asserting
the same IRQ, if we see that it didn't get handled for some time
(that's with Tim's subsequent adjustment - originally the patch
caused the IRQ to be asserted exactly once).

And just to be clear - it is the purpose of the change to neither
raise the IRQ needlessly nor run the periodic timer when there's
no use for it (because once RTC_PF got set, subsequent
invocations are supposed to have no effect at all).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.