Programming the parallel port irq on a shared irq?
unruh
unshared parallel port for years. It uses an edge triggered
(IO-APIC-edge) unshared irq. One one of my machines I have no onboard
parallel port and so had to buy a card which contains one parallel and
two serial ports. The irq in this case is a shared irq -- irq 0x11 with
a IO-APIC-fasteoi. However, this does not work, since there seems no way
with the parallel port to shut off the irq once the irq has been
serviced.
The nINTA is tied to the nACK line, and, I cannot switch it off (or
rather cannot switch it to 1). as it is tied to the nACK, and that is
delivered by the gps timing line, and cannot be changed by the computer
(it goes on for 100ms ) What happens is that I get an irq storm-- every
3 ms a new irq comes through, which is hardly what I want happening.
I am clearly missing something. Does anyone have any hints or references
I can look at? I have tried googling, but all I find is discussions of
the irq behaviour on an unshared edge triggered, not a shared, level
triggered ( which is what I assume that fasteoi is) parallel port.
The parallel card is a Moschip MCS9835 card-- 2 serial, one parallel,
all sharing one fasteoi interrupt (0x11)
lspci -v gives
04:03.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O
Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic 1P2S
Flags: medium devsel, IRQ 11
I/O ports at 1030 [size=8]
I/O ports at 1028 [size=8]
I/O ports at 1020 [size=8]
I/O ports at 1018 [size=8]
I/O ports at 1010 [size=8]
I/O ports at 1000 [size=16]
----------------------------------------
The first two base addresses are serial, the third is the parallel base
address. I have no idea what the other three are. Usually it is said
that the extended ports for the parallel port are at 0x400 higher than
the base (1020) which does not seem to make sense with the above
addresses.
Reading the MOSCHIP specs for this system gives me no clue.
Note that I do NOT want to use the parport Linux parallel port driver,
since timing is critical, and want the irq to be time stamped
immediately the irq comes through, not after some delay while the irq
comes through, the parport driver is notified and it triggers a polling
select function or something like that-- that takes time before the
timestamp is applied.
If there is some other newsgroup where I should take this, please let me
know.
The Natural Philosopher
> I wrote a program using the parallel port irq, and ran it on a single
> unshared parallel port for years. It uses an edge triggered
> (IO-APIC-edge) unshared irq. One one of my machines I have no onboard
> parallel port and so had to buy a card which contains one parallel and
> two serial ports. The irq in this case is a shared irq -- irq 0x11 with
> a IO-APIC-fasteoi. However, this does not work, since there seems no way
> with the parallel port to shut off the irq once the irq has been
> serviced.
? if its edge triggered, its gone before you even service it.
> The nINTA is tied to the nACK line, and, I cannot switch it off (or
> rather cannot switch it to 1). as it is tied to the nACK, and that is
> delivered by the gps timing line, and cannot be changed by the computer
> (it goes on for 100ms ) What happens is that I get an irq storm-- every
> 3 ms a new irq comes through, which is hardly what I want happening.
>
> I am clearly missing something. Does anyone have any hints or references
> I can look at? I have tried googling, but all I find is discussions of
> the irq behaviour on an unshared edge triggered, not a shared, level
> triggered ( which is what I assume that fasteoi is) parallel port.
>
why not go for level triggered, assuming you can reset the edge in the ISR?
understood.
>
> If there is some other newsgroup where I should take this, please let me
> know.
>
>
its been a long time BUT in the case where you have several possible
causes of the same interrupt, in general you need to examine each source
in turn, and tell it to shut up. After all it may be interrupting
because its got an empty write buffer. Unless you tell it not to.
Assuming you are reading data off it, not writing data to it.
Your best bet is to ID the actual chipset and try and get specs on it.
unruh
> unruh wrote:
>> I wrote a program using the parallel port irq, and ran it on a single
>> unshared parallel port for years. It uses an edge triggered
>> (IO-APIC-edge) unshared irq. One one of my machines I have no onboard
>> parallel port and so had to buy a card which contains one parallel and
>> two serial ports. The irq in this case is a shared irq -- irq 0x11 with
>> a IO-APIC-fasteoi. However, this does not work, since there seems no way
>> with the parallel port to shut off the irq once the irq has been
>> serviced.
>
> ? if its edge triggered, its gone before you even service it.
No, it was fine. The edge is obviously gone, but the ACK is at its high
level which you can check to see that the interrupt occured. And the
interrupt does not reoccur since the edge is gone. If you level trigger,
then the level stays high (I cannot reset the level on the ACK pin of
the parallel port-- that comes from the GPS)-- at least I cannot figure
out how to do it. I have thought of switching off interrupts on the
parallel port for say 300ms, until the level should have gone down
again. But that really sounds like a kludge. And I would not want to put
a wait into the itnerrupt service routine. I would have to install a
timer (eg select) to tell me when to switch the interrupt back on. But
my worry would be that doing this in an interrupt service routine sounds
dangerous.
>
>
>> The nINTA is tied to the nACK line, and, I cannot switch it off (or
>> rather cannot switch it to 1). as it is tied to the nACK, and that is
>> delivered by the gps timing line, and cannot be changed by the computer
>> (it goes on for 100ms ) What happens is that I get an irq storm-- every
>> 3 ms a new irq comes through, which is hardly what I want happening.
>>
>> I am clearly missing something. Does anyone have any hints or references
>> I can look at? I have tried googling, but all I find is discussions of
>> the irq behaviour on an unshared edge triggered, not a shared, level
>> triggered ( which is what I assume that fasteoi is) parallel port.
>>
>
> why not go for level triggered, assuming you can reset the edge in the ISR?
That is the problem, I do not know how to reset the edge for a parallel
port.
All I am using is the parallel interrupt line. I am not reading or
writing anything. GPS->ACK->interrupt service routine time stamps the
start of the ACK transition->timestamps fed to a /dev file for reading.
It is too bad that the computers do not have a few interrupt lines whose
only purpose is to trigger an interrupt. But I guess that is such a low
useage item. The problem today is that all of the inputs, except usb (
which does not have interrupts as far as I can see) are disappearing.
Noone uses parallel port printers anymore, and even serial ports are
becoming rare.
> Your best bet is to ID the actual chipset and try and get specs on it.
Yup, that is that MOSCHIP MCS9835, but the specs are not terribly
enlightening, at least to me. It talks about PS2 mode causing and edge
triggering latchup, but that does not seem to work on my system. And I
have not been able to find the Parallel port PS2 specs anywhere on the
web.
The Natural Philosopher
I used to have a book...from way back when..threw it away..generally
reading some port should case it to stop interrupting.
unruh
Yes, that was what I thought, but experiment says it does not work. Of
course it could have been a defective product. Will have to try again
with another parallel card I guess.
>
>
>
David W. Hodgins
> I wrote a program using the parallel port irq, and ran it on a single
> unshared parallel port for years. It uses an edge triggered
> (IO-APIC-edge) unshared irq. One one of my machines I have no onboard
> parallel port and so had to buy a card which contains one parallel and
> two serial ports. The irq in this case is a shared irq -- irq 0x11 with
> a IO-APIC-fasteoi. However, this does not work, since there seems no way
According to http://www.xml.com/ldd/chapter/book/ch09.html#t6
you cannot use edge triggered interrupts with shared irq.
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
The Natural Philosopher
> On Mon, 28 Mar 2011 15:45:04 -0400, unruh
> <un...@wormhole.physics.ubc.ca> wrote:
>
>> I wrote a program using the parallel port irq, and ran it on a single
>> unshared parallel port for years. It uses an edge triggered
>> (IO-APIC-edge) unshared irq. One one of my machines I have no onboard
>> parallel port and so had to buy a card which contains one parallel and
>> two serial ports. The irq in this case is a shared irq -- irq 0x11 with
>> a IO-APIC-fasteoi. However, this does not work, since there seems no way
>
> According to http://www.xml.com/ldd/chapter/book/ch09.html#t6
> you cannot use edge triggered interrupts with shared irq.
>
Total redesign time?
> Regards, Dave Hodgins
>
Grant
>I wrote a program using the parallel port irq, and ran it on a single
>unshared parallel port for years. It uses an edge triggered
>(IO-APIC-edge) unshared irq. One one of my machines I have no onboard
>parallel port and so had to buy a card which contains one parallel and
>two serial ports. The irq in this case is a shared irq -- irq 0x11 with
>a IO-APIC-fasteoi. However, this does not work, since there seems no way
>with the parallel port to shut off the irq once the irq has been
>serviced.
For shared interrupts you set for level triggered and the ISR loops until
all shared interrupts are looked after and the line goes inactive again.
It's a pain, but the only way.
>The nINTA is tied to the nACK line, and, I cannot switch it off (or
>rather cannot switch it to 1). as it is tied to the nACK, and that is
>delivered by the gps timing line, and cannot be changed by the computer
>(it goes on for 100ms ) What happens is that I get an irq storm-- every
>3 ms a new irq comes through, which is hardly what I want happening.
>
>I am clearly missing something. Does anyone have any hints or references
>I can look at? I have tried googling, but all I find is discussions of
>the irq behaviour on an unshared edge triggered, not a shared, level
>triggered ( which is what I assume that fasteoi is) parallel port.
You're not polling all interrupt sources to fix them back to inactive
state before ISR returns.
>
>The parallel card is a Moschip MCS9835 card-- 2 serial, one parallel,
>all sharing one fasteoi interrupt (0x11)
Can't help with specific hardware, I'm talking about the software side.
Don't know, it's a hardware thing, probably more like embedded controller
software, directly playing with the ports?
Grant.
>
Grant
>unruh wrote:
>> I wrote a program using the parallel port irq, and ran it on a single
>> unshared parallel port for years. It uses an edge triggered
>> (IO-APIC-edge) unshared irq. One one of my machines I have no onboard
>> parallel port and so had to buy a card which contains one parallel and
>> two serial ports. The irq in this case is a shared irq -- irq 0x11 with
>> a IO-APIC-fasteoi. However, this does not work, since there seems no way
>> with the parallel port to shut off the irq once the irq has been
>> serviced.
>
>? if its edge triggered, its gone before you even service it.
>
>
>> The nINTA is tied to the nACK line, and, I cannot switch it off (or
>> rather cannot switch it to 1). as it is tied to the nACK, and that is
>> delivered by the gps timing line, and cannot be changed by the computer
>> (it goes on for 100ms ) What happens is that I get an irq storm-- every
>> 3 ms a new irq comes through, which is hardly what I want happening.
>>
>> I am clearly missing something. Does anyone have any hints or references
>> I can look at? I have tried googling, but all I find is discussions of
>> the irq behaviour on an unshared edge triggered, not a shared, level
>> triggered ( which is what I assume that fasteoi is) parallel port.
>>
>
>why not go for level triggered, assuming you can reset the edge in the ISR?
Why not? Must! Only way to service shared IRQ is to poll each source until
the IRQ is satisfied. Can't do that with edge trigger.
Grant.
Mat Nieuwenhoven
<snip>
>The parallel card is a Moschip MCS9835 card-- 2 serial, one parallel,
>all sharing one fasteoi interrupt (0x11)
At least for chip MCS9865 Moschip has Linux drivers as compilable source on
their site. That chip looks very much like what you describe (2 serial, 1 LPT
port, plus extendable). The source could give you a clue.
Mat Nieuwenhoven
unruh
Unfortuantely that source code is only for the serial ports, not
parallel.
Under the 9835 all they say is
"Please refer Linux Installation Guide.
We are using Linux Standard Serial and Parallel Driver.
So it will work with all Linux Kernels."
and then teach you how to use lspci -v to determine the base port
numbers ( without doing it properly) and the irq. (as a learing
exprerience I discovered that lspci put everything out in hex withoug
saying so. Thus irq 11 means irq 17 in decimal. )
Unfortuantely the standard linux parport driver does not handle sharable
interrupts at all, except to bail out and poll the driver instead.
I am coming to the conclusion that the parallel port specs are such that
it is absolutely impossible to use shared interrupts with the
parallel port.
>
> Mat Nieuwenhoven
>
>
Klaatu
> Reading the MOSCHIP specs for this system gives me no clue.
>
Did you get the parallel port printer to work? I have a MOSCHIP 9815 (2
Parallel ports) going to /var/log and running "cat syslog | grep parport"
yields
Apr 10 09:45:04 phenom kernel: parport_pc 00:0a: reported by Plug and Play
ACPI
Apr 10 09:45:04 phenom kernel: parport0: PC-style at 0x378, irq 7
[PCSPP,TRISTATE]
Apr 10 09:45:04 phenom kernel: parport_pc 0000:03:06.0: PCI INT A -> GSI 20
(level, low) -> IRQ 20
Apr 10 09:45:04 phenom kernel: parport1: PC-style at 0xcf00 (0xce00), irq
20, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
Apr 10 09:45:04 phenom kernel: parport2: PC-style at 0xcd00 (0xcc00), irq
20, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
lspci -v yields
03:06.0 Communication controller: NetMos Technology PCI 9815 Multi-I/O
Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic 2P0S (2 port parallel adaptor)
Flags: medium devsel, IRQ 20
I/O ports at cf00 [size=8]
I/O ports at ce00 [size=8]
I/O ports at cd00 [size=8]
I/O ports at cc00 [size=8]
I/O ports at cb00 [size=8]
I/O ports at ca00 [size=16]
Kernel modules: parport_pc
Doing a /sbin/modprobe parport_pc io=0x378,0xcf00 irq=7,20 runs but no
printer is detected using any of the above ports.
The setup works in Windoz 7, same machine, so no hardware issue. Running
2010.2, PhenomIIx2 64 bit machine. Any ideas.
unruh
>>
>> Reading the MOSCHIP specs for this system gives me no clue.
>>
>
> Did you get the parallel port printer to work? I have a MOSCHIP 9815 (2
> Parallel ports) going to /var/log and running "cat syslog | grep parport"
> yields
>
> Apr 10 09:45:04 phenom kernel: parport_pc 00:0a: reported by Plug and Play
> ACPI
> Apr 10 09:45:04 phenom kernel: parport0: PC-style at 0x378, irq 7
> [PCSPP,TRISTATE]
> Apr 10 09:45:04 phenom kernel: parport_pc 0000:03:06.0: PCI INT A -> GSI 20
> (level, low) -> IRQ 20
> Apr 10 09:45:04 phenom kernel: parport1: PC-style at 0xcf00 (0xce00), irq
> 20, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
> Apr 10 09:45:04 phenom kernel: parport2: PC-style at 0xcd00 (0xcc00), irq
> 20, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
No I did not get the irq to work. I have come to the conclusion that
that parallel port interrupt cannot work on a shared (level rather than
edge) interrupt. There is no way to switch off the interrupt level on
the card, so the interrupts simply keep coming, once a microsecond or
so.
The linux parport driver simply reverts to polling, which is pretty
useless if one is using the port for timing purposes.
>
> lspci -v yields
>
> 03:06.0 Communication controller: NetMos Technology PCI 9815 Multi-I/O
> Controller (rev 01)
> Subsystem: LSI Logic / Symbios Logic 2P0S (2 port parallel adaptor)
> Flags: medium devsel, IRQ 20
> I/O ports at cf00 [size=8]
> I/O ports at ce00 [size=8]
> I/O ports at cd00 [size=8]
> I/O ports at cc00 [size=8]
> I/O ports at cb00 [size=8]
> I/O ports at ca00 [size=16]
> Kernel modules: parport_pc
>
> Doing a /sbin/modprobe parport_pc io=0x378,0xcf00 irq=7,20 runs but no
> printer is detected using any of the above ports.
>
> The setup works in Windoz 7, same machine, so no hardware issue. Running
> 2010.2, PhenomIIx2 64 bit machine. Any ideas.
Nope, sorry. HOwever, remember that everything is hex, so that interrupt
is hex 20 (= 32 in base 10)
>
David W. Hodgins
> Doing a /sbin/modprobe parport_pc io=0x378,0xcf00 irq=7,20 runs but no
> printer is detected using any of the above ports.
After the above, try "modprobe -v ppdev", and check the syslog
again.
unruh
Actually I did answer.
I got the parallel port to work, but did not get the interrupt to work.
I am convinced that it cannot be made to work. The hardware is such that
it assumes an edge triggered interrupt and there is no way to tell the
board to stop sending a level trigger. I tried very hard to do all kinds
of things to switch off the interrupt, but nothing worked.
However the parport driver basically does not use the interrupt if it is
not a standard interrupt line (ie the old PC parallel port interrupts)
Note tha tthe report from lspci is all in octal. Thus and interrupt
reported as 20 is 20 hex=32 decimal.
I do not know how the ports are arranged on your board. I would suspect
that the first 3 are the first parallel port, and the second three the
second. Note that you will need to run it as an old fashined port (not
EPP or any of the other extended ports) since the EPP ports are not
0x400 higher than the base ports, which the old standard dictated.
On 2011-04-10, Klaatu <houn...@gmail.com> wrote:
>>
>> Reading the MOSCHIP specs for this system gives me no clue.
>>
>
> Did you get the parallel port printer to work? I have a MOSCHIP 9815 (2
> Parallel ports) going to /var/log and running "cat syslog | grep parport"
> yields
>
> Apr 10 09:45:04 phenom kernel: parport_pc 00:0a: reported by Plug and Play
> ACPI
> Apr 10 09:45:04 phenom kernel: parport0: PC-style at 0x378, irq 7
> [PCSPP,TRISTATE]
> Apr 10 09:45:04 phenom kernel: parport_pc 0000:03:06.0: PCI INT A -> GSI 20
> (level, low) -> IRQ 20
> Apr 10 09:45:04 phenom kernel: parport1: PC-style at 0xcf00 (0xce00), irq
> 20, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
> Apr 10 09:45:04 phenom kernel: parport2: PC-style at 0xcd00 (0xcc00), irq
> 20, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
Wrong interupt-- it should be 32. Ahd you should tell it you have no
interrupt.
Do you actually have a parport 0 (ie an on board parallel port)?
So I suspect that 0xcf00-03 are the legacy parallel port registers,
0xce00-3 are the extended registers, and similarly with
cd00 and cc00
>
> lspci -v yields
>
> 03:06.0 Communication controller: NetMos Technology PCI 9815 Multi-I/O
> Controller (rev 01)
> Subsystem: LSI Logic / Symbios Logic 2P0S (2 port parallel adaptor)
> Flags: medium devsel, IRQ 20
> I/O ports at cf00 [size=8]
> I/O ports at ce00 [size=8]
> I/O ports at cd00 [size=8]
> I/O ports at cc00 [size=8]
> I/O ports at cb00 [size=8]
> I/O ports at ca00 [size=16]
> Kernel modules: parport_pc
>
> Doing a /sbin/modprobe parport_pc io=0x378,0xcf00 irq=7,20 runs but no
> printer is detected using any of the above ports.
0x378 will be an on-board parallel port. Perhaps there is a header on
your motherboard, that needs a parallel port cable plugged into it.
You have the wrong irq for the cf00-- it is 20 hex, not 20dec.
>
> The setup works in Windoz 7, same machine, so no hardware issue. Running
> 2010.2, PhenomIIx2 64 bit machine. Any ideas.
>
Using the drivers on the supplied cdrom I suspect.
Greegor
When did they stop using IRQ 4,3,4,3 for
COM1,COM2,COM3,COM4?
unruh
> On Apr 10, 12:43?pm, Klaatu <houndn...@gmail.com> wrote:
>> > Reading the MOSCHIP specs for this system gives me no clue.
>>
>> Parallel ports) going to /var/log and running "cat syslog | grep parport"
>> yields
>>
>> Apr 10 09:45:04 phenom kernel: parport_pc 00:0a: reported by Plug and Play
>> ACPI
>> Apr 10 09:45:04 phenom kernel: parport0: PC-style at 0x378, irq 7
>> [PCSPP,TRISTATE]
>> Apr 10 09:45:04 phenom kernel: parport_pc 0000:03:06.0: PCI INT A -> GSI 20
>> (level, low) -> IRQ 20
>> Apr 10 09:45:04 phenom kernel: parport1: PC-style at 0xcf00 (0xce00), irq
>> 20, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
>> Apr 10 09:45:04 phenom kernel: parport2: PC-style at 0xcd00 (0xcc00), irq
>> 20, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
>>
>> lspci -v yields
>>
>> 03:06.0 Communication controller: NetMos Technology PCI 9815 Multi-I/O
>> Controller (rev 01)
>> ? ? ? ? Flags: medium devsel, IRQ 20
>> ? ? ? ? I/O ports at cf00 [size=8]
>> ? ? ? ? I/O ports at ce00 [size=8]
>> ? ? ? ? I/O ports at cd00 [size=8]
>> ? ? ? ? I/O ports at cc00 [size=8]
>> ? ? ? ? I/O ports at cb00 [size=8]
>> ? ? ? ? I/O ports at ca00 [size=16]
>> ? ? ? ? Kernel modules: parport_pc
>>
>> Doing a /sbin/modprobe parport_pc io=0x378,0xcf00 irq=7,20 runs but no
>> printer is detected using any of the above ports.
>>
>> 2010.2, PhenomIIx2 64 bit machine. ?Any ideas.
>
> When did they stop using IRQ 4,3,4,3 for
> COM1,COM2,COM3,COM4?
When they build add on cardswhich were supposed to work on any machine,
including those for which that irq and ioports were already in use. The
worse thing about these cards is that they use shared interrupts, and
all of the software for serial and parallel ports assumes edge triggered
interrupts (whch do not work on shared interrupts), which means that the
interrupts are pretty much useless. And since the serial/parallel ports
are the only things which use interrupts anymore accessible by the user,
this means that one cannot do any interrupt driven stuff anymore (eg pps
timers)
Jasen Betts
>> > Reading the MOSCHIP specs for this system gives me no clue.
> When did they stop using IRQ 4,3,4,3 for
> COM1,COM2,COM3,COM4?
For me it was sometime in the late 80s
that only worked if you didn't need interrupts on both of the ports that
share an IRQ line.
I used to rewire one of my serial ports on one of the unused ISA IRQ
lines, so I could run tests of serial software without losing my modem.
⚂⚃ 100% natural
Jasen Betts
> When they build add on cardswhich were supposed to work on any machine,
> including those for which that irq and ioports were already in use. The
> worse thing about these cards is that they use shared interrupts, and
> all of the software for serial and parallel ports assumes edge triggered
> interrupts (whch do not work on shared interrupts), which means that the
> interrupts are pretty much useless. And since the serial/parallel ports
> are the only things which use interrupts anymore accessible by the user,
> this means that one cannot do any interrupt driven stuff anymore (eg pps
> timers)
these ones work well:
01:02.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954
especially the 8-port ones. (the 4-ports ones show, in addition, 4 phantom
16550 UARTS sthat don't do anything but clutter up /dev/)
I'm running 16 ports in one machine a bunch of 9600 baud devices.
there's an 8, two 4's and the single on-board serial
each card seems to use an individual interrupt
number 17 seems to be shared with the disk controller and USB
root@XYZ# cat /proc/interrupts | grep serial,
4: 9519 0 IO-APIC-edge serial
17: 14190035 0 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel, serial
21: 14184365 0 IO-APIC-fasteoi serial
22: 25653545 0 IO-APIC-fasteoi serial
It looks like the internal's unused, uptime is only 3 days, not
sure why, the machine is in another city.
USB is more and more primising for serial, with a little hotplug trickery
cheap Prolific or SiLabs serial adaptors can be issued /dev names based on
their USB hardware address (what port of what hub they are connected to)
so that the names are repeatable
--
⚂⚃ 100% natural
unruh
Yes, those are level triggered interrupts. The Parallel port seems to
have no way of telling the card that the interupt has been processed. As
a result it gives and itnerrupt every usec while the Ack line is high.
Now, I supposed I could switch off interrupts, wait for half a second
and then switch them on again (since I am looking at a PPS) but that
really really seems like a kludge.
I do not know if the serial port allows the interrupts to be serviced
without immediately trigger another interrupt since the level on the
line is still high.
Your system seems to have25Minterrupts in 3 days. 3 days is 300000 sec,
so you are getting about 100 interrupts per second.
Are those actually on one of the lines, or are they "buffer full/buffer
empty" interrupts?