Hi all,

after more than a year without updates, I uploaded a new
version of LBACACHE (includes TICKLE). This semi-critical
update fixes a hang which could happen with FDAPM. Thanks
to Arkady for explaining the bug background and solution.

You can get the updated version at:


The FREEDOS-USER part of this mail ends here. For discussion
about the rest of this mail, please use the FREEDOS-DEVEL list.

Thanks for testing, and enjoy the update :-). Eric

Technical part... Other programs which have SIMILAR BUGS are:

- fdxms family: int 15 forces interrupts to enabled (no big problem)

- doslfn: findfirst/findnext forces interrupts to enabled (same...)

- DISPLAY: several interrupt functions can force interrupts to
   disabled as far as I can tell. this could make DOS freeze.

- FDSHIELD: several shield functions can force interrupts to
   disabled, which can also cause a freeze. I plan to update
   fdshield soon, but I would like to know if anybody actually
   does use it :-). It is a TSR for selective write protection
   and other "malware impact reduction" things like deliberately
   freezing DOS when new drivers or TSRs show up unexpectedly.

- KERNEL: int 2f stubs for Win3 and network drive (and cdrom?)
   interaction can force interrupts to disabled. This might
   freeze DOS when you start Win3 or shsucdx or network drive
   drivers, but nobody actually ran into problems here afair...?
   Arkady has a patch for kernels 2036 and 2037, which will
   probably be made part of the current kernels soon. Affected
   int 2f functions are 11xx and 16xx.

Technical details: Cause of the hang is using retf +2
instead of iret, which means that the flags of the
caller are replaced by the flags of the lbacache /
tickle driver. The new code uses iret and manually
changes only those flags of the caller (on the stack)
which it is actually supposed to change.

The hang only happens if:
- you have emm386 loaded, recent version of it
- you have LBACACHE loaded, normally with the FLOP option on
- you have TICKLE loaded
- you try to do something with FDAPM which involves disk
   cache flushing (commands: flush, poweroff, suspend, ...)

In this context, interrupts are disabled inside interrupts,
and when tickle returns to the caller, interrupts were still
disabled, which made the delay countdown in fdapm flush code
hang. Older emm386 versions do not disable interrupts in
interrupts, and somehow the bug in tickle does not trigger
either if emm386 is not loaded at all... Lbacache contains
a similar bug (not restoring the interrupt enable state on
returning to the caller) but that somehow never triggered
a hang. Maybe because other disk drivers actually enabled
interrupts and because lbacache internally calls those
disk drivers?

In either case, lbacache now PRESERVES whichever interrupt
enable / disable state the caller uses. When it returns,
it ONLY sets or clears the carry flag but does not change
any other caller flag state any more. Neither does the new
version of tickle.


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Freedos-user mailing list

Reply via email to