Is there a way to put Windows in PIC-mode instead of APIC-mode?

NTDEV
21

Switching between ACPI and non-ACPI has system-wide consequences.
Switching between PIC and APIC affects only the interrupt controller.
I doubt that you’ll have a problem.

  • Jake Oshins

“Taed Wynnell” wrote in message
news:xxxxx@ntdev…
> “Don Burn” wrote in message news:xxxxx@ntdev…
>> if you are asking how to put the same disk image of an
>> embedded type system on both the old system and the apic system,
>> then you might look at the boot.ini option /HAL= This will allow
>> you to specify the apic HAL as boot.ini option.
>
> Thanks for the reminder of that option. However, I had tried doing
> that last year when we had a similar issue with ACPI and non-ACPI
> motherboards, and it didn’t work (it ended up crashing as I recall).
> My theory at the time was that there were registry or other
> configuration settings that were still dependant on the type of HAL,
> so one couldn’t use the /HAL= bios.ini switch to force a different
> type of HAL. (And that the option was really only useful for
> checked mode.)
>
> In fact, the seemingly equivalent of editing the disk offline and
> putting the correct HAL.DLL on there also doesn’t work and crashes.
> However, if one then reinstalls (not repairs) Windows from the
> install disk to the edited disk, it will correct whatever problem
> there was. (Oddly enough, though, the reinstall without putting the
> correct HAL on there first does NOT put the correct HAL on there.)
> I did go through that process this time again, so I know I’m right
> on that point.
>
> I’ll try the /HAL= again, but do you really think that the /HAL=
> switch would allow the use of a different type of HAL with respect
> to PIC/APIC and ACPI/non-ACPI?
>
> I’m using Win2003. However, I heard from Microsoft support last
> year that Vista and/or Win2008 do away with these issues by
> auto-detecting the HAL and NTOSKRNL types on bootup. I don’t know
> if they know enough to use the right one, or if they did away with
> the multiple versions altogether.
>
>
>

22

Again, Loren, your memory is slipping. These issues affect
single-processor and multi-processor installations. Taed isn’t asking
for multi-processor support (or at least he hasn’t mentioned it yet.)

  • Jake Oshins

“Loren Wilton” wrote in message
news:xxxxx@ntdev…
>> I’ll try the /HAL= again, but do you really think that the /HAL=
>> switch
>
> It won’t work. As best I recall, as well as picking the HAL, it
> either picks a matching kernel or applies assorted patches to the
> kernel when loading apic. You can’t just change the HAL at that
> point, you have to at least change the kernel also, and I seem to
> recall that was iffy. Much easier to reinstall from scratch.
>
> Loren
>
>
>

23

> Vista would enable the APIC without a re-installation, but XP will stick with

whichever interrupt controller the image was created with.

This fully explains the contradictions between Don’s post, on one hand, and Loren’s and mine on another - apparently, Don just did it on Vista, so it worked. However, I tried it around 3 years ago on XP, so it did not…

Anton Bassov

24

> Loren, you’re acronyms are getting confused. The “bad BIOS” list was for

broken ACPI BIOSes, not broken APIC BIOSes.

Argh. Yea, I do that with those two all the time. Have to check every time
I type one which one I actually typed. In this case though it appears to
have been more failing memory than mistyping. :frowning:

Loren

25

> The purpose of BIOS is just booting the computer. Therefore, BIOS APIC
settings

are guaranteed to be in effect only before it transfers control to the OS -
once
APIC setting can be modified by anyone who runs at privilege level 0 (these
modifications don’t really have to be saved in CMOS, do they ), it is up to
the OS
to decide whether it wants to make use of APIC or whether it wants to disable
it
and run in PIC mode.

Yes, but Windows tries to avoid such modifications as much as possible.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

26

“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> You don’t say in this message which version of Windows you’re dealing
> with, so I’ll assume you’re talking about XP.

It’s Windows Server 2003.

> Your PIC-based image will run on the motherboard with an APIC (as long
> as the BIOS is well-formed.) Vista would enable the APIC without a
> re-installation, but XP will stick with whichever interrupt controller
> the image was created with.

Based on the hang of my PIC-based image on my APIC motherboard, it’s clear
that Win2003 isn’t happy with the mis-match. (It’s an Award BIOS, so I
assume it’s “well-formed”.)

Your comment about Vista matches what I was told last year by Microsoft
support when dealing with the same issue with ACPI.

Thanks!

27

wrote in message news:xxxxx@ntdev…
> Are you saying that your software has a chance to run before the OS (or
setup program) even gets loaded???

Ignore my software on the disk. I’m just trying to create a Windows-only
disk image that will boot fine on either a PIC-based or APIC-based
motherboard. Think of it as if I have one hard drive that I want to boot in
either my home PIC-based system or in my work APIC-based system.

Thanks!

28

> Ignore my software on the disk. I’m just trying to create a Windows-only disk image

that will boot fine on either a PIC-based or APIC-based motherboard.

Actually, I don’t see any reason why your software should be ignored. As we have already established, there is no generic solution to your problem (i.e. your success depends on whether BIOS allows disabling APIC, as well as on Windows version). However, if your software gets loaded before Windows, you have all chances to develop a generic solution that is going to work everywhere, because you are in full control of everything…

Anton Bassov

29

Anton, I think what this guy has is something like an industrial touchscreen
display panel. A lot of these are full PCs about the size of your average
laptop power brick embedded in the back of a rackmount 14" monitor about 3"
thick.

He may not even have any drivers of his own. If he does, they are probably
things like a simple serial to mouse driver to handle the touchscreen, and
that may even be from a 3rd party OEM, not his.

What he probably has is a full-screen app that begins on startup and
displays pretty graphs and text and the like on the monitor panel by
creating mostly custom GUI gadgets, and then sending messages back to some
remote device over TCPIP or serial.

So this isn’t really about “the driver”. There may not be one. This is
about “the packaged app plus OS” that will be burned to the flash drive in
the display panel (or whatever it is he builds). The guy probably has to
support tens or hundreds of thousands of these things in the field, run
mostly by mechanics in industrial plants that have never seen a computer.
When they report a Windows crash message or other error, he needs to debug
it based on virtually no data. There isn’t going to be a dump to analyze,
he gets what the mechanic happened to remember from the screen before it
rebooted. If he has two different build images, *AND NO WAY TO TELL WHICH
IS USED*, it is going to make his life just a little mroe difficult, don’t
you think?

* The only way to tell the build images apart would probably be to give the
whole touchscreen a new model number. This means a lot of marketing
collateral changes, and real problems in dealing with government contracts,
since they may not accept a new model number in place of one previously
ordered.

Just my 4 cents…

Loren

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Sunday, December 09, 2007 7:47 AM
Subject: RE:[ntdev] Is there a way to put Windows in PIC-mode instead of
APIC-mode?

>> Ignore my software on the disk. I’m just trying to create a Windows-only
>> disk image
>> that will boot fine on either a PIC-based or APIC-based motherboard.
>
> Actually, I don’t see any reason why your software should be ignored. As
> we have already established, there is no generic solution to your problem
> (i.e. your success depends on whether BIOS allows disabling APIC, as well
> as on Windows version). However, if your software gets loaded before
> Windows, you have all chances to develop a generic solution that is going
> to work everywhere, because you are in full control of everything…
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

30

Loren,

My idea here is exactly to avoid the scenario that you have mentioned, i.e. avoid building separate images. If his on-disk (or embedded in FLASH) software gets loaded before Windows,
it can detect APIC presence with CPUID, and if it is present, disable it via IA32_APIC_BASE MSR before transferring control to Windows. If you disable APIC via IA32_APIC_BASE MSR, it is impossible to re-enable it before CPU reset (although you can re-enable APIC that was disabled via spurious interrupt vector register without resetting the CPU). However, CPU with local APIC disabled via IA32_APIC_BASE MSR is functionally equivalent to the one that just does not support APIC. Therefore, Windows installation with PIC HAL will work perfectly well on the machine with his embedded software.

Anton Bassov

31

Sure enough, /HAL= worked fine when switching between the PIC and APIC
systems with the same image. It actually ends up copying the specified
image to HAL.DLL, so the /HAL= option does not need to be specified on
future boots (but needs to be specified again with the old HAL image to go
back to the original). It even changed the string on the “Computer” device
in Device Manager.

So, since that seems to be the only change needed, I could have the image
deploying software change the boot.ini after it finishes deploying, based on
the CPUID instruction that Anton Bassov pointed out for easily detecting PIC
versus APIC.

Thanks so much to all – this gives me a workable solution if the BIOS
enhancement (to add an option for disabling APIC) doesn’t occur.

“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> Switching between ACPI and non-ACPI has system-wide consequences.
> Switching between PIC and APIC affects only the interrupt controller.
> I doubt that you’ll have a problem.
>
> - Jake Oshins
>
>
> “Taed Wynnell” wrote in message
> news:xxxxx@ntdev…
> > “Don Burn” wrote in message news:xxxxx@ntdev…
> >> if you are asking how to put the same disk image of an
> >> embedded type system on both the old system and the apic system,
> >> then you might look at the boot.ini option /HAL= This will allow
> >> you to specify the apic HAL as boot.ini option.
> >
> > Thanks for the reminder of that option. However, I had tried doing
> > that last year when we had a similar issue with ACPI and non-ACPI
> > motherboards, and it didn’t work (it ended up crashing as I recall).
> > My theory at the time was that there were registry or other
> > configuration settings that were still dependant on the type of HAL,
> > so one couldn’t use the /HAL= bios.ini switch to force a different
> > type of HAL. (And that the option was really only useful for
> > checked mode.)
> >
> > In fact, the seemingly equivalent of editing the disk offline and
> > putting the correct HAL.DLL on there also doesn’t work and crashes.
> > However, if one then reinstalls (not repairs) Windows from the
> > install disk to the edited disk, it will correct whatever problem
> > there was. (Oddly enough, though, the reinstall without putting the
> > correct HAL on there first does NOT put the correct HAL on there.)
> > I did go through that process this time again, so I know I’m right
> > on that point.
> >
> > I’ll try the /HAL= again, but do you really think that the /HAL=
> > switch would allow the use of a different type of HAL with respect
> > to PIC/APIC and ACPI/non-ACPI?
> >
> > I’m using Win2003. However, I heard from Microsoft support last
> > year that Vista and/or Win2008 do away with these issues by
> > auto-detecting the HAL and NTOSKRNL types on bootup. I don’t know
> > if they know enough to use the right one, or if they did away with
> > the multiple versions altogether.
> >
> >
> >
>
>

32

> the CPUID instruction that Anton Bassov pointed out for easily detecting PIC

versus APIC.

Even if CPU has APIC (“local APIC”) - this does not mean the MB has one (“IO
APIC”).

Probably CPUID is a bad idea of checking for IO APIC presense.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

33

> Probably CPUID is a bad idea of checking for IO APIC presense.

Well, you could look for the MPS table and walk that. For that matter,
while I don’t recall for sure, it might be that mere presence of an MPS
table would be enough to indicate that a usable APIC setup was present. Of
course, it might be bypassed by the BIOS. Don’t recall that I ever looked
at what the bits were in an MPS table on a system with the APIC disabled.

Loren

34

Taed,

Sorry to be late here. You also need to be aware of the kernel you’re loading. For 32 bit Server 2003 there are 4 kernels, with the dimensions of the matrix being uniprocessor vs multiprocessor and PAE mode vs not. The PIC HALs are only compatible with the uniprocessor kernels. The APIC HALs are compatible with all kernels. If your image starts out with the multiprocessor kernel installed, and you load the HAL using /HAL=, you’ll crash. I suspect this is what happened to you in earlier tests.

/detecthal is a boot option that will autodetect the capabilities of your platform and load the proper kernel and HAL. It’ll therefore ensure that they match. You should give this a whirl as well.

Dave

35

Maxim,

Even if CPU has APIC (“local APIC”) - this does not mean the MB has one (“IO APIC”).

Correct. However, in this context it just does not matter - after all, our objective is to disable APIC, rather than to make use of it…

Probably CPUID is a bad idea of checking for IO APIC presense.

*In this context* CPUID is just fine - the only reason why we issue it here is to check whether we should write to IA32_APIC_BASE MSR in order to disable it. As long as CPU does not support APIC (a CPU with local APIC disabled via IA32_APIC_BASE MSR is functionally equivalent to the one that just does not support APIC), the system will be unable to make any use of IOAPIC anyway, so that it will have no option, apart from configuring IOAPIC as 8259A and running in PIC mode…

Therefore, your observation is of no importance for us, although it is of crucial importance for setup program when it checks whether APIC HAL can get installed, because APIC HAL is not going to work unless both CPU and MB support APIC…

Anton Bassov

36

Ack. /detecthal is only available on Vista. Sorry to mislead you. The basic caveat still applies, though - you have to match your kernel to your HAL. /KERNEL= is available on Server 2003 for this purpose.

Dave

37

Anton, Windows doesn’t look at the IA32_APIC_BASE MSR. It looks at
the BIOS tables that tell it whether to try to use an APIC. This is
because the APIC code in Windows pre-dates that MSR.

If you were to do what you’re suggesting, you’d find that Windows
would still try to use the APIC because the BIOS said so and then it
would crash (bugcheck 0x79) because the APIC wouldn’t work.

  • Jake

wrote in message news:xxxxx@ntdev…
> Maxim,
>
>> Even if CPU has APIC (“local APIC”) - this does not mean the MB has
>> one (“IO APIC”).
>
> Correct. However, in this context it just does not matter - after
> all, our objective is to disable APIC, rather than to make use of
> it…
>
>> Probably CPUID is a bad idea of checking for IO APIC presense.
>
> In this context CPUID is just fine - the only reason why we issue
> it here is to check whether we should write to IA32_APIC_BASE MSR
> in order to disable it. As long as CPU does not support APIC (a
> CPU with local APIC disabled via IA32_APIC_BASE MSR is functionally
> equivalent to the one that just does not support APIC), the system
> will be unable to make any use of IOAPIC anyway, so that it will
> have no option, apart from configuring IOAPIC as 8259A and running
> in PIC mode…
>
> Therefore, your observation is of no importance for us, although it
> is of crucial importance for setup program when it checks whether
> APIC HAL can get installed, because APIC HAL is not going to work
> unless both CPU and MB support APIC…
>
> Anton Bassov
>
>
>

38

Jake,

Anton, Windows doesn’t look at the IA32_APIC_BASE MSR. It looks at the BIOS
tables that tell it whether to try to use an APIC. This is because the APIC code
in Windows pre-dates that MSR.

If you were to do what you’re suggesting, you’d find that Windows would still
try to use the APIC…

Please read carefully all posts on this thread - the OP asks how to make *pre-Vista* Windows installation with *PIC* HAL work on the machine with APIC. Therefore, apparently, it is not going to check either APIC via IA32_APIC_BASE MSR or BIOS tables, simply because it is configured to run in PIC mode, no matter what and no matter how. What we are trying to do here is just to make sure that the hardware state corresponds to the one PIC HAL is designed to work on.
Therefore, you post applies only to Vista, because, as you said, it chooses HAL version dynamically.

In any case, you should think of my proposal as of a direction to work in, rather than of a precise final solution.(although the step that I have mentioned is going to part of a final solution)…

Anton Bassov