How-to disable irq4 serial ints

How-to disable irq4 serial ints

[Hufnus]

I am forced to use a legacy assembler serial driver that handles a
special comm port device and preps data for a dos text gui.

Problem is, if the serial device on /dev/ttyS0 is receiving
data and generating ints, this serial servicing tsr crashes
during its init.  But if the port is quiet it starts fine.

So, I ask for suggestions on ways to temporarily disable irq 4
interrupts from happening, until after this tsr starts ???

Thanks in advance
TonyB

--
  __      __  _     I N C.               http://www.sysdev.org
/ __|\\// __||  \  __   __          /         tonyb@sysdev.org
\__ \ \/\__ \||)|/ O_)\/ /        \/  System Tools / Utilities
|___/ || ___/|_ /\___|\_/        WIntel / Linux Device Drivers

Re: How-to disable irq4 serial ints

[Hufnus]

On Thu, 9 Jun 2005 19:49:28 -0800
Hufnus <tonyb@thekrnl.sysdev.org> wrote:

> 
> So, I ask for suggestions on ways to temporarily disable irq 4
> interrupts from happening, until after this tsr starts ???

Basically I was wondering, if masking the PIC with a 0x04 by doing
I/O to port 0x21 would work in dosemu emulation or if there is a
better way to do this?

TonyB

--
  __      __  _     I N C.               http://www.sysdev.org
/ __|\\// __||  \  __   __          /         tonyb@sysdev.org
\__ \ \/\__ \||)|/ O_)\/ /        \/  System Tools / Utilities
|___/ || ___/|_ /\___|\_/        WIntel / Linux Device Drivers

Re: How-to disable irq4 serial ints

[Stas Sergeev]

Hello.

Hufnus wrote:
> Problem is, if the serial device on /dev/ttyS0 is receiving
> data and generating ints, this serial servicing tsr crashes
> during its init.
So finally you did what I suggested,
and located the broken DOS program
instead of presuming the bugs in dosemu?
Good work, keep it that way:)

> Basically I was wondering, if masking the PIC with a 0x04 by doing
> I/O to port 0x21 would work in dosemu emulation or if there is a
> better way to do this?
This *of course* works under dosemu.
But this may be irrelevant. Because
unless I am seriously mistaken, the
DOS doesn't unmask the serial port
IRQs by default. So if this is the
problem, you have to search further
and locate another broken program of
yours that unmasks the IRQ and forgets
to mask it back before exit.

Re: How-to disable irq4 serial ints

[Hufnus]

On Fri, 10 Jun 2005 19:38:42 +0400
Stas Sergeev <stsp@aknet.ru> wrote:

> Hufnus wrote:
> > Problem is, if the serial device on /dev/ttyS0 is receiving
> > data and generating ints, this serial servicing tsr crashes
> > during its init.
> So finally you did what I suggested,
> and located the broken DOS program
> instead of presuming the bugs in dosemu?

I am afraid that is not exactly true!  It is related
to dosemu not being 100% DOS compatible, when handling these
programs of ours.  Because they have been un-crashable for the
20 years that they have been shipped to customers on vanilla
Dos 3.2 - 6.2

I dont see a fault with Dosemu handling of serial, execept when
we mix it with this Quick Basic/asm Serial I/O TSR combination!

It only crashes Dosemu on a Dosemu restart, if the serial device is
left ON, sending I/O at 1200 baud.

It does not crash when Dosemu starts or when the asm Serial I/O TSR
installs. It crashes on the initial requests between the Quick Basic
Gui trying to start getting serial data events.

Its a hard debug, but we are slowly narrowing THE WHAT is happening,
so it can be resolved, whatever it is...

But it is related to Dosemu 1.2.0 -> 1.3.2, with MsDos 5.0 files,
with our 2 programs, not getting along when Dosemu starts while
serial events are takin place.

The hole issue started when we discovered that: after about 20 or
30 days of continuous running the dosemu clock date/time would get
corrupted. So we started restarting Dosemu about once every 10 days
to get around the corruption.

It is still NOT clear what is at fault,
but it works with real DOS, but that is a
different environment.

Thanks
TonyB

> > Basically I was wondering, if masking the PIC with a 0x04 by
> > doing I/O to port 0x21 would work in dosemu emulation or if there
> > is a better way to do this?
> This *of course* works under dosemu.
> But this may be irrelevant. Because
> unless I am seriously mistaken, the
> DOS doesn't unmask the serial port
> IRQs by default. So if this is the
> problem, you have to search further
> and locate another broken program of
> yours that unmasks the IRQ and forgets
> to mask it back before exit.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-msdos" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


--
  __      __  _     I N C.               http://www.sysdev.org
/ __|\\// __||  \  __   __          /         tonyb@sysdev.org
\__ \ \/\__ \||)|/ O_)\/ /        \/  System Tools / Utilities
|___/ || ___/|_ /\___|\_/        WIntel / Linux Device Drivers

Re: How-to disable irq4 serial ints

[Stas Sergeev]

Hello.

Hufnus wrote:
> I am afraid that is not exactly true!  It is related
> to dosemu not being 100% DOS compatible, when handling these
> programs of ours.  Because they have been un-crashable for the
> 20 years that they have been shipped to customers on vanilla
> Dos 3.2 - 6.2
This still doesn't mean your progs
are bug-free. Dosemu is not 100%
compatible mostly in the area of
the hardware timings. For example,
you program may assume that after
it unmasks the IRQ on PIC, it can
still execute a bunch of instructions
before the interrupt is received,
but under dosemu the interrupt can
happen immediately because it doesn't
properly emulate the delays of the
hardware. So you can be interrupted
immediately after you did the "out"
instruction that unmasks an IRQ.
This may be called a bug in dosemu,
but the properly written programs
should not rely on such a things
(fortunately most of them do not).

> The hole issue started when we discovered that: after about 20 or
> 30 days of continuous running the dosemu clock date/time would get
> corrupted.
This really sounds like a bug in
dosemu, but unfortunately most people
do not have a resources for running
such a long tests. And since fixing
this will fix also another problem of
yours, it would be nice if you track
this one down on dosemu side:)