[cisco-nas] strange MICA behaviour : Disconnect Reason Info: (0x6102)

[Aaron Leonard]

> 1st question
> ------------
> I have an AS5300 with 2 MICA modules which has ~60 success rate. The quite common
> disconnect reason is the following...DSP is the one that worries me...

All this means is that it was the DSP that decided to hang up.

>   May 18 18:02:26: Modem State event:
>                     State: Call Setup
>    May 18 18:02:26: Modem State event:
>                     State: Connect
>    May 18 18:02:26: Modem State event:
>                     State: V.8bis Exchange
>    May 18 18:02:26: Modem State event:
>                     State: Link
>    May 18 18:02:26: Modem State event:
>                     State: Train Up
>    May 18 18:02:38: Modem State event:
>                     State: Terminate
>    May 18 18:02:38: End Connect event:
>      Call Timer:  22 secs
>      Disconnect Reason Info:  (0x6102)
>         Type (=3 ):  Condition occurred during call setup
>        Class (=1 ):  DSP condition
>       Reason (=2 ):  failure in modem training up

>    May 18 17:03:55: Modem State event:
>                     State: Call Setup
>    May 18 17:03:55: Modem State event:
>                     State: Connect
>    May 18 17:03:55: Modem State event:
>                     State: V.8bis Exchange
>    May 18 17:03:55: Modem State event:
>                     State: Link
>    May 18 17:04:07: Modem State event:
>                     State: Train Up
>    May 18 17:04:19: Modem State event:
>                     State: Terminate
>    May 18 17:04:19: End Connect event:
>      Call Timer:  22 secs
>      Disconnect Reason Info:  (0x6102)
>         Type (=3 ):  Condition occurred during call setup
>        Class (=1 ):  DSP condition
>       Reason (=2 ):  failure in modem training up

>   May 18 17:18:21: Modem State event:
>                     State: Call Setup
>    May 18 17:18:21: Modem State event:
>                     State: Connect
>    May 18 17:18:21: Modem State event:
>                     State: V.8bis Exchange
>    May 18 17:18:21: Modem State event:
>                     State: Link
>    May 18 17:18:21: Modem State event:
>                     State: Train Up
>    May 18 17:18:33: Modem State event:
>                     State: Terminate
>    May 18 17:18:33: End Connect event:
>      Call Timer:  16 secs
>      Disconnect Reason Info:  (0x6102)
>         Type (=3 ):  Condition occurred during call setup
>        Class (=1 ):  DSP condition
>       Reason (=2 ):  failure in modem training up


> Should i replace the chassis or both the mica modules?

I don't see any reason why - these just look like normal modem
trainup failures.  

If "show modem" shows that certain specific modem lines have much 
lower CSR than others, then this could be a DSP problem however, since
we made it thru the V.8bis exchange phase etc. OK, it doesn't
look like it.

> 2nd question
> ------------
> Quite strangely, while issuing "sh modem call-stats" the router crashed (!) with the
> following stack info.


> Minimum process stacks:
>   Free/Size   Name
>   5672/6000   Reset ipc queue
>   5676/6000   HPI Logger
>   2512/3000   fstp init
>   2464/3000   allegro libretto init
>   5608/6000   Microcom DSP download Process
> 11296/12000  Router Init
>   8572/12000  Init
>   5424/6000   RADIUS INITCONFIG
> 10304/12000  Exec
> 10432/12000  Mica board Download

> Interrupt level stacks:
> Level    Called Unused/Size  Name
>    2        4679   7800/9000  Low IRQ Int Handler
>    3         616   8272/9000  High IRQ Int Handler
>    4        5555   8592/9000  Console Uart
>    6           0   9000/9000  Parity interrupt
>    7       25747   8600/9000  NMI Interrupt Handler

> System was restarted by bus error at PC 0x6034EB0C, address 0x20686F73
> 5300 Software (C5300-IS-M), Version 12.2(15)T9,  RELEASE SOFTWARE (fc2)
> TAC Support: http://www.cisco.com/tac
> Compiled Sat 01-Nov-03 01:30 by ccai
> Image text-base: 0x6000894C, data-base: 0x61574000


> Stack trace from system failure:
> FP: 0x648BD458, RA: 0x6034EB0C
> FP: 0x648BD510, RA: 0x6034D518
> FP: 0x648BD530, RA: 0x6017B120
> FP: 0x648BD590, RA: 0x6017B50C
> FP: 0x648BD648, RA: 0x601845D0
> FP: 0x648BD680, RA: 0x60185A08
> FP: 0x648BD698, RA: 0x6036AF68
> FP: 0x648BD6F0, RA: 0x6037DC00

> Bug-tool showed "CSCdy14558" as the possible bug, but this one doesn't refer to 12.2(15)T9
> which i'm using. Also the bug notes don't refer the ios versions where the bug is solved.

No, CSCdy14558.  If you can replicate this and are willing
to capture a core file, then open a TAC case and have the
TAC engineer reopen and link to the DDTS.

Aaron