On 03/18/09 11:21, Tom Whitten wrote:
> Tom Whitten writes:
>
>> My panic seems to be of a different nature. First of all, I'm running on a
>> several years old Dell Inspiron 600m. It is a single x86 CPU running at
>> 1.6 GHz with 2 GB of memory. Here is the output of mdb's ::msgbuf command
>> on the crash dump.
>>
>> kernel memory allocator:
>> buffer freed to wrong cache
>> buffer was allocated from kmem_alloc_128,
>> caller attempting free to kmem_alloc_96.
>> buffer=d1d714c0 bufctl=0 cache: kmem_alloc_96
>>
>> panic[cpu0]/thread=d0dd1dc0:
>> kernel heap corruption detected
>>
>>
>> d0dd1c68 genunix:kmem_error+483 (3, cfc3f018, d1d714)
>> d0dd1ca8 genunix:kmem_slab_free+316 (cfc3f018, d1d714c0,)
>> d0dd1ce8 genunix:kmem_magazine_destroy+c2 (cfc3f018, d46c8f80,)
>> d0dd1d18 genunix:kmem_depot_ws_reap+58 (cfc3f018, d0d9ce88,)
>> d0dd1d48 genunix:kmem_cache_reap+7e (cfc3f018, d7eec420)
>> d0dd1da8 genunix:taskq_thread+192 (d0d9ce68, 0)
>> d0dd1db8 unix:thread_start+8 ()
>>
>> syncing file systems...
>> done
>> dumping to /dev/zvol/dsk/reservoir/dump, offset 65536, content: kernel
>>
>>
>> I can make the crash dump available if anyone is interested after I finish
>> uploading it onto the swan.
>>
>> tom
>>
>
> Crash dumps are at /net/boora.central/brmnas/tw21770/crash. Also, $c shows
> this stack trace:
>
> vpanic(fea983ac, d1d714c0, 0, cfc3f078)
> kmem_error+0x483(3, cfc3f018, d1d714c0, fe945e00)
> kmem_slab_free+0x316(cfc3f018, d1d714c0, d16de840, cfc22150)
> kmem_magazine_destroy+0xc2(cfc3f018, d46c8f80, 7, fe945dc2)
> kmem_depot_ws_reap+0x58(cfc3f018, d0d9ce88, d0dd1d48, fe9f7309)
> kmem_cache_reap+0x7e(cfc3f018, d7eec420)
> taskq_thread+0x192(d0d9ce68, 0)
> thread_start+8()
>
> If you think that this is all unrelated to the bug that you guys are
> tracking, please let me know. I'll file a separate bug in that case.
>
> tom>
If this is reproducible, please set turn on kernel memory debugging.
Add the "-k -d" flags to the end of the grub entry's $kernel line and boot.
When boot stops in kmdb type:
::kmem_debug
$c
Please file a bug.
This buffer does not look like a cpu_acpi_cstate_t structure:
> d1d714c0 ::print -a cpu_acpi_cstate_t
{
d1d714c0 cs_addrspace_id = 0
d1d714c4 cs_address = 0
d1d714c8 cs_type = 0xd3a411e8
d1d714cc cs_latency = 0x1
d1d714d0 cs_power = 0x16
d1d714d4 promotion = 0
d1d714d8 demotion = 0x79df5b40
d1d714dc cs_ksp = 0x67a
Thank you,
Bill
