On Fri, 8 Apr 2011, Doug Barton wrote:
On 04/08/2011 17:57, Bjoern A. Zeeb wrote:
similar to what?
We're seeing the "must be migratable" part of the panic, but nothing else.
Ok.
panic: 0xc63dd000 must be migratable
cpuid = 1
panic: 0xc63dd000 must be migratable
cpuid = 1
panic: 0xc63dd000 must be migratable
cpuid = 1
panic: 0xc63dd000 must be migratable
cpuid = 1
panic: 0xc63dd000 must be migratable
cpuid = 1
panic: 0xc63dd000 must be migratable
cpuid = 1
panic: 0xc63dd000 must be migratable
cpuid = 1
This is the bit we see. Breaking to the debugger hasn't worked, and dumping
is not an option (I inherited this system, trying to get it tuned up now).
...
Depsite being in the subject that's just follow-up problems, though
thinking about it (very wild guess) -- how many cores do you have and are
you
running with flowtable enabled?
It's an SMP system, and yes, FLOWTABLE was in the kernel config. I took that
out, and got the KDB options sorted out so that if it happens again hopefully
I can get a stack trace. Thanks for the FLOWTABLE suggestion, wish I'd
remembered that one myself. :)
Flowtable is one of the things in the network stack that I could think
of that would do the sched_bind() dance. Thinking of the above in the
context of 'but nothing else' it could really be anything.
The pointer printed there is a struct thread *.
show allpcpu
show thread
show thread <address given>
bt
will probably be a good start. I hope you have a serial console. Try to
get a coredump as well if you can.
/bz
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
