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

[jacek burghardt <jaceksburghardt@xxxxxxxxx>]

How is networking with w2k3. I had tested server 2012 2008R2 and w2k3 and there is no network as of most recent xen unstable. I have to install xen drivers to get network working. Hvm has bug were there is no network connectivity dhcpd does not work so my freenas nas no network anymore.

I also hope this will fix issues with freenas 

On Tue, Apr 23, 2013 at 8:21 AM, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:

On 23/04/13 14:00, Jan Beulich wrote:

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.

So that last bit seems to do these things:
a. Changes when the handling happens in the Xen interrupt handler
b. Causes assert/deassert to only happen if !(C.PF) && (B.PIE)
  (Before it happened unconditionally)
c. Causes C.IRQF=1 only if (same condition above)
 (Before it happened unconditionally)
d. Runs destroy_periodic_timer() if C.PF already

So just to figure out what it was that w2k3 wanted, I tried a bunch of variations:

* All of above
 BAD
* a only; always assert/deassert + set C.IRQF
 GOOD
* always assert/deassert, but leave destroy_periodic_timer and IRQF setting alone
 FAIL
* destroy if C.PF, assert/deassert, set IRQF if setting C.PF (don't check B.PIE)
 FAIL
* destroy if C.PF, always assert/deassert + set C.IRQF
 FAIL
* never destroy, assert/deassert + set C.IRQF if setting C.PF
 FAIL
* never destroy, assert/deassert + set C.IRQF if !C.IRQF
 FAIL

In short, it seems that w2k3 basically expects an unlimited number of attempts to actually deliver the interrupt.

Let me see if I can get a patch to the tip of unstable (with all the other intermediate changes)...

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel