XLlTemac soft lockup BUG

[John Bonesio]

Hi Kevin,

Does xlltemac_main.c have
    #define MARVELL_88E1111_PHY
in it? If not, try setting that.

It's odd that sometimes it works. Does your system meet timing?

We've found that when the PHY is being poked, it can take a while before the PHY settles down and starts working. If the code tries to start using the PHY too soon, then the PHY never seems to get to a good state. So, you might experiement with different values in the udelay() call in _XLlTemac_SetOperatingSpeed().

If you really think there's something wrong in the fifo code, you can enable debug (#define DEBUG) in the following files:
drivers/xilinx_common/xdebug.h
drivers/xilinx_common/xstreamer.h

Perhaps that will shed some light on the problem.

- John


On Wednesday 16 April 2008 15:08, khollan wrote:
> 
> Hugo Villeneuve-3 wrote:
> > 
> > Hi,
> > we had a similar error message, which was caused by us selecting the wrong
> > PHY type in the kernel configuration menu (latest linux-2.6-xlnx-git
> > tree). In fact, we had to modify the lltemac driver to support our PHY
> > (BCM5466). Once we did that, the error message went away.
> > 
> > Hugo V.
> > 
> I tried out all 3 configurations and it didn't seem to help.  We are using
> the Marvell Phy on our prototype.  The weird thing is it seems to work
> perfectly every once in awhile, but not very often.  I seem to have tracked
> the problem to the FifoRecvHandler tasklet function in xlltemac_main.c it
> gets stuck in this while loop:
> while (XLlFifo_RxOccupancy(&lp->Fifo) != 0) {
> the XLlFifo_RxOccupancy always reads the same value.
> Any ideas?
> 
> Thanks
> Kevin
> -- 
> View this message in context: http://www.nabble.com/XLlTemac--soft-lockup-BUG-tp16711066p16734685.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
>