Opened 7 years ago

Last modified 3 years ago

#8580 reopened defect

tx dma ring full on AG310

Reported by: mark@… Owned by: florian
Priority: highest Milestone: Backfire 10.03.1
Component: kernel Version: Backfire 10.03.1 RC4
Keywords: Cc:



I can flash my router using the stock AG310 (AR7) backfire RC4 binary. However, when the router boots it is not accessable via the lan ports effectively making the router useless.

Connecting a serial console to the router shows "tx dma ring full" continiously.

I can stop these errors from continuing by issuing the following:
ifconfig eth0 down
ifconfig eth0 up

However, even after issuing these commands, the router is still unaccessable via the lan.

Attached is the output of dmesg.

Attachments (1)

tx-dma-ring-full.txt (8.9 KB) - added by mark@… 7 years ago.
Dmesg output

Download all attachments as: .zip

Change History (8)

Changed 7 years ago by mark@…

Dmesg output

comment:1 Changed 7 years ago by mark@…

I should also say that kamikaze (8.09, 8.09.1 & 8.09.2) all work.

This bug seems to have crept in in the backfire (10.03 & 10.03.1) releases.

Thanks for all your good work.

Mark D

comment:2 Changed 7 years ago by KillaB

I'm pretty sure the "tx dma ring full" issue is present in ALL releases.

As for the switch not working, it's a known issue without a current fix on the Backfire branch. See ticket #7836

comment:3 Changed 7 years ago by anonymous

Actually I have been running kamikaze for about a year now with out any major problems. The problem seems to have been created in the move to the Backfire branch.

comment:4 Changed 7 years ago by jow

  • Owner changed from developers to florian
  • Status changed from new to assigned

Is this still the case with RC5 ?

comment:5 Changed 6 years ago by nbd

  • Resolution set to no_response
  • Status changed from assigned to closed

comment:6 Changed 3 years ago by nema32

  • Resolution no_response deleted
  • Status changed from closed to reopened

I get behavior like the dmesg output on my Actiontec GT701 running 2.6.32.x kernels. Kamikaze builds using 2.6.30.x worked fine. I tracked this down to the 950-cpmac_fallback_switch.patch in r20022 and related change r21307.
Removing both of these allowed any (I say any, but really only tested a few) 2.6.32.x kernels to work fine. Builds between r20022 and r21307 were DOA because no network IP was assigned and I don't have a serial connection. Builds after 21307 worked but produced a series of tx dma ring full messages constantly filling up dmesg. Also got the warning at net/sched/sch_generic.c and trace, though I don't remember any of the 'br-lan' port 1 messages possibly due to device differences.

Anyway, the crux is that for my device, removing 950-cpmac_fallback_switch.patch and changing 'eth0 eth1' to 'eth0' in target/linux/ar7/base-files/etc/config/network allowed 2.6.32.x kernels to work properly. I now have backfire shapshot r33081 working fine.

I'd like to achieve the same thing with attitude adjustment, but the network file has several devices, and the patch to modify is presuably 972-cpmac_fixup.patch which I don't see exactly what to change.

comment:7 Changed 3 years ago by anonymous

For my device, I understand the problem better now. There are two interfaces on this hardware. The error message(s) probably do indicate a bug somewhere, but they are for the "other" interface-- the one I don't care about. The solution, regardless of what patches you apply, is to set up your network config to use the right interface. On this device, you can even set an environment variable during boot to choose which interface comes first. (

So the configs that include multiple ethx and ethx.y on the iface line just need to include only the correct one to operate properly without the messages. That's easier to fix with a serial connection which I now have.

Add Comment

Modify Ticket

as reopened .

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.