Hi all,
In my continued search to stop tx-babbling-errors, I grabbed the latest
blobs for gianfar.c and gianfar.h from http://git.kernel.org. The
history says that the following changes were made since the driver
version I was using (Freescale December 2008 LTIB release for 8572):
2009-02-09 Ja
Dai,
> I am not so sure about your PHY, but if you access to PHY while
packet
> transmission through MDIO bus, the packet might be corrupted. Do you
> have "phy_interrupt" in the /proc/interrupts? What is your dmesg
around
> the eTSEC look like (there is phy driver info surrounded).
With some p
egards
Dai
> -Original Message-
> From: Scott Coulter [mailto:scott.coul...@cyclone.com]
> Sent: Friday, February 20, 2009 3:00 PM
> To: Haruki Dai-R35557; linuxppc-dev@ozlabs.org
> Cc: Gala Kumar-B11780
> Subject: RE: Gianfar tx-babbling-errors
>
>
>
>
>
l Message-
> From: Haruki Dai-R35557 [mailto:dai.har...@freescale.com]
> Sent: February 20, 2009 2:16PM
> To: Scott Coulter; linuxppc-dev@ozlabs.org
> Cc: Gala Kumar-B11780
> Subject: RE: Gianfar tx-babbling-errors
>
> Hi Scott,
>
>
> Regards
> Dai
>
>
Hi Scott,
Is this your own board? If so, what PHY chip are you using? Are you
using the PHY driver?
If the generic PHY driver is used and polling the MDIO periodically for
the link check, you may truncate the packet. I hope this is not the
case.
Regards
Dai
> -Original Message-
> From
Hi Scott,
Your issue may come from data setup (or corruption) instead of code path:
babbling error may occurs when a TSEC TX descriptor hasn't its "last frame"
bit set or when the data length is greated than max frame length.
--
sj
2009/2/19 Scott Coulter
>
>
> Kumar,
>
> >
> > can't think of
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: February 19, 2009 12:04PM
> >
> > Your issue may come from data setup (or corruption) instead of code
> > path: babbling error may occurs when a TSEC TX descriptor hasn't its
> > "last frame" bit set or whe
On Feb 19, 2009, at 10:48 AM, sjoy...@wanadoo.fr wrote:
Hi Scott,
Your issue may come from data setup (or corruption) instead of code
path: babbling error may occurs when a TSEC TX descriptor hasn't its
"last frame" bit set or when the data length is greated than max
frame length.
--
>
> What specific processor & rev are you running on?
>
I've only been running the modified kernel with the added BUG_ON() code
on the 8568E processor, but I've seen the errors reported on the 8572E
as well.
According to the u-boot startup:
8568E, Version: 1.1, (0x807d0011)
Core: E500, Versio
On Feb 19, 2009, at 10:17 AM, Scott Coulter wrote:
Kumar,
can't think of any. How about adding a BUG_ON() in the tx path to
see
if the buffer size > MTU and re-run your tests.
So, here are the checks I've tried in gfar_start_xmit():
BUG_ON(skb->len > DEFAULT_RX_BUFFER_SIZE)
BUG_ON
Kumar,
>
> can't think of any. How about adding a BUG_ON() in the tx path to see
> if the buffer size > MTU and re-run your tests.
>
So, here are the checks I've tried in gfar_start_xmit():
BUG_ON(skb->len > DEFAULT_RX_BUFFER_SIZE)
BUG_ON(skb->len > priv->regs->maxfrm)
Neither produces a b
Kumar,
>
> can't think of any. How about adding a BUG_ON() in the tx path to see
> if the buffer size > MTU and re-run your tests.
>
With the following in gfar_start_xmit():
BUG_ON(skb->len > priv->dev->mtu);
I bug checked during the NFS root boot process with skb->len at 1514 and
priv->dev
On Feb 18, 2009, at 11:22 AM, Scott Coulter wrote:
Kumar,
I'm told this will occur when:
Transmitted frame > MAXFRM and MACCFG2[Huge En] = 0.
In the driver it looks like the MACCFG2_HUGEFRAME only gets set if the
mtu > DEFAULT_RX_BUFFER_SIZE (1536 in my kernel). It appears as
though
t
Kumar,
> I'm told this will occur when:
> Transmitted frame > MAXFRM and MACCFG2[Huge En] = 0.
In the driver it looks like the MACCFG2_HUGEFRAME only gets set if the
mtu > DEFAULT_RX_BUFFER_SIZE (1536 in my kernel). It appears as though
the mtu is set to 1500. Under what conditions would the d
On Feb 18, 2009, at 10:16 AM, Scott Coulter wrote:
Hi all,
As a simple stress test for my board with an MPC8572E and an
MPC8568E on
it, I setup both processors to boot linux 2.6.27.6 with an NFS root
and
then perform repeated native compiles of a linux kernel over NFS.
After
running fo
15 matches
Mail list logo
