in6.c and panic: 0xc63dd000 must be migratable
Bjoern A. Zeeb
bzeeb-lists at lists.zabbadoz.net
Sat Apr 9 08:16:07 UTC 2011
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.
More information about the freebsd-net
mailing list