[c-nsp] 7206 crashing when enabling LLQ on Frame-relay interface(s)

Rodney Dunn rodunn at cisco.com
Tue Feb 13 10:24:18 EST 2007 

On Tue, Feb 13, 2007 at 04:07:37PM +0100, Rolf Mendelsohn wrote:
> Hi Rodney,
> 
> The crashinfo file I sent was from the first crash. After It happened I went 
> to our NOC, rebooted the router and upgraded to 12.2.28SB6.
> 
> I re-applied the policy-map's again and got the second set of messages which I 
> sent to you in the smaller file. (none of which are in the crashinfo)

Ah ha...you forgot to mention that. No wonder my symbols decode was all
messed up. So I then just analyzed the spurious memory accesses saved in
the crashinfo.

Can you resend me the small file again and the exact IOS feature set you
had on there with SB6 and I'll decode those?

> 
> Unfortunately I don't have a crashinfo file from the second crash (I am not 
> sure why it was not saved).
> 
> Sorry I don't have proper output to debug from the second crash :>(.
> 
> Thanks to all fro the help, especially Rodney!
> 
> cheers
> /rolf
> 
> On Tuesday 13 February 2007 15:43, Rodney Dunn wrote:
> > Rolf sent me the crashinfo file offline.
> >
> > He was hitting two bugs.
> >
> > The crash is:
> >
> > CSCsg36389
> > Externally found moderate defect: Resolved (R)
> > removing of policy-map may crash the router under certain circumstances
> >
> > and the spurious acceses are:
> >
> > CSCsd19951
> > Internally found severe defect: Resolved (R)
> > Spurious access @ hqf_centralized_platform_check after sh policy-map int
> >
> >
> > both are fixed in 12.2(28)SB6.
> >
> > Rodney
> >
> > On Mon, Feb 12, 2007 at 01:31:08PM -0500, Rodney Dunn wrote:
> > > On Mon, Feb 12, 2007 at 06:19:55PM +0100, Rolf Mendelsohn wrote:
> > > > Hi Everyone,
> > > >
> > > > Thanks to those who replied off-list. To summarise 12.2SB is a new
> > > > train focusing on ISG and I should not be running it anyway.
> > >
> > > While a general suggestion for IOS release selection is always
> > > good that doesn't justify a bug in our code that makes a device
> > > reload. That's something we should fix regardless.
> > >
> > > > For those who are interested I also found the bug under bug toolkit:
> > > >
> > > > CSCea72991 Bug Details
> > > >
> > > >   Headline   E1/T1 on VIP: %SYS-2-QCOUNT: Bad deqeueue
> > > >   Product   IOS
> > > >   Feature   QOS   Duplicate of
> > > >   Severity   2  Severity help  Status   Resolved  Status help
> > > >   First Found-in Version   12.2(16)   All affected versions   First
> > > > Fixed-in Version   12.0(23)S04, 12.2(17.7)S, 12.0(25.3)S01, 12.3(2.1),
> > > > 12.2(17.8), 12.1(19.2)E, 12.1(19)E02, 12.3(3.1)T, 12.0(24)S03,
> > > > 12.2(15)T07, 12.3(2.3)B, 12.2(15)ZK01, 12.0(25)S02, 12.0(25)SX02,
> > > > 12.0(27)SV, 12.3(7)XI  Version help Release Notes
> > >
> > > That can't be the right bug because it was fixed in 12.2(17.7)S which
> > > is years before 12.2(28)SB code.
> > >
> > > Please open a TAC case and provide the logs, configuration, and 'sh ver'
> > > so they can decode those messages. It will probably be pretty easy to
> > > find with that information.
> > >
> > > Rodney
> > >
> > > > cheers
> > > > /rolf
> > > >
> > > > On Sunday 11 February 2007 20:21, Rolf Mendelsohn wrote:
> > > > > Hi Guys,
> > > > >
> > > > > I have a 7200 doing a bit of MPLS / routing, frame-relay FR.12
> > > > > fragmentation and now I wanted to add LLQ for prioritising traffic.
> > > > >
> > > > > However the router keeps crashing with traceback errors, i have
> > > > > tested on 12.2.28-SB4 and 12.2.28SB6
> > > > >
> > > > > I was wondering if anybody had come across the following:
> > > > >
> > > > > Feb 11 17:52:59.301 UTC: %SYS-2-QCOUNT: Bad deqeueue 63EF09D8 count 1
> > > > > -Process= "<interrupt level>", ipl= 1
> > > > > -Traceback= 60888024 60A0FF98 60A269C4 601B24BC 6051979C 6051CCE8
> > > > > 6051CFB4 Feb 11 17:52:59.305 UTC: %SYS-2-QCOUNT: Bad deqeueue
> > > > > 63EF09D8 count 0 -Process= "<interrupt level>", ipl= 1
> > > > > -Traceback= 60888024 60A0FF98 60A269C4 601B24BC 6051979C 6051CCE8
> > > > > 6051CFB4 pe1.wdh1.na#
> > > > > Feb 11 17:53:00.641 UTC: %SYS-2-QCOUNT: Bad deqeueue 63EF09D8 count 0
> > > > > -Process= "<interrupt level>", ipl= 1
> > > > > -Traceback= 60888024 601206D4 6069814C 606CF504 605BE7C8 605BCFD4
> > > > > 6191D28C 601AF678 6051979C 6051CCE8 6051CFB4
> > > > >
> > > > > I will try and open a TAC case tommorrow, but am really in a hurry to
> > > > > try and get this finished.
> > > > >
> > > > > If the problem is frame-relay related then perhaps i should swap to
> > > > > Mulitilink PPP?
> > > > >
> > > > >
> > > > > The config is below:
> > > > >
> > > > > policy-map mpls-qos
> > > > >  description Set a General Backbone QoS policy
> > > > >   class qos1
> > > > >     priority percent 20
> > > > >   class qos2
> > > > >     bandwidth percent 30
> > > > >   class class-default
> > > > >     fair-queue
> > > > >
> > > > > class-map match-any qos1
> > > > >   description Critical Class
> > > > >   match mpls experimental topmost 5  6  7
> > > > >   match ip precedence 5  6  7
> > > > > class-map match-any qos2
> > > > >   description Priority class
> > > > >   match mpls experimental topmost 1  2  3  4
> > > > >   match ip precedence 1  2  3  4
> > > > >
> > > > > pe1.wdh1.na#sh mpls interfaces
> > > > > Interface              IP            Tunnel   BGP Static Operational
> > > > > FastEthernet0/1        Yes (ldp)     No       No  No     Yes
> > > > > Serial5/2              Yes (ldp)     No       No  No     Yes
> > > > > Serial6/0:0            Yes (ldp)     No       No  No     Yes
> > > > > Serial3/0:2.1          Yes (ldp)     No       No  No     Yes
> > > > > Serial3/0:5.1          Yes (ldp)     No       No  No     Yes
> > > > > Serial3/0:6.1          Yes (ldp)     No       No  No     Yes
> > > > > Serial3/0:7.1          Yes (ldp)     No       No  No     Yes
> > > > > Serial3/0:8.1          Yes (ldp)     No       No  No     Yes
> > > > > Serial3/0:10.1         Yes (ldp)     No       No  No     Yes
> > > > > Serial3/2:2.1          Yes (ldp)     No       No  No     Yes
> > > > > Serial3/5:0.1          Yes (ldp)     No       No  No     Yes
> > > > >
> > > > >
> > > > > I Have a couple of interfaces running MPLS, configured as such:
> > > > >
> > > > > interface Serial3/0:2
> > > > >  description 128k  Backbone link to Town B PoP
> > > > >  mtu 1516
> > > > >  bandwidth 128
> > > > >  no ip address
> > > > >  encapsulation frame-relay IETF
> > > > >  frame-relay lmi-type ansi
> > > > >  frame-relay intf-type dce
> > > > >  frame-relay fragment 192 end-to-end
> > > > > end
> > > > > !
> > > > > interface Serial3/0:2.1 point-to-point
> > > > >  description 128k  Backbone link to Town A PoP
> > > > >  bandwidth 128
> > > > >  ip address X.Y.Z.71 255.255.255.254
> > > > >  mpls ip
> > > > >  no cdp enable
> > > > >  frame-relay interface-dlci 206
> > > > > end
> > > > >
> > > > > cheers
> > > > > /rolf
> > > >
> > > > _______________________________________________
> > > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > archive at http://puck.nether.net/pipermail/cisco-nsp/

More information about the cisco-nsp mailing list