Subject: Re: Re: 8259 spurious interrupt (IRQ1,IRQ7,IRQ12..)

From: Zhang Fuxin <[email-masked]>
Date: Wed, 19 Sep 2001 16:37:35 +0800

hi,Jun Sun，
在 2001-09-18 10:09:00 you wrote：
>Zhang Fuxin wrote:
>> 
>> hi,all
>>   I have finally been able to get a copy of sgi cvs code:).Now I have
>> changed my p6032 code to use new[time,pci,irq] code and it seems a
>> lot cleaner.But still problems.
>
>Cool.  Very glad to hear that.
Thank you for encourage:). I am new to mips and kernel programming,the code 
may still look very dirty for your eyes.But i will try my best.
>
>>   I keep seeing spurious interrupt when starting xwindows.And
>> sometimes without x. If the machine is doing heavy io(e.g.,unzip &
>> untar mozilla source) when I startx,it will probably enter an
>> endless loop of spurious interrupt or lead to unaligned instruction
>> access shortly after(with epc=0x1,ra=0x1) and die.
>>   I have seen spurious IRQ1,IRQ7 and IRQ12,and the endless loop case
>> is IRQ12--ps2 mouse interrupt.
>>   Can somebody give me a clue? What I know is that 8259 may generate
>> spurious IRQ7 & IRQ15. But how can the others happen,buggy hw?And
>> what may cause a kernel unaligned instruction access?
>
>Are you using arch/mips/i8259.c file?
Yes.
>
>One possibility is your irq dispatching code.  If it loops to deliver all
>pending interrupts, what you described may happen (assuming there is a real
>hardware connecting to those irq sources).
I have checked the p6032 manual.It says it has an intel FW82371AB("PIIX 4") 
south bridge chip,a National Semiconductor PC97307-ICE/VUL multi I/O 
controller which includes dual serial ports and rtc,PC mouse/keyb etc,connect 
to the PIIX 4.

 My irq dispatching code is very simple,it just read the IRR,count the first
irq number and call do_IRQ.
  /*
 * the first level int-handler will jump here if it is a 8259A irq
 */
asmlinkage void i8259A_irqdispatch(struct pt_regs *regs)
{
        int isr, irq;

        isr = inb(0x20);

        irq = ffz (~isr);

        if (irq == 2) {
                isr = inb(0xa0);
                irq = 8 + ffz(~isr);
        }

        do_IRQ(irq,regs);
}

>
>> 
>>   My hw is p6032 rev.B eval board with idtRC64474 cpu.
>> 
>>   BTW,is that current code has no support for different PCI & CPU
>> address space?In p6032 default setting,PCI memory address 0 is
>> CPU physical address 0x10000000,and main memory is 0-0x10000000
>> for CPU,but 0x80000000-0x90000000 for pci. So I have to change
>> ioremap,virt_to_bus & bus_to_virt. I think this problem should
>> exist in many nonpc hw,could you point me a clean way?
>> 
>
>For now, we do assume PCI memeory space is identical to physical address
>space.  To remove the restriction cleanly is not a small task.
>
>It is typically much easier to modify PCI device BARS so that they do coincide
>with the same physical address.   You can control that by using the correct
>starting address for PCI MEM space in pci_auto.c resource assignment.  
It seems a good way to solve the ioremap problem and X problem.But virt_to_bus
& bus_to_virt problem remains?

Thank you very much.

>Jun

Regards
            Zhang Fuxin
            [email-masked]

---

From: Jun Sun <[email-masked]>
Date: Wed, 19 Sep 2001 12:39:09 -0700

> asmlinkage void i8259A_irqdispatch(struct pt_regs *regs)

OK, so the problem is not what I was thinking.

I don't have much clue here.  I remember old i8259As have some timing issues
on fast cpus.  Hopefully all the bridge chips are set up correctly ...

> & bus_to_virt problem remains?

What is the virt_to_bus() problem?  Is the address beyond 512MB (phy addr)? 
If PCI mem (BUS) address is identical to phy addr, you should not have problem
unless the address is beyond 512MB.

BTW, virt_to_bus()/bus_to_virt() are deprecicated.  See
Documentation/DMA-mapping.txt.

Jun