tyler.durden
/
kernel
mirror of https://github.com/FDOS/kernel.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

potential fix for spurious near fnodes!=0 msg with shsufdrv and >2 near fnodes in use for bug 1879 

git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/branches/UNSTABLE@1160 6ac86273-5f31-0410-b378-82cca8765d1b
This commit is contained in:
Kenneth J Davis 2005-11-27 08:20:33 +00:00
parent 407014d5fd
commit f44334f0e2
1 changed files with 19 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
kernel/inthndlr.c
View File

@ -434,10 +434,26 @@ dispatch:
}
/* Clear carry by default for these functions */
/* see PATCH TE 5 jul 04 explanation at end */
if (ErrorMode && lr.AH > 0x0c && lr.AH != 0x30 && lr.AH != 0x59)
/* We force clear the near fnodes,
On a normal int21h entry these are unused, so should already
be clear, thus this code is effectively redundant.
However when re-entering int21h, such as a device driver
(e.g. shsufdrv), the fnodes may contain the values of the
in progress call; as long as the driver/tsr causing the
reentrancey saves and restores the SDA across the call then
any changes we do (ie clearing these) should go unnoticed
and if the cause of the reentrancy does not save/restore the
SDA then the caller should expected the unexpected.
Failure to do this will at a minimal result in the extra
output indicating fnodes not 0 (and possibly clearing at end
of call) when the re-entered int21h call completes, but could
result in the re-entered call to fail with no free near fnodes
if both are already in use by the original int21h call (?bug 1879?).
See also PATCH TE 5 jul 04 explanation at end
*/
if (/*ErrorMode && */lr.AH > 0x0c && lr.AH != 0x30 && lr.AH != 0x59)
{
ErrorMode = 0;
/*if (ErrorMode)*/ ErrorMode = 0;
fnode[0].f_count = 0; /* don't panic - THEY ARE unused !! */
fnode[1].f_count = 0;
}