Re: Bug: Windows 2003 fails to install on xen-unstable tip

[George Dunlap <george.dunlap@eu.citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4137 bytes --]

On 23/04/13 15:43, jacek burghardt wrote:
> 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

1. Don't top-post
2. Don't hijack a thread to talk about an unrelated topic.

If you have a bug to report, please write a new e-mail with the 
pertinent information.

  -George

>
>
> On Tue, Apr 23, 2013 at 8:21 AM, George Dunlap 
> <george.dunlap@eu.citrix.com <mailto:george.dunlap@eu.citrix.com>> wrote:
>
>     On 23/04/13 14:00, Jan Beulich wrote:
>
>                     On 23.04.13 at 13:52, George Dunlap
>                     <george.dunlap@eu.citrix.com
>                     <mailto:george.dunlap@eu.citrix.com>> wrote:
>
>             On 23/04/13 12:33, Jan Beulich wrote:
>
>                             On 23.04.13 at 12:38, George Dunlap
>                             <george.dunlap@eu.citrix.com
>                             <mailto:george.dunlap@eu.citrix.com>> 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 <http://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 <http://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 <http://C.PF>, assert/deassert, set IRQF if
>     setting C.PF <http://C.PF> (don't check B.PIE)
>      FAIL
>     * destroy if C.PF <http://C.PF>, always assert/deassert + set C.IRQF
>      FAIL
>     * never destroy, assert/deassert + set C.IRQF if setting C.PF
>     <http://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@lists.xen.org <mailto:Xen-devel@lists.xen.org>
>     http://lists.xen.org/xen-devel
>
>


[-- Attachment #1.2: Type: text/html, Size: 8469 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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