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
>
>
age-
> From: linuxppc-dev-bounces+dai.haruki=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+dai.haruki=freescale@ozlabs.org] On
Behalf Of
> Scott Coulter
> Sent: Wednesday, February 18, 2009 10:16 AM
> To: linuxppc-dev@ozlabs.org
> Subject: Gianfar tx-babbling-errors
>
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
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 for 4 days straight or so with between 250-300 build cycles per
16 matches
Mail list logo
