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

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

On 23/04/13 11:25, Jan Beulich wrote:
>>>> On 22.04.13 at 17:32, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> (XEN) pt on: 10 @14fd4b61ef^M
>> (XEN) B=42 [A:2a B:02 C:50 pt:10/0] @14fd6f73d9^M
>> (XEN) C=50 pt=10/0 @14fdb032f8^M
>> (XEN) C=c0 pt=10/6 @14fddabc31^M
>> (XEN) C=00 pt=10/0 @14fe04d583^M
>> (XEN) C=c0 pt=10/0 @14feaa9978^M
>> (XEN) C=00 pt=10/0 @14fed2ae4b^M
>> (XEN) C=c0 pt=10/0 @14ff98fe90^M
>> (XEN) C=00 pt=10/0 @14ffc0fbc1^M
>> (XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0^M
>> (XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0^M
>> (XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0^M
>> (XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0^M
>> (XEN) pt off #105 @15e95c8ff8^M
>> (XEN) pt irq @15da75fb9c (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15db644b09 (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15dc53074a (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15dd41309b (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15de2f93db (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15df1e6232 (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15e00c3c2f (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15e0faca4c (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15e1e94f41 (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15e2d7b303 (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15e3c61780 (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15e4b4cd99 (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15e5a33c65 (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15e690a53a (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15e77f1d0f (rtc_periodic_interrupt+0x81/0x93)^M
>> (XEN) pt irq @15e86d876a (rtc_periodic_interrupt+0x81/0x93)^M
> So we send IRQs as regularly as we're expected to, but Windows
> doesn't even look at REG_C. To me it seems perfectly valid to stop
> sending further IRQs in that case.

Perhaps something else is going on -- e.g., Windows is *reading* 
something different from the RTC, and acting differently in response to 
that?

It's obviously a quirk in Windows 2003, as XP and Win7 seem to deal with 
it just fine.  Nonetheless, we can't very well just say, "Well, it's a 
bug in Windows, so go talk to Microsoft". :-)

>
> In any event the time stamps appear to confirm that the respective
> second REG_C reads are likely checks at the end of the interrupt
> handler in Windows, and that the increased deferral of turning off
> the periodic timer didn't make a difference.
>
> Just to double check - could you comment out entirely the first
> (normal code, i.e. not the one marked //todo?) "else if" in
> rtc_periodic_interrupt() (including its body of course)? I would
> expect this to not make a difference, and if so I don't see how
> Windows expects to be woken up again (I would guess that
> they internally have some gating logic preventing the normal IRQ8
> handling to happen, yet of course we don't know what would
> reset that state).

In fact, when I comment out that region, then it hangs in the guest BIOS 
before even attempting to boot the CD.

I took a look at the offending changeset, and unfortunately it seems to 
have a lot of different changes, so it's not 100% clear which ones are 
related or not.   I'll give it a try anyway. Do you not have boot images 
of Windows 2003 that you can test yourself?

  -George