FreeBSD 10-STABLE/sparc64 panic

[CARTWRIGHT, CORY C]

To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe at freebsd.org"

-----Original Message-----
From: owner-freebsd-sparc64 at freebsd.org [mailto:owner-freebsd-sparc64 at freebsd.org] On Behalf Of Craig Masse
Sent: Thursday, October 02, 2014 9:42 AM
To: John-Mark Gurney; Chris Ross
Cc: freebsd-sparc64 at freebsd.org
Subject: Re: FreeBSD 10-STABLE/sparc64 panic

REMOVE ME FROM YOUR MAIL LIST............ PLEASE !!!!!!!!!!!

--------------------------------------------
On Thu, 10/2/14, Chris Ross <cross+freebsd at distal.com> wrote:

 Subject: Re: FreeBSD 10-STABLE/sparc64 panic
 To: "John-Mark Gurney" <jmg at funkthat.com>
 Cc: freebsd-sparc64 at freebsd.org
 Date: Thursday, October 2, 2014, 8:36 AM
 
 
 On Oct
 1, 2014, at 22:53 , Chris Ross <cross+freebsd at distal.com>
 wrote:
 > On Sep 29, 2014, at 00:22 ,
 John-Mark Gurney <jmg at funkthat.com>
 wrote:
 >> If you could get a core dump
 (call doadump) that'd be good, but dumping
 >> the stack of the tid that held the
 spinlock too long would be a good
 >>
 start..
 > 
 >  I fear
 I'm going to need some help doing this.  I'm not
 sure what I need to
 > do to get into
 ddb.  (And, after that, I'm not sure how to dump the
 stack of
 > the tld that held the
 spinlock)
 
   Okay.  I
 rebuilt GENERIC after adding options DDB, and found the
 following:
 
 spin lock
 0xc0ccbdb0 (smp rendezvous) held by 0xfffff8000559f6d0 (tid
 100351) too long
 timeout stopping cpus
 panic: spin lock held too long
 [...]
 db> thread 100351
 [ thread pid 299 tid 100351 ]
 sched_switch+0x3e0:     call   
         cpu_switch
 db> thread   
    
 [ thread pid 299 tid 100351
 ]
 sched_switch+0x3e0:     call 
           cpu_switch
 db> bt
 Tracing pid 299 tid 100351 td
 0xfffff8000559f6d0
 mi_switch() at
 mi_switch+0x19c
 critical_exit() at
 critical_exit+0x9c
 spinlock_exit() at
 spinlock_exit+0x8
 turnstile_chain_unlock()
 at turnstile_chain_unlock+0x6c
 __mtx_unlock_sleep() at
 __mtx_unlock_sleep+0x9c
 bge_init() at
 bge_init+0x5c
 ether_ioctl() at
 ether_ioctl+0x70
 M_PLIMIT() at
 M_PLIMIT+0x8
 db> dump
 Cannot dump: no dump device specified.
 db> 
 
  
 Apparently, I don't have a dump device set, so I'll
 to fix that next and get a
 core dump. 
 I'm not sure, however, if what I provided above was the
 stack of
 the tid as was requested.  At
 least, it's not 100% consistent.  Since I had a
 DDB kernel running, while trying to get the
 system back up to multiuser, I did
 get many
 more panic's to experiment with, and doing the same
 "thread NNN", "bt" on many
 passes I sometimes got different results.
 Perhaps I'm doing something wrong?  Or
 worse, it may not be 100%
 consistent. 
 :-/
 
   A pointer to what I
 need to do within ddb would be appreciated, if I'm
 doing anything wrong (or suboptimmally), or any
 other instructions. I'll try
 to get a
 dump device specified.
 
  
 Thanks.
 
               -
 Chris
 
 
 
 
 
 _______________________________________________
 freebsd-sparc64 at freebsd.org
 mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
 To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe at freebsd.org"
 
_______________________________________________
freebsd-sparc64 at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe at freebsd.org"