OSDev.org

Hi guys and girls,
After many sleepless days and nights, I finally discovered why my 32bit Os code that boots fine on 32bit pcs and Bochs suddenly stopped working when I bought a 64bit Amd pc.

The AMD PC is a 3.7+GHz processor on an Asrock 939 DualSata2(Uli 1695 chipset) motherboard.

The problem is that for some strange reason, as soon as I enable interrupts the LPT 1 (IRQ 7) fires even though on 32bit pcs this does not occur.

Anyone have an idea why this would happen?

I would appreciate any ideas. Thanks a lot

Hi,

Code Slasher wrote:The problem is that for some strange reason, as soon as I enable interrupts the LPT 1 (IRQ 7) fires even though on 32bit pcs this does not occur.

Anyone have an idea why this would happen?

To be honest, I don't know exactly what causes it...

I had the same problem on an older Pentium 166 MHz (not sure what the motherboard was) many years ago on an early version of my OS - I haven't seen it for about 8 years.

At the time I couldn't find any problem with my code, and in the end I gave up and put a dummy IRQ handler in (i.e. just an "iret" to stop it crashing).

Today, I did a Google search for "spurious IRQ7 8259A" and found a lot of confused people - it seems Linux has the same problem on a wide variety of different hardware, and no-one seems to know exactly what causes it.

One of the better pages seems to be this page. I like the last possibility they've listed:

"A device issues interrupt requests for a period of time too short to be recognized correctly by the 8259A, or the CPU acknowledges ( /INTA) the request too late (See data sheet for the Intersil 82C59A , page 6)"

In any case, I'd suggest adding a dummy IRQ handler and ignoring it - if the entire Linux community can't figure it out, chances are we won't either...


Cheers,

Brendan

Thanks man. I've decided to initialize my entire IDT table with the following cde Then add actual handlers as I load drivers.

It's stange that such a hardware bug still persists till today!

Seen the same issue, always thought it was just bad hardware I was using and made that IRQ simply return (iret).

Code Slasher wrote: Thanks man. I've decided to initialize my entire IDT table with the following cde

Code: Select all

unhandled_int:
       mov al,0x20
       out 0xa0,al
       out 0x20,al
       iretd

when you say "the entire IDT", i suppose you mean "all of IRQs 8..15" ... There's no reasons to acknowledge the slave pic when an interrupt is delivered from the master. And there's certainly no reason to acknowledge both when an exception or a system call is handled.

Does that 64-bit machine have an actual LPT port? Can you check (bios [boot]) what is actually connected to that IRQ 7?

@Pype:
For now I'm initializing all 256 idt entries. Know this is overkill ;D

@Rob:
There is an LPT port, assigned to IRQ 7 and 0x2xx. (Thats not the problem)

Brendan gave me a link in his post, seems this is a known issue.

Could we add this random IRQ 7 behaviour to a list of Gotchas - Things to look out for in our FAQ? (Might do it myself!)

Thanks

Hi,

Code Slasher wrote:Could we add this random IRQ 7 behaviour to a list of Gotchas - Things to look out for in our FAQ? (Might do it myself!)

I think that's a good idea...

I've done a little digging, and found a curious paragraph in Intel's "8259A Programmable Interrupt Controller (8259A/8259A-2)" datasheet. It reads:

"In both the edge and level triggered modes the IR inputs must remain high after the falling edge of the first INTA. If the IR input goes low before this time a DEFAULT IR7 will occur when the CPU acknowledges the interrupt. This can be a useful safeguard for detecting interrupts caused by suprious noise glitches on the IR inputs. To implement this feature the IR7 routine is used for "clean-up" simply executing a return instruction, thus ignorng the interrupt. If IR7 is needed for other purposes a default IR7 can still be detected by reading the ISR. A normal IR7 interrupt will set the corresponding ISR bit, a default IR7 won't. If a default IR7 routine occurs during a normal IR7 routine, however, the ISR will remain set. In this case it is necessary to keep track of whether or not the IR7 routine was previously entered. If another IR7 occurs it is a default."

This leads me to 5 conclusions:

• - it has nothing to do with the parallel port or any of the other hardware.
  - for a spurious IRQ7 you don't need an EOI at all.
  - the same thing could happen for the slave PIC chip, giving spurious IRQ15.
  - if it does happen on the slave PIC you might need to send an EOI to the master PIC (but shouldn't need to send an EOI to the slave PIC). I'm not too sure here.
  - the Linux community don't know as much as I assumed .

I also did a google search for "spurious IRQ15" and found this web page: http://en.wikipedia.org/wiki/Intel_8259#Spurious_Interrupts, which is rather informative....


Cheers,

Brendan

Now that is very interesting Brendan. Nice find!