Gianfar tx-babbling-errors

Gianfar tx-babbling-errors

[Scott Coulter]

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
processor, I stopped the builds and ran ethtool to look for any odd
statistics.  Both processors reported non-zero values for
tx-babbling-errors.  Both processors reported around 1300
tx-babbling-errors out of about 80,000,000 Tx packets.  Should I be
concerned about the tx-babbling-errors?  What conditions would cause
these errors to be reported?

Thanks,
Scott





___________________________________________________________________

  Scott N. Coulter
  Senior Software Engineer
 =20
  Cyclone Microsystems         =20
  370 James Street              Phone:  203.786.5536 ext. 118
  New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
  U.S.A.                        Web:    http://www.cyclone.com
___________________________________________________________________

Re: Gianfar tx-babbling-errors

[Kumar Gala]

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 for 4 days straight or so with between 250-300 build cycles  
> per
> processor, I stopped the builds and ran ethtool to look for any odd
> statistics.  Both processors reported non-zero values for
> tx-babbling-errors.  Both processors reported around 1300
> tx-babbling-errors out of about 80,000,000 Tx packets.  Should I be
> concerned about the tx-babbling-errors?  What conditions would cause
> these errors to be reported?
>
> Thanks,
> Scott

I'm told this will occur when:

Transmitted frame > MAXFRM and MACCFG2[Huge En] = 0.

- k

RE: Gianfar tx-babbling-errors

[Scott Coulter]

Kumar,

> I'm told this will occur when:

> Transmitted frame > MAXFRM and MACCFG2[Huge En] =3D 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 driver attempt
to send a frame larger than the mtu?

Scott

___________________________________________________________________

  Scott N. Coulter
  Senior Software Engineer
 =20
  Cyclone Microsystems         =20
  370 James Street              Phone:  203.786.5536 ext. 118
  New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
  U.S.A.                        Web:    http://www.cyclone.com
___________________________________________________________________

Re: Gianfar tx-babbling-errors

[Kumar Gala]

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
> the mtu is set to 1500.  Under what conditions would the driver  
> attempt
> to send a frame larger than the mtu?

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.

- k

RE: Gianfar tx-babbling-errors

[Scott Coulter]

Kumar,

>=20
> 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 1500.  I changed it to:

BUG_ON(skb->len > DEFAULT_RX_BUFFER_SIZE);

Compiling now.  Has not failed yet, I'll let you know.

Scott

___________________________________________________________________

  Scott N. Coulter
  Senior Software Engineer
 =20
  Cyclone Microsystems         =20
  370 James Street              Phone:  203.786.5536 ext. 118
  New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
  U.S.A.                        Web:    http://www.cyclone.com
___________________________________________________________________

RE: Gianfar tx-babbling-errors

[Scott Coulter]

Kumar,

>=20
> 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 yet ethtool reports non-zero
tx-babbling-errors.  The last check appears to be the definition of
tx-babbling-errors.  Is there a transmit path that I have missed?

Scott

___________________________________________________________________

  Scott N. Coulter
  Senior Software Engineer
 =20
  Cyclone Microsystems         =20
  370 James Street              Phone:  203.786.5536 ext. 118
  New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
  U.S.A.                        Web:    http://www.cyclone.com
___________________________________________________________________

Re: Gianfar tx-babbling-errors

[Kumar Gala]

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(skb->len > priv->regs->maxfrm)
>
> Neither produces a bug check yet ethtool reports non-zero
> tx-babbling-errors.  The last check appears to be the definition of
> tx-babbling-errors.  Is there a transmit path that I have missed?

What specific processor & rev are you running on?

- k

RE: Gianfar tx-babbling-errors

[Scott Coulter]

>=20
> 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: 2.2 (0x80210022)

8572E, Version: 1.1, (0x80e80011)
Core:  E500, Version: 3.0 (0x80210030)


Scott
___________________________________________________________________

  Scott N. Coulter
  Senior Software Engineer
 =20
  Cyclone Microsystems         =20
  370 James Street              Phone:  203.786.5536 ext. 118
  New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
  U.S.A.                        Web:    http://www.cyclone.com
___________________________________________________________________

Re: Gianfar tx-babbling-errors

[sjoyeau]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

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.coulter@cyclone.com>

>
>
> 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 yet ethtool reports non-zero
> tx-babbling-errors.  The last check appears to be the definition of
> tx-babbling-errors.  Is there a transmit path that I have missed?
>
> Scott
>
> ___________________________________________________________________
>
>  Scott N. Coulter
>  Senior Software Engineer
>
>  Cyclone Microsystems
>  370 James Street              Phone:  203.786.5536 ext. 118
>  New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
>  U.S.A.                        Web:    http://www.cyclone.com
> ___________________________________________________________________
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



-- 
------------------
Sylvain JOYEAU
Freelance Engineer
Software RT-OS R&D
sylvain.joyeau@gmail.com
Tél: +33-(0)667 477 052
"A good idea is one side of the coin. The other side is the practical
usefulness". J. Liedke.

[-- Attachment #2: Type: text/html, Size: 2679 bytes --]

Re: Gianfar tx-babbling-errors

[Kumar Gala]

On Feb 19, 2009, at 10:48 AM, sjoyeau@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.
>
> --

Take a look at TxBD[TR] and see if its getting set ever.

- k

RE: Gianfar tx-babbling-errors

[Scott Coulter]

> -----Original Message-----
> From: Kumar Gala [mailto:galak@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 length is greated than max
> > frame length.
> >
> > --
>=20
> Take a look at TxBD[TR] and see if its getting set ever.
>=20

I added two bug checks:

- one in gfar_clean_tx_ring() after the check for completed frames:

		/* see if any transmits were truncated */
		BUG_ON(lstatus & BD_LFLAG(TXBD_TR));

- one in gfar_start_xmit() at the end to check a flag to see if
TXBD_LAST never gets set.

Within a couple of minutes it bug checked in gfar_clean_tx_ring():

kernel BUG at drivers/net/gianfar.c:1826!
Oops: Exception in kernel mode, sig: 5 [#1]
CYC833-8568
Modules linked in:
NIP: c019a7b8 LR: c019a824 CTR: 00000000
REGS: c0307d50 TRAP: 0700   Not tainted  (2.6.27.6)
MSR: 00021000 <ME>  CR: 44044044  XER: 20000000
TASK =3D c02eb4a8[0] 'swapper' THREAD: c0306000
GPR00: 00010000 c0307e00 c02eb4a8 00000002 00000010 00000001 c030dc48
c0e003c0
GPR08: c0314e80 180107a8 00000000 efab6dd0 24044022 002ae6bc 0000007f
00000010
GPR16: ef84a800 00029000 ef84abec ef84abc0 00000000 00000001 00000073
000001cc
GPR24: 00100100 00000001 ef84abc0 00000400 efab7400 00000000 ef0f9f00
efab71c8
NIP [c019a7b8] gfar_poll+0xb0/0x408
LR [c019a824] gfar_poll+0x11c/0x408
Call Trace:
[c0307e00] [c019a824] gfar_poll+0x11c/0x408 (unreliable)
[c0307e50] [c01cb144] net_rx_action+0xc4/0x180
[c0307e80] [c0036404] __do_softirq+0x74/0xe0
[c0307ea0] [c0004a20] do_softirq+0x54/0x58
[c0307eb0] [c00362b0] irq_exit+0x94/0x98
[c0307ec0] [c0004acc] do_IRQ+0xa8/0xc8
[c0307ed0] [c000e40c] ret_from_except+0x0/0x18
[c0307f90] [c0007c88] cpu_idle+0x50/0xd8
[c0307fb0] [c024b220] __got2_end+0x58/0x68
[c0307fc0] [c02c5808] start_kernel+0x230/0x2ac
[c0307ff0] [c00003c4] skpinv+0x2ec/0x328
Instruction dump:
3a800000 817e0094 a32b0004 57291838 7d3f4a14 7f89e040 7d7b4850 7d295f1e
81290000 2f890000 419c0160 552003de <0f000000> 813f0000 2f190000
55290084
Kernel panic - not syncing: Fatal exception in interrupt



___________________________________________________________________

  Scott N. Coulter
  Senior Software Engineer
 =20
  Cyclone Microsystems         =20
  370 James Street              Phone:  203.786.5536 ext. 118
  New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
  U.S.A.                        Web:    http://www.cyclone.com
___________________________________________________________________

RE: Gianfar tx-babbling-errors

[Haruki Dai-R35557]

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.=20

Regards
Dai

> -----Original Message-----
> From: linuxppc-dev-bounces+dai.haruki=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+dai.haruki=3Dfreescale.com@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
>=20
>=20
> Hi all,
>=20
> 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
> processor, I stopped the builds and ran ethtool to look for any odd
> statistics.  Both processors reported non-zero values for
> tx-babbling-errors.  Both processors reported around 1300
> tx-babbling-errors out of about 80,000,000 Tx packets.  Should I be
> concerned about the tx-babbling-errors?  What conditions would cause
> these errors to be reported?
>=20
> Thanks,
> Scott
>=20
>=20
>=20
>=20
>=20
> ___________________________________________________________________
>=20
>   Scott N. Coulter
>   Senior Software Engineer
>=20
>   Cyclone Microsystems
>   370 James Street              Phone:  203.786.5536 ext. 118
>   New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
>   U.S.A.                        Web:    http://www.cyclone.com
> ___________________________________________________________________
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: Gianfar tx-babbling-errors

[Scott Coulter]

Dai,

>  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.

Yes this is our own board.  Both the 8568E and 8572E processors each
expose two TSECs.  The 4 TSECs are each connected to a separate
interface of a  Broadcom 5464 Quad PHY in RGMII mode.  I am pretty sure
that there is no interrupt connected (I'll have to check with the
hardware engineer) and I know that I didn't configure one in the DTS
file.  My kernel is configured to use the Broadcomm 54xx driver, but I'm
not sure if it polls when no interrupt is configured.

Thanks,
Scott
___________________________________________________________________

  Scott N. Coulter
  Senior Software Engineer
 =20
  Cyclone Microsystems         =20
  370 James Street              Phone:  203.786.5536 ext. 118
  New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
  U.S.A.                        Web:    http://www.cyclone.com
___________________________________________________________________

> -----Original Message-----
> From: Haruki Dai-R35557 [mailto:Dai.Haruki@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
>=20
> Hi Scott,
>=20
>=20
> Regards
> Dai
>=20
> > -----Original Message-----
> > From: linuxppc-dev-bounces+dai.haruki=3Dfreescale.com@ozlabs.org
> > [mailto:linuxppc-dev-bounces+dai.haruki=3Dfreescale.com@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 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
> > processor, I stopped the builds and ran ethtool to look for any odd
> > statistics.  Both processors reported non-zero values for
> > tx-babbling-errors.  Both processors reported around 1300
> > tx-babbling-errors out of about 80,000,000 Tx packets.  Should I be
> > concerned about the tx-babbling-errors?  What conditions would cause
> > these errors to be reported?
> >
> > Thanks,
> > Scott
> >
> >
> >
> >
> >
> > ___________________________________________________________________
> >
> >   Scott N. Coulter
> >   Senior Software Engineer
> >
> >   Cyclone Microsystems
> >   370 James Street              Phone:  203.786.5536 ext. 118
> >   New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
> >   U.S.A.                        Web:    http://www.cyclone.com
> > ___________________________________________________________________
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: Gianfar tx-babbling-errors

[Haruki Dai-R35557]

Scott,
 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).

Regards
Dai



> -----Original Message-----
> From: Scott Coulter [mailto:scott.coulter@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
>=20
>=20
>=20
>=20
> Dai,
>=20
> >  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.
>=20
> Yes this is our own board.  Both the 8568E and 8572E processors each
> expose two TSECs.  The 4 TSECs are each connected to a separate
> interface of a  Broadcom 5464 Quad PHY in RGMII mode.  I am pretty
sure
> that there is no interrupt connected (I'll have to check with the
> hardware engineer) and I know that I didn't configure one in the DTS
> file.  My kernel is configured to use the Broadcomm 54xx driver, but
I'm
> not sure if it polls when no interrupt is configured.
>=20
> Thanks,
> Scott
> ___________________________________________________________________
>=20
>   Scott N. Coulter
>   Senior Software Engineer
>=20
>   Cyclone Microsystems
>   370 James Street              Phone:  203.786.5536 ext. 118
>   New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
>   U.S.A.                        Web:    http://www.cyclone.com
> ___________________________________________________________________
>=20
> > -----Original Message-----
> > From: Haruki Dai-R35557 [mailto:Dai.Haruki@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=3Dfreescale.com@ozlabs.org
> > > =
[mailto:linuxppc-dev-bounces+dai.haruki=3Dfreescale.com@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 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
> > > processor, I stopped the builds and ran ethtool to look for any
odd
> > > statistics.  Both processors reported non-zero values for
> > > tx-babbling-errors.  Both processors reported around 1300
> > > tx-babbling-errors out of about 80,000,000 Tx packets.  Should I
be
> > > concerned about the tx-babbling-errors?  What conditions would
cause
> > > these errors to be reported?
> > >
> > > Thanks,
> > > Scott
> > >
> > >
> > >
> > >
> > >
> > >
___________________________________________________________________
> > >
> > >   Scott N. Coulter
> > >   Senior Software Engineer
> > >
> > >   Cyclone Microsystems
> > >   370 James Street              Phone:  203.786.5536 ext. 118
> > >   New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
> > >   U.S.A.                        Web:    http://www.cyclone.com
> > >
___________________________________________________________________
> > >
> > > _______________________________________________
> > > Linuxppc-dev mailing list
> > > Linuxppc-dev@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20

RE: Gianfar tx-babbling-errors

[Scott Coulter]

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 printks, I did confirm that the kernel is polling the phy
every second or so.  So, I modified the routine which reads the phy
status to hardcode the link state, speed, and duplex without actually
performing any reads and the driver still bug checks with a truncated
packet.  I also dropped a printk in phy_read() and phy_write(), but
neither function is getting called with the hard-coded link information.

In gfar_clean_tx_ring() I printed out the tx descriptor data length
field when I detected that the descriptor had the TR bit set.  For 5 bug
checks in a row, the data length field was set to 1960 (which would
definitely cause the packet truncation).  I then went back into
gfar_start_xmit() and added some additional BUG_ON() checks of the data
length field before the descriptor is handed off to the TSEC and none of
them fire.  I am wondering if somehow the descriptor is getting
corrupted, perhaps by some code with an errant pointer.

Scott=20



___________________________________________________________________

  Scott N. Coulter
  Senior Software Engineer
 =20
  Cyclone Microsystems         =20
  370 James Street              Phone:  203.786.5536 ext. 118
  New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
  U.S.A.                        Web:    http://www.cyclone.com
___________________________________________________________________

RE: Gianfar tx-babbling-errors

[Scott Coulter]

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 Jarek Poplawski gianfar: Fix boot hangs while bringing up
gianfar ethernet
2009-02-05 Andy Fleming gianfar: Fix potential soft reset race=20
2009-01-26 Anton Vorontsov gianfar: Revive VLAN support blob=20
2009-01-13 Anton Vorontsov gianfar: Fix soft lockup with multi-interrupt
TSECs=20
2009-01-11 Clifford Wolf netdev: gianfar: add MII ioctl handler=20
2009-01-08 Kumar Gala gianfar: Fixup use of BUS_ID_SIZE
2009-01-06 Li Yang gianfar: ensure ECNTRL[R100] is cleared on link state
change
2008-12-18 Andy Fleming gianfar: Continue polling until both tx and rx
are empty

I backed out the following change due to compile errors:

2008-12-23 Neil Horman net: Remove unused netdev arg from some NAPI
interfaces

I also added the following change which wasn't in the kernel.org git:

2009-02-26 Rini van Zetten: fix to prevent num_txbdfree from going
negative

I also left my BUG_ON() check in gfar_clean_tx_ring() in to look for
truncated packets.  So far I've done 3 complete kernel builds over NFS
with no tx-babbling-errors reported by ethtool and no bug checks.

Scott




___________________________________________________________________

  Scott N. Coulter
  Senior Software Engineer
 =20
  Cyclone Microsystems         =20
  370 James Street              Phone:  203.786.5536 ext. 118
  New Haven, CT 06513-3051      Email:  scott.coulter@cyclone.com
  U.S.A.                        Web:    http://www.cyclone.com
___________________________________________________________________