Re: PPC440GX GigE support - Update

Re: PPC440GX GigE support - Update

[Phil Thompson]

With a bit more digging I've come to the conclusion that interrupts are not
the cause of the problem. It seems more like the time taken by the SCSI
driver to initialise 2 SCSI buses is triggering the problem.

If I hack the SCSI driver detect code to just delay before returning "not
found" then things work with an overal delay of 2 seconds, but fail with an
overall delay of 4 seconds.

This would imply the problem is just within the GigE driver. Matt, comments?

Thanks,
Phil

> -----Original Message-----
> From: Phil Thompson
> Sent: 13 May 2004 12:44
> Subject: RE: PPC440GX GigE support
>
> I'm having some problems with this on an Ocotea board (using the
> latest source).
>
> With the default Ocotea configuration everything works fine when
> booting over both eth0 and eth3. If I then configure support for the
> SYM53C8XX_2 SCSI driver then everything continues to be fine for eth0,
> but with eth3 the system times out trying to autoconfigure using
> BOOTP. Packets are being sent Ok (irq 10 is raised and you see them on
> the wire), but they are not received (irq 11 is never raised).
>
> About 1 time in 10 the system will boot successfully.
>
> I don't think the SCSI driver is particularly relevant - just that
> it is a source of interrupts (irq 23) that occur after the MAL
> interrupts are enabled and before the kernel tries to use the network
> to autoconfigure.
>
> The implication is that there are problems in ppc4xx_pic.c in handling
> the 3rd UIC of the 440GX. There seems to be at least one bug in
> ppc4xx_uic_end() in the first case statement - there is no "case 2:"
> clause and it looks as if there should be - but it isn't the cause of
> the problem.
>
> I'll continue digging, but I'd welcome any ideas from anybody with
> more experience of interrupt handling on the 440GX.
>
> > -----Original Message-----
> > From: Matt Porter [mailto:mporter@kernel.crashing.org]
> > Sent: 19 April 2004 19:57
> > Subject: PPC440GX GigE support
> >
> > I've pushed a bunch of code for this to the linux-2.5-ocp tree.
> > It overhauls the EMAC driver a bit and adds a number of fields to
> > the new OCP EMAC .additions field that are set per SoC or by the
> > board specific code. There's support for GigE on EMAC2/3, the TAH,
> > zerocopy, and jumbo frames.


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

Re: PPC440GX GigE support - Update

[Matt Porter]

On Fri, May 14, 2004 at 09:59:16AM +0100, Phil Thompson wrote:
>
> With a bit more digging I've come to the conclusion that interrupts are not
> the cause of the problem. It seems more like the time taken by the SCSI
> driver to initialise 2 SCSI buses is triggering the problem.
>
> If I hack the SCSI driver detect code to just delay before returning "not
> found" then things work with an overal delay of 2 seconds, but fail with an
> overall delay of 4 seconds.
>
> This would imply the problem is just within the GigE driver. Matt, comments?

I've been looking at the problem too. I had no problem reproducing it
here.  I've isolated it down to where the EMAC itself is receiving
the bootp reply in its fifos (as evidenced by OCRX incrementing by
the number of octets in a bootp reply). However, the controller is
not getting the data into the MAL buffer from there, which is why
you don't see the RXEOB interrupt asserted.  It could be any number
of things, still looking.

BTW, thanks for pointing out the bug in ppc4xx_pic.c, I'll get that
change in soon.

-Matt

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