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: http://www.coli.uni-saarland.de/~eric/stuff/soft/lbacache-2006aug31.zip 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. Eric