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
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
: 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 all,
As a simple stress
[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
-Original Message-
From: linuxppc-dev-bounces+dai.haruki=freescale
-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
Dai,
Is this your own board? If so, what PHY chip
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 bug check
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)
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, Version:
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.
--
-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 when the data
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 scott.coul...@cyclone.com
Kumar,
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
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
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
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
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-mtu at
16 matches
Mail list logo
