03-05-2013 06:30 AM - edited 03-18-2019 12:43 AM
We see that few of our E20's - most of them on internet hangs as soon as the endpoint is booted.
If the endpoint is booted without network cable, then the E20 is stable.
If the SIP configuration is removed, the E20 is stable.
As soon as we put in the SIP config and the E20 is registering over SIP, the device hangs.
We can see from root that the Tandberg application to fail - tsh from root cli says "unable to connect application"
Is this a known issue with TE4.1.1.
If we disable SIP and use only H323 - device is stable.
VCS - X7.2.1
Solved! Go to Solution.
03-07-2013 02:01 AM
Hello,
the logfiles you sent from the E20 show an issue with the Marvell chip which is an ethernet controller inside the E20.
Feb 26 07:59:02 (none) main: FPGA programmed OK
Feb 26 07:59:02 (none) main: marvell.c: ioctl(9, -2146669310, ...)==-1, errno==14, Bad address
Feb 26 07:59:02 (none) main: platform/marvell/marvell.c:132: marvell_ioctl: Assertion `0 && "Marvell ioctl Failure"' failed.
Feb 26 07:59:02 (none) main: Received signal SIGABRT (6) in thread 0x4082a4c0, TID 1704
Feb 26 07:59:02 (none) main: Registers:
Feb 26 07:59:02 (none) main: R0: 00000000 R1: 000006a8 R2: 00000006 R3: 000006a8
Feb 26 07:59:02 (none) main: R4: 00000006 R5: 40826bdc R6: 40826000 R7: 0000010c
Feb 26 07:59:02 (none) main: R8: 00000bdc R9: 00000000 R10: 4082a4c0 FP: be976974
Feb 26 07:59:02 (none) main: PC: 407206f8 IP: be976978 SP: be97695c LR: 407206c4
Feb 26 07:59:02 (none) main: ERR: 00000000 CPSR: 20000010 FAULT: 00000000 TRAP: 00000000
Feb 26 07:59:02 (none) main: OLDMSK: 00000000
Our defect tracking system is down, so could not find a matching ddts for this, but to me, this looks like hardware.
Will verify with engineering.
The recent change you talk about can cause E20s to crash. There's a defect open on this :
CSCue59199 - Boot: SIPAUTH error: unable to clear signature (gState=1)
When we get challenged on a SIP presence subscribe message, the E20 crashes. When that happens you will see a message like "Authorization to SUBSCRIBE got proxy-challenged in 407 SUBSCRIBE".
Now the historical logfiles you sent for the specific E20 does not match that ddts. Do you have other E20s crashing when you enable SIP? If so, can you send the historical logfiles of such a device which now no longer crashes with SIP disabled?
Below is the sequence prior to the crash.
Could you collect some SIP debugs and try enable SIP on 1 E20 please?
From the tsh do :
log ctx sippacket debug 9
When the unit crashes, disable SIP again and forward the logfiles to verify.
Mar 3 11:43:43 (none) main: User admin(1001) successfully executed command '/Presence/Subscribe/Start URI: 91000001' from sweet-brew-7.cisco.com.
Mar 3 11:43:43 (none) main: 8241.76 SipStack I: SipEv: Active Subscribe to '
' of type 'presence', unsolicited=0
Mar 3 11:43:43 (none) main: 8241.76 SipStack I: SipUa GRUU added OK
Mar 3 11:43:43 (none) main: 8241.77 SipPacket PacketDump: Proto: SIP, Name: SUBSCRIBE
SIP/2.0, Direction: Outgoing, RemoteAddress: 10.106.93.69:5061, GroupEntity:
, Time: 8241765, Content: !!!<
Mar 3 11:43:43 (none) main: 8241.77