From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Bug: Windows 2003 fails to install on xen-unstable tip Date: Tue, 23 Apr 2013 11:38:54 +0100 Message-ID: <517664BE.401@eu.citrix.com> References: <516D7DA202000078000CDA60@nat28.tlf.novell.com> <516D61A8.1080102@eu.citrix.com> <516E791902000078000CDE09@nat28.tlf.novell.com> <516EE63E.4090008@eu.citrix.com> <5171332602000078000CEE8A@nat28.tlf.novell.com> <51712018.4010600@citrix.com> <5171591402000078000CF023@nat28.tlf.novell.com> <51714BE5.8080909@eu.citrix.com> <517535A702000078000CF75C@nat28.tlf.novell.com> <517557F3.9020605@eu.citrix.com> <51767DC402000078000CFE48@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51767DC402000078000CFE48@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Eddie Dong , "xen-devel@lists.xen.org" , "Tim (Xen.org)" , Suravee Suthikulpanit , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org On 23/04/13 11:25, Jan Beulich wrote: >>>> On 22.04.13 at 17:32, George Dunlap 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