Modify

Opened 10 years ago

Closed 9 years ago

#2393 closed defect (fixed)

ar7-port and ethernet / modem crashing

Reported by: brian@… Owned by: florian
Priority: normal Milestone:
Component: kernel Version:
Keywords: Cc:

Description

I am having a difficult time keeping my Actiontec GT-701 modem running for extended periods of time. My modem is based on the TNETD7300. I didn't have any stability issues with the 2.6.21.5 kernel, but since the ar7 has been ported to the 2.6.22 kernel I've had stability issues with it. The problem seems to occur when there is a lot of data being received on the ethernet over an extended period of time. Not only does that seem to trigger it, but the forwarding of bad UDP packets appears to exacerbate the problem. The modem gets heavy traffic through out the day as the connection is shared. I've had the modem crash after five hours to seven days. I haven't gotten it to last more than seven days though. This has been tested and confirmed on subversion snapshot 8776. The current setup of the modem is to set the ip address on the eth0 the same as ppp0 and turn on ip forwarding. This makes the modem run as a router essentially. There are no iptables rules loaded into the kernel. The modem crashes with just these modules loaded:

sch_htb 16160 2
sch_red 5312 0
sch_sfq 5184 0
sch_hfsc 17120 0
pppoatm 4448 1
ppp_async 11616 0
ppp_generic 26880 6 pppoatm,ppp_async
slhc 6176 1 ppp_generic
crc_ccitt 1472 1 ppp_async
br2684 7312 0
atm 48528 5 tiatm,pppoatm,br2684

I've changed the scheduler for packets to the htb scheduler to better balance traffic through the modem.

Attachments (1)

.config (50.1 KB) - added by brian at rapsure.net 10 years ago.
config file for actiontec gt701

Download all attachments as: .zip

Change History (13)

comment:1 follow-up: Changed 10 years ago by nabcore

Is there anything unusual in the dmesg output during normal operationf and/or before it crashes?

comment:2 in reply to: ↑ 1 ; follow-up: Changed 10 years ago by brian@…

Replying to nabcore:

Is there anything unusual in the dmesg output during normal operationf and/or before it crashes?

During operation the only kernel messages have been regarding eth0 error, resetting. The latest snapshot got an unhandled irq message from a driver. I'll need to reflash to get the irq error, but it was freezing before that error message began to show.

comment:3 in reply to: ↑ 2 Changed 10 years ago by brian at rapsure.net

Replying to brian@rapsure.net:

Replying to nabcore:

Is there anything unusual in the dmesg output during normal operationf and/or before it crashes?

During operation the only kernel messages have been regarding eth0 error, resetting. The latest snapshot got an unhandled irq message from a driver. I'll need to reflash to get the irq error, but it was freezing before that error message began to show.

I believe I have solved the issue. I reflashed to the newest svn snapshot, and also wired the serial port to my computer so that I could fix it when the flash didn't go well. The module kaodv kept the eth0 talking. The only thing that would happen is the device would respond with arp packets saying it was there, but nothing was occurring. After I removed the module eth0 began talking again. I'll be watching to make sure that the network doesn't crash in the next 20 days. If it does I have the life line attached to the modem so I can get what the crash was.

comment:4 follow-up: Changed 10 years ago by brian at rapsure.net

After a few hours of operation the modem rebooted itself. The reboot might be related to this:

WARNING: at kernel/softirq.c:138 local_bh_enable()
Call Trace:
[<94109748>] dump_stack+0x8/0x34
[<941290ec>] local_bh_enable+0x50/0xa8
[<c021c4c0>] tn7atm_receive+0x154/0x200 [tiatm]
[<c021a54c>] tn7sar_process_unmatched_oam+0x2ac/0x34c [tiatm]

This message appears after the first ppp connection is established.

comment:5 Changed 10 years ago by brian at rapsure.net

I was able to trigger the reboot on the modem. The last message from the kernel was:
KERNEL: assertion (!atomic_read(&skb->users)) failed at net/core/dev.c (1730)

About 30sec later the modem rebooted, and when the modem loaded again the firmware for the dsl would not load anymore. I had to reload the firmware to get the internet working again.

comment:6 in reply to: ↑ 4 Changed 10 years ago by nabcore

Replying to brian at rapsure.net:

After a few hours of operation the modem rebooted itself. The reboot might be related to this:

WARNING: at kernel/softirq.c:138 local_bh_enable()
Call Trace:
[<94109748>] dump_stack+0x8/0x34
[<941290ec>] local_bh_enable+0x50/0xa8
[<c021c4c0>] tn7atm_receive+0x154/0x200 [tiatm]
[<c021a54c>] tn7sar_process_unmatched_oam+0x2ac/0x34c [tiatm]

This message appears after the first ppp connection is established.

I don't think it's related to this warning. I'm seeing this as well (#2377) but not having any issues with the unit rebooting.

Changed 10 years ago by brian at rapsure.net

config file for actiontec gt701

comment:7 Changed 10 years ago by brian at rapsure.net

I added my config file hoping that perhaps I have something in there wrong. However I have in the past stripped it down to nearly nothing and the modem has still crashed.

comment:8 Changed 10 years ago by nabcore

The correlation with high Ethernet traffic may suggest that this could this have been #2791. Can you retry with the latest trunk?

comment:9 Changed 10 years ago by matteo

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

comment:10 Changed 9 years ago by anonymous

any updates on this issue?

comment:11 Changed 9 years ago by florian

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

comment:12 Changed 9 years ago by florian

  • Resolution set to fixed
  • Status changed from new to closed

I assume we have this fixed now.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.