X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Date: Thu, 16 Dec 2004 06:48:32 +0200
From: "Eli Zaretskii" <eliz AT gnu DOT org>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp AT delorie DOT com
Message-ID: <01c4e32a$Blat.v2.2.2$a3b07a80@zahav.net.il>
Content-Transfer-Encoding: 7BIT
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 2.2.2
In-reply-to: <20041215234645.6d15ae95.lijon@kymatica.com> (message from
	Jonatan Liljedahl on Wed, 15 Dec 2004 23:46:45 -0200)
Subject: Re: Problems with timer interrupt chaining and SmartDrv
References: <20041215011234 DOT 44376f01 DOT lijon AT kymatica DOT com>
	<01c4e2e9$Blat.v2.2.2$7ba22de0 AT zahav DOT net DOT il> <20041215234645 DOT 6d15ae95 DOT lijon AT kymatica DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Wed, 15 Dec 2004 23:46:45 -0200
> From: Jonatan Liljedahl <lijon AT kymatica DOT com>
> 
> > Does the problem go away if you hook the timer interrupt, but do not
> > reprogram the timer to a higher frequency?
> 
> I just tried this: I leave the PIT alone and I chain to the original
> handler at the end of my own handler every time. Yes, the problem goes
> away!

Then I'd suspect that with a reprogrammed PIT, the next timer
interrupt hits you while SmartDRV is still writing data to disk, and
that causes the machine to hang.  Perhaps your handler is invoked
again, for example.  Yes, I saw that you called `disable', but as you
might know, this not necessarily actually disables the hardware
interrupt from happening.  I'd suggest to check whether the interrupt
happens while the previous one is still being processed.

> Why would the original handler (where smartdrv lives) care about how
> often my own handler is called??

Because it is interrupted, and the interrupt handler switches to
protected mode?

> By the way, I have also tried to disable interrupts while writing to
> disc, and to flush smartdrv before enabling interrupts again (assuming
> that sync() does signal to smartdrv to flush it's cache, as it says in
> the info).

`sync' does force SmartDRV tp flush its buffers, just look at the
library sources, and ou will see.

> > If everything else fails, you can include in your program's
> > initialization routine code to disable SmartDRV automatically.  Ralf
> > Brown's Interrupt List documents the API exported by SmartDRV via
> > interrupt 2Fh.
> 
> Yes, that would be OK.

I meant to disable the write-behind mode, not disable SmartDRV
entirely, btw.

> Does it work under Windows too?

I don't know, maybe.  Do you have similar problems on Windows, and if
so, what version(s) of Windows?