Problems with 2_4_devel & MVME2600 serial interrupts

Problems with 2_4_devel & MVME2600 serial interrupts

[Anders Blomdell]

When trying 2_4_devel on a MVME2600 box, the system hangs on the first
access to stdout (printk works OK).

The problem occurs when my /bin/sh gets invoked as the init task, so all
kernel initialization seems to work OK (lots of reasonable output at least)
. What seems to happen is:

1. A write to stdout eventually reach rs_write (drivers/char/serial/serial.
c),
    where the following gets executed:

		info->IER |= UART_IER_THRI;
		serial_out(info, UART_IER, info->IER);

2. When the interrupts gets enabled, the system gets an interrupt and
eventually
    calls i8259_irq, which reads 0xff from pci_intack, which it will
continue to
    do	forever in this loop (do_IRQ, arch/kernel/irq.c):

      while ((irq = ppc_md.get_irq(regs)) >= 0) {
		ppc_irq_dispatch_handler(regs, irq);
		first = 0;
      }

Does anybody has a clue what might be wrong (linuxppc_2_4 works OK, but not
the linuxppc_2_4_devel)?

Regards

Anders Blomdell

------------------------------------------------------------------------------
  Anders Blomdell
  Department of Automatic Control        Email: anders.blomdell@control.lth.
se
  Lund Institute of Technology           Phone: +46 46 222 4625
  Box 118, S-221 00 Lund, Sweden         Fax:   +46 46 138118


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with 2_4_devel & MVME2600 serial interrupts

[Anders Blomdell]

> When trying 2_4_devel on a MVME2600 box, the system hangs on the first
> access to stdout (printk works OK).
>
> The problem occurs when my /bin/sh gets invoked as the init task, so all
> kernel initialization seems to work OK (lots of reasonable output at least)
> . What seems to happen is:
>
> 1. A write to stdout eventually reach rs_write (drivers/char/serial/serial.
> c),
>    where the following gets executed:
>
> 		info->IER |= UART_IER_THRI;
> 		serial_out(info, UART_IER, info->IER);
>
> 2. When the interrupts gets enabled, the system gets an interrupt and
> eventually
>    calls i8259_irq, which reads 0xff from pci_intack, which it will
> continue to
>    do	forever in this loop (do_IRQ, arch/kernel/irq.c):
>
>      while ((irq = ppc_md.get_irq(regs)) >= 0) {
> 		ppc_irq_dispatch_handler(regs, irq);
> 		first = 0;
>      }
>
> Does anybody has a clue what might be wrong (linuxppc_2_4 works OK, but not
> the linuxppc_2_4_devel)?

A quick (and working, but probably unclean) solution is call
'i8259_init(intack_addr)' with intack_addr set to zero (instead of the
0xbffffff0 from prep_setup.c), thus forcing the interrupt to be polled from
the 8259 controller. Could somebody who understands open_pic (is this a
relative to MPIC?), give me a hint of suitable further reading before I to
try to clean this up?

Regards

Anders Blomdell


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with 2_4_devel & MVME2600 serial interrupts

[Hollis Blanchard]

On Fri, 2002-10-18 at 09:59, Anders Blomdell wrote:
>
> > 2. When the interrupts gets enabled, the system gets an interrupt and
> > eventually
> >    calls i8259_irq, which reads 0xff from pci_intack, which it will
> > continue to
> >    do	forever in this loop (do_IRQ, arch/kernel/irq.c):
>
> A quick (and working, but probably unclean) solution is call
> 'i8259_init(intack_addr)' with intack_addr set to zero (instead of the
> 0xbffffff0 from prep_setup.c), thus forcing the interrupt to be polled from
> the 8259 controller. Could somebody who understands open_pic (is this a
> relative to MPIC?), give me a hint of suitable further reading before I to
> try to clean this up?

Seems to me that either:
a) the pci_intack value is incorrect for your board, in which case you
should correct it
b) your board's int-ack feature is broken and you'll need to poll

-Hollis

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with 2_4_devel & MVME2600 serial interrupts

[Anders Blomdell]

> Seems to me that either:
> a) the pci_intack value is incorrect for your board, in which case you
> should correct it
Shure is, question is if it really should be caught from the pci_intack
register, as far as I can understand from the MVME2600 doc's, the 8259
interrupt generates a MPIC-IRQ0, but one has to poll the 8259 to find out
what device it was that generated the interrupt.


> b) your board's int-ack feature is broken and you'll need to poll

Perhaps an extra field in the 'mot_info' (arch/ppc/platforms/prep_pci.c) is
called for? This line in prep_init_IRQ (arch/ppc/platforms/prep_setup.c):

   i8259_init(0xbffffff0); /* PCI interrupt ack address for MPC105 and 106
*/

does not look like a general solution.

I'll take a further look in next week. Any comments/suggestions are welcome.
..

Regards

Anders Blomdell


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with 2_4_devel & MVME2600 serial interrupts

[Hollis Blanchard]

On Fri, 2002-10-18 at 10:47, Anders Blomdell wrote:
> > Seems to me that either:
> > a) the pci_intack value is incorrect for your board, in which case you
> > should correct it
> Shure is, question is if it really should be caught from the pci_intack
> register,

If possible, yes it should (IMHO). There was a thread on linuxppc-dev
about a year ago:
http://lists.linuxppc.org/linuxppc-dev/200112/msg00032.html

I think Gabriel's point about hardware testing methods is the best
argument, though I also think having hardware figure it out greatly
diminishes the chance of software polling race conditions such as those
that plagued a few desktop PReP machines for a long time.

> as far as I can understand from the MVME2600 doc's, the 8259
> interrupt generates a MPIC-IRQ0, but one has to poll the 8259 to find out
> what device it was that generated the interrupt.

Yes. Software can do this. The alternative is that some hardware (PHBs)
can do it too, which is what you're using if you pass a non-0 address to
i8259_init.

> Perhaps an extra field in the 'mot_info' (arch/ppc/platforms/prep_pci.c) is
> called for? This line in prep_init_IRQ (arch/ppc/platforms/prep_setup.c):
>
>    i8259_init(0xbffffff0); /* PCI interrupt ack address for MPC105 and 106
> */
>
> does not look like a general solution.

What you're saying is that you have a PReP machine without a Motorola
host bridge? Then yes, that constant will need to be abstracted.

-Hollis

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with 2_4_devel & MVME2600 serial interrupts

[Hollis Blanchard]

On Fri, 2002-10-18 at 11:04, Hollis Blanchard wrote:
>
> On Fri, 2002-10-18 at 10:47, Anders Blomdell wrote:
> > > Seems to me that either:
> > > a) the pci_intack value is incorrect for your board, in which case you
> > > should correct it
> > Shure is, question is if it really should be caught from the pci_intack
> > register,
>
> If possible, yes it should (IMHO). There was a thread on linuxppc-dev
> about a year ago:
> http://lists.linuxppc.org/linuxppc-dev/200112/msg00032.html

Oops, this is the right thread:
http://lists.linuxppc.org/linuxppc-dev/200111/msg00073.html

-Hollis

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with 2_4_devel & MVME2600 serial interrupts

[Tom Rini]

On Fri, Oct 18, 2002 at 05:47:32PM +0200, Anders Blomdell wrote:
>
> >Seems to me that either:
> >a) the pci_intack value is incorrect for your board, in which case you
> >should correct it
> Shure is, question is if it really should be caught from the pci_intack
> register, as far as I can understand from the MVME2600 doc's, the 8259
> interrupt generates a MPIC-IRQ0, but one has to poll the 8259 to find out
> what device it was that generated the interrupt.

Are you running this as CONFIG_ALL_PPC?  IIRC, under 2_4_devel, this
board should work as CONFIG_PPLUS.  Or it will need minor fixups, which
I have described previously on the lists (and possibly to you as well)
for the OpenPIC table.

> >b) your board's int-ack feature is broken and you'll need to poll
>
> Perhaps an extra field in the 'mot_info' (arch/ppc/platforms/prep_pci.c) is
> called for? This line in prep_init_IRQ (arch/ppc/platforms/prep_setup.c):
>
>   i8259_init(0xbffffff0); /* PCI interrupt ack address for MPC105 and 106
> */
>
> does not look like a general solution.

Well, it's a correct solution for the PReP like PReP machines.  Where in
the continium does the MVME2600 fall exactly?
MPC105/MPC106/Raven/Hawk/Falcon ?  I _think_ this is an example of why
it would really be nice to kill PPLUS support from PReP.  But I know
that will upset some people, so I'm not advocating that for 2.4, and it
looks like we might have to do something similar to the MPC10x test in
the PReP bootwrapper code in 2.5 (and maybe 2.4? I'm not at home, so I
can't easily check).

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with 2_4_devel & MVME2600 serial interrupts

[Anders Blomdell]

> On Fri, Oct 18, 2002 at 05:47:32PM +0200, Anders Blomdell wrote:
> >
> > >Seems to me that either:
> > >a) the pci_intack value is incorrect for your board, in which case you
> > >should correct it
> > Shure is, question is if it really should be caught from the pci_intack
> > register, as far as I can understand from the MVME2600 doc's, the 8259
> > interrupt generates a MPIC-IRQ0, but one has to poll the 8259 to find out
> > what device it was that generated the interrupt.
>
> Are you running this as CONFIG_ALL_PPC?  IIRC, under 2_4_devel, this
> board should work as CONFIG_PPLUS.  Or it will need minor fixups, which
> I have described previously on the lists (and possibly to you as well)
> for the OpenPIC table.
CONFIG_ALL_PPC, yes.
>
> > >b) your board's int-ack feature is broken and you'll need to poll
> >
> > Perhaps an extra field in the 'mot_info' (arch/ppc/platforms/prep_pci.c) is
> > called for? This line in prep_init_IRQ (arch/ppc/platforms/prep_setup.c):
> >
> >   i8259_init(0xbffffff0); /* PCI interrupt ack address for MPC105 and 106
> > */
> >
> > does not look like a general solution.
>
> Well, it's a correct solution for the PReP like PReP machines.  Where in
> the continium does the MVME2600 fall exactly?
> MPC105/MPC106/Raven/Hawk/Falcon ?  I _think_ this is an example of why
> it would really be nice to kill PPLUS support from PReP.  But I know
> that will upset some people, so I'm not advocating that for 2.4, and it
> looks like we might have to do something similar to the MPC10x test in
> the PReP bootwrapper code in 2.5 (and maybe 2.4? I'm not at home, so I
> can't easily check).
It's a Raven equipped card, and as far as I can find, the 8259
interrupts acks are not accessible from any other adress. I'll look
further into this on monday...


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with 2_4_devel & MVME2600 serial interrupts

[Tom Rini]

On Sat, Oct 19, 2002 at 08:35:52PM +0200, Anders Blomdell wrote:
> > On Fri, Oct 18, 2002 at 05:47:32PM +0200, Anders Blomdell wrote:
> > >
> > > >Seems to me that either:
> > > >a) the pci_intack value is incorrect for your board, in which case you
> > > >should correct it
> > > Shure is, question is if it really should be caught from the pci_intack
> > > register, as far as I can understand from the MVME2600 doc's, the 8259
> > > interrupt generates a MPIC-IRQ0, but one has to poll the 8259 to find out
> > > what device it was that generated the interrupt.
> >
> > Are you running this as CONFIG_ALL_PPC?  IIRC, under 2_4_devel, this
> > board should work as CONFIG_PPLUS.  Or it will need minor fixups, which
> > I have described previously on the lists (and possibly to you as well)
> > for the OpenPIC table.
> CONFIG_ALL_PPC, yes.
> >
> > > >b) your board's int-ack feature is broken and you'll need to poll
> > >
> > > Perhaps an extra field in the 'mot_info' (arch/ppc/platforms/prep_pci.c) is
> > > called for? This line in prep_init_IRQ (arch/ppc/platforms/prep_setup.c):
> > >
> > >   i8259_init(0xbffffff0); /* PCI interrupt ack address for MPC105 and 106
> > > */
> > >
> > > does not look like a general solution.
> >
> > Well, it's a correct solution for the PReP like PReP machines.  Where in
> > the continium does the MVME2600 fall exactly?
> > MPC105/MPC106/Raven/Hawk/Falcon ?  I _think_ this is an example of why
> > it would really be nice to kill PPLUS support from PReP.  But I know
> > that will upset some people, so I'm not advocating that for 2.4, and it
> > looks like we might have to do something similar to the MPC10x test in
> > the PReP bootwrapper code in 2.5 (and maybe 2.4? I'm not at home, so I
> > can't easily check).
> It's a Raven equipped card, and as far as I can find, the 8259
> interrupts acks are not accessible from any other adress. I'll look
> further into this on monday...

Any address other than what?  If i8259_init is passed 0, then we poll,
instead of asking the int-ack.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/