SPA122 - Memory Leak & Eventual Lock-Up

caseyl1997 · ‎09-09-2015

I'm working with a SPA122 that has both lines (successfully) registered, and it performs as expected in almost every way.

It is running on 1.3.5p firmware.

After about 3-5 days of service, the unit will lock up completely. A reboot is the only solution at that point.

All the LEDs are still lit, but there is no dial tone and no response from the web GUI.

I first turned on the general syslog messaging and saw this repeating line:

08-21-2015 21:22:24 Local0.Info 192.168.15.1 tpError at [SIP_tsCreateClient:1817]

08-21-2015 20:32:19 Local0.Info 192.168.15.1 tpError at [SIP_tsCreateClient:1817]

08-21-2015 19:42:15 Local0.Info 192.168.15.1 tpError at [SIP_tsCreateClient:1817]

08-21-2015 18:52:10 Local0.Info 192.168.15.1 tpError at [SIP_tsCreateClient:1817]

Every now and then I also see one of these:

09-04-2015 16:15:28 Local0.Info 192.168.15.1 tpError at [SIP_tsCreateServer:2318]

I can't find much at all on the meaning of the CreateClient error and nothing at all on the CreateServer.

Continuing on, I also turned on the debug logs.

I picked up on the memory status lines. The MemFree value steadily declines after a boot up like this:

Sep 9 10:52:49 (Hostname) daemon.info system[134]: MemFree: 8852 kB
Sep 9 10:57:52 (Hostname) daemon.info system[134]: MemFree: 8764 kB
Sep 9 11:02:56 (Hostname) daemon.info system[134]: MemFree: 8776 kB
Sep 9 11:07:59 (Hostname) daemon.info system[134]: MemFree: 8756 kB
Sep 9 11:13:03 (Hostname) daemon.info system[134]: MemFree: 8792 kB
Sep 9 11:18:06 (Hostname) daemon.info system[134]: MemFree: 8692 kB
Sep 9 11:23:09 (Hostname) daemon.info system[134]: MemFree: 8708 kB
Sep 9 11:28:16 (Hostname) daemon.info system[134]: MemFree: 8664 kB
Sep 9 11:33:19 (Hostname) daemon.info system[134]: MemFree: 8712 kB
Sep 9 11:38:22 (Hostname) daemon.info system[134]: MemFree: 8608 kB

Then, when the memory gets extremely low, the unit locks up.

From looking at past discussions, it looks like others have had memory leak problems with the SPA122.

However, most of them were couple of years back, and a firmware upgrade was the suggested action.

As stated at the top, my device is running 1.3.5(004p). There is an XU version and a 1.4.0, but both release notes say they're identical to 1.3.5p except for one (unrelated) change.

It would seem the repeating tpErrors and memory leak are related.

Would anyone have a suggestion?

Thanks Very Much!

Dan Lukes · ‎09-09-2015

Quick and blind shot - if you are using names in proxy configuration, replace it by IP address.

Well, I assume I missed, thus more serious response follow.

------------------

Well, if you trust the Release Notes, the you can use 1.4.0 as it's the same. I don't trust Release Notes as much as you (in advance I don't trust 1.4.0 has been used instead of 1.3.5q or 1.3.7 just because "nothing important has changed"), thus I recommend the 1.4.0 to you.

All at all, yours chances someone at Cisco will look at it will be higher with the most recent firmware version.

Would anyone have a suggestion?

Not sure what king of suggestion you are wishing for. If your analysis is correct then new firmware will solve the issue only. This is volunteer community, we can provide no firmware to you. Call SMB Support Center, explain issue to them, follow their instructions. You will receive ticket number. Then you can wish for solution. Unfortunately, it may take months or you may no receive feedback at all.

So what in the mean time ? The memory leak should be related to particular configuration or feature turned on. This start with simplest configuration possible. Then, step by step, turn on features you require. Try to isolate the feature causing memory leak. If you found the one, then we can try to find a workaround. Also, if you will identify the cause in your's bug report, the chances it will be solved in a further release will increase.

Well. Such kind of analysis will take a lot of time.

So what in the mean time ? Assuming you are not debugging on production device but on a test device, just trigger production device reboot periodically. You can use SIP NOTIFY or HTTP method. If device lock's once per 3-5 day you can reboot it once per 24 hours to maintain reliable operation.

-------

Note there's volunteer's forum only. Don't expect Cisco become aware about the issue because you reported it here.

caseyl1997 · ‎09-09-2015

Thanks Dan,

I had read an old post that suggested using the IP instead of a name. I've had that change made for a little while, but that is a good suggestion.

You're probably right about the Release Notes. There may be more to each new version than what is listed (good or bad).

If the new(est) firmware 1.4.0 doesn't work, I'll go back and turn each feature off one at a time like you say.

I also have a case open now.

Depending on the company, feedback from other users is just as good or better than from vendor support.

We'll see what they say after I upgrade.

Thanks again!