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