Intravision/reactos
1
0
Fork 0
mirror of https://github.com/reactos/reactos.git synced 2024-06-01 10:11:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

[HALX86] Fix the "ASSERT(j < 32);" problem in HalpStoreAndClearIopm() encountered from time to time.

Browse source 
CORE-11921 CORE-13715

(Regression introduced by commit 2e1b82cf, r44841.)

In some cases the number of valid (!= 0xFFFF) entries in the IOPM can be
larger than the assumed size (32) of the entries cache. The maximum
possible number of entries is equal to IOPM_SIZE / sizeof(USHORT).

A way to reproduce the problem is as follows: start ReactOS in debugging
mode using '/DEBUG /DEBUGPORT=SCREEN' . Then manage to break into the
debugger exactly during the execution of Ke386CallBios() triggered by
display initialization (for example in my case, while a video driver was
being initialized via the HwInitialize() call done by videoport inside
IntVideoPortDispatchOpen() ).

When this happens, a "concurrent" execution between Ke386CallBios() and
the HAL function HalpStoreAndClearIopm() takes place. This is due to the
fact that when entering the debugger in SCREEN mode, the following
call-chain holds:
InbvResetDisplay() -> VidResetDisplay() -> HalResetDisplay() ->
HalpBiosDisplayReset() -> HalpSetupRealModeIoPermissionsAndTask() ->
HalpStoreAndClearIopm().

However, the code of Ke386CallBios() has reset the IOPM contents with
all zeroes instead of 0xFFFF, and this triggers the caching of all the
entries of the IOPM by HalpStoreAndClearIopm(), whose number is greater
than the wrongly assumed number of '32'.

As Thomas explained to me, "Windows supports [the maximum number of IOPM entries],
it just makes a full copy of the table instead of this indexed partial copy."

And I agree that this overengineered so-called "optimization" committed
in 2e1b82cf contributed in introducing an unnecessary bug and making the
code less clear. Also it makes the IOPM cache larger than the necessary
size by twice as much. Finally, Ke386CallBios() also caches IOPM entries
before doing a 16-bit call, and obviously uses the more straightforward
way of doing a direct copy of the IOPM table (using RtlCopyMemory()).

I wonder what kind of "optimization" this tried to achieve, knowing that
we are not doing like thousands of 32->16bit BIOS interrupt calls per second
in ReactOS...
This commit is contained in:
Hermès Bélusca-Maïto 2019-11-24 22:58:12 +01:00
parent 00cb464d9d
commit 5887b17005
No known key found for this signature in database
GPG key ID: 3B2539C65E7B93D0
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
hal/halx86/generic/bios.c
View file

@ -41,7 +41,7 @@ USHORT HalpSavedTss;
//
USHORT HalpSavedIopmBase;
PUSHORT HalpSavedIoMap;
USHORT HalpSavedIoMapData[32][2];
USHORT HalpSavedIoMapData[IOPM_SIZE / sizeof(USHORT)][2];
ULONG HalpSavedIoMapEntries;
/* Where the protected mode stack is */
@ -400,7 +400,7 @@ HalpStoreAndClearIopm(VOID)
//
// Save it
//
ASSERT(j < 32);
ASSERT(j < IOPM_SIZE / sizeof(USHORT));
HalpSavedIoMapData[j][0] = i;
HalpSavedIoMapData[j][1] = *Entry;
j++;