From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stas Sergeev Subject: Re: bug in pic_prot.diff (was Re: Bootfile) Date: Thu, 06 Feb 2003 13:03:11 +0300 Sender: linux-msdos-owner@vger.kernel.org Message-ID: <3E4232DF.60603@yahoo.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-msdos@vger.kernel.org Hello. Bart Oldeman wrote: >> locks up. That looks like a problem. The attached patch fixes it: now >> setting $_pic_watchdog to any reasonable value (within a range of 1-100 >> approx) will work for that game. > Hmm why do you now need to enable the hack in the first place where it > was unnecessary before? That doesn't sound like a good thing to me. Yes, but this is not as straightforward. There was a big discussion about a year ago in a (unfortunately not archived these days) dosemu-devel@ about that issue, where the several possibilities were discussed: Eric was standing for the time-based measurements, which are, unfortunately, not reliable with the current timer precision. I was standing for the hlt- based protection and Larry at one point proposed to make that optional, which is now done. As I was a proponent of a hlt-based protection, I have made it by default, and optionally we can enable a time-based watchdog. The problem is that the both approaches are the hacks:( It was tested and proved (at least I hope so:) that the hlt-based approach satisfies a majority of apps out there, however some (counted by fingers) are still in need of a time-based approach. Before it was used a much weaker protection (also a hlt-based, but flawed), and many apps used to ocasionally crash. Now the behaveour is at least predictable and for the programs which can't get along with the current scheme there is an optional detour. Eric wanted the time-based approach to be enabled by default and Larry agreed but noted that this can potentially harm all the programs. I also think it can harm sometimes (esp. with the current state of an interrupt handling for DPMI!) that's why I decided to disable it by default. The choice here is as follows: either we want all the programs to work, but potentially unreliably, or we want to work reliably an absolute majority of progs, but some will not work at all, then the option. So when the option exists, the default value is not so important after all. We can set it to some large value by default if it is really necessary for the any noticeable amount of progs, but it really seems like it is not. Alternatively we can always track a timeouts and, in case $_pic_watchdog is disabled and the timeout is frightening, we throw an error message to hint the user to try enabling the option if he have a lock-up. >> However I have found my test-case for that problem screwed up by an >> XMS changes of 1.1.4.1. > i'll look at the XMS changes again to see if I missed something there. Would be great. Let me know in case you need a logs or a test-case.