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

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

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

[Jun Sun]

Zhang Fuxin wrote:
> 
>  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);
> }
> 

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 ...

> >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)? 
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

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

[Jun Sun]

Zhang Fuxin wrote:
> 
> 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.
> 

You should make sys memory appears starting from 0x0 in PCI memory as well. 
That was part of what I meant by making PCI memory address and CPU physical
address identical.

> >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?

Hmm, I am not too sure here.  My understanding is any new driver should try
*not* to use it.  pci-dma.c may use it because of lack of other means or just
a quick hack.

Jun

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

[Zhang Fuxin]

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.
  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?

  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?

  Thanks in advance.


Regards
            Zhang Fuxin
            fxzhang@ict.ac.cn

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

[Gleb O. Raiko]

Zhang Fuxin wrote:
>   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?
> 

Change them.

Regards,
Gleb.

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

[Jun Sun]

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.

>   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?

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).

> 
>   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.  

Jun