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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.04.13 at 17:32, George Dunlap <george.dunlap@xxxxxxxxxxxxx> 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.

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).

Tim, do you have any other thoughts?

Jan


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