On Tue, Jun 15, 2010 at 2:55 PM, <casper....@sun.com> wrote:
>
>>More details:
>>
>>> $C
>>ffffff001f630da0 fuword16+0x4f()
>>ffffff001f630e10 cred2ucred+0x12b(ffffff05078c7098, 426d, 0, ffffff04e6362a88)
>>ffffff001f630e50 door_ucred+0xbe(806b770)
>>ffffff001f630ec0 doorfs32+0x78(806b770, 0, 0, 0, 0, 9)
>>ffffff001f630f10 sys_syscall32+0xff()
>>
>>> *panic_thread$<thread !grep t_procp
>> t_procp = 0xffffff04ea729e18
>>
>>> 0xffffff04ea729e18::ps
>>S PID PPID PGID SID UID FLAGS ADDR NAME
>>R 17 1 17 17 15 0x52000000 ffffff04ea729e18 dlmgmtd
>>
>>> *panic_thread::findstack
>>stack pointer for thread ffffff04ef6d4780: ffffff001f6309f0
>> ffffff001f630ae0 panic+0x94()
>> ffffff001f630b70 die+0xdd()
>> ffffff001f630c80 trap+0x177e()
>> ffffff001f630c90 0xfffffffffb8001d6()
>> ffffff001f630da0 fuword16+0x4f()
>> ffffff001f630e10 cred2ucred+0x12b()
>> ffffff001f630e50 door_ucred+0xbe()
>> ffffff001f630ec0 doorfs32+0x78()
>> ffffff001f630f10 sys_syscall32+0xff()
>>
>>Do you think it's still the same issue? If so, is there any workaround
>>for that?
>
> Boot build 128 or earlier or build 135 or later. The bug exists in builds
> 129-134, inclusive.
>
> There is no workaround.
>
> Does this happen all the time or just once?
I have got this only one time in a few days but on 2 the same machines.
> If you don't have a bootable earlier environment, you can run this
> dtrace script:
>
> dtrace -w -n '::crfree:entry,::crhold:entry /args[0]->cr_ref == 0 || args[0]->
> cr_ref == 0xdeadbeef/ { panic();}'
>
> this causes an immediate panic before anything really bad happens; it also
> allows us to make sure it is the same bug.
Nice, I will try that.
Thanks,
--
Piotr Jasiukajtis | estibi | SCA OS0072
http://estseg.blogspot.com
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
