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

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

[Phil Thompson]

> -----Original Message-----
> From: Zhang Fuxin [mailto:fxzhang@ict.ac.cn]
> Sent: 19 September 2001 09:38
> To: linux-mips@oss.sgi.com
> Subject: Re: Re: 8259 spurious interrupt (IRQ1,IRQ7,IRQ12..)
> 
> 
> 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.

Make sure you read the section in the P6032 manual "Tips on programming
south bridge interrupt controller(s)" - page 31. I don't see how the 8259
code that's part of the MIPS tree can ever be used without changes.

Phil

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

[Ralf Baechle]

On Wed, Sep 19, 2001 at 11:27:14AM +0100, Phil Thompson wrote:

> Make sure you read the section in the P6032 manual "Tips on programming
> south bridge interrupt controller(s)" - page 31. I don't see how the 8259
> code that's part of the MIPS tree can ever be used without changes.

Can you elaborate?  It's actually being used without problems.

  Ralf

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

[Phil Thompson]

> -----Original Message-----
> From: Ralf Baechle [mailto:ralf@oss.sgi.com]
> Sent: 19 September 2001 17:41
> To: Phil Thompson
> Cc: 'Zhang Fuxin'; linux-mips@oss.sgi.com
> Subject: Re: Re: 8259 spurious interrupt (IRQ1,IRQ7,IRQ12..)
> 
> 
> On Wed, Sep 19, 2001 at 11:27:14AM +0100, Phil Thompson wrote:
> 
> > Make sure you read the section in the P6032 manual "Tips on 
> programming
> > south bridge interrupt controller(s)" - page 31. I don't 
> see how the 8259
> > code that's part of the MIPS tree can ever be used without changes.
> 
> Can you elaborate?  It's actually being used without problems.

The P6032 documentation recommends using Special Mask Mode to disable the
8259's priority logic so that reading the ISR register gives you the set of
pending interrupts. I took that at face value, so you need to program the
mode and need a function to return the set of pending interrupts (although
you could use i8259A_irq_pending() in loop).

Phil

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

[Zhang Fuxin]

hi,Jun Sun，

在 2001-09-19 12:39:00 you wrote：
>
>> >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?
>> 
>
>What is the virt_to_bus() problem?  Is the address beyond 512MB (phy addr)? 
No,I mean problem caused different cpu & pci address space.from pci's view,
the main memory is at address 0x80000000-0x90000000 in p6032.But for cpu,
they are 0x0-0x10000000.So current virt_to_bus & bus_to_virt won't work.

>If PCI mem (BUS) address is identical to phy addr, you should not have problem
>unless the address is beyond 512MB.
yes:).When i solve the 8259,i will try to make them same.
>
>BTW, virt_to_bus()/bus_to_virt() are deprecicated.  See
>Documentation/DMA-mapping.txt.
I think the "depreciated" is only for direct usage: they are used in
arch/mips/pci-dma.c to implement new interface pci_alloc_consistent.
And there are still many driver using them(grep tell me).Am i missing
something?
>
>Jun

Regards
            Zhang Fuxin
            fxzhang@ict.ac.cn

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

[Zhang Fuxin]

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
            fxzhang@ict.ac.cn