Re: Analyzing "panic" Alexander Skwar <usenet@alexander.skwar.name> writes:
> · James Carlson <james.d.carlson@sun.com>:
>
> > Alexander Skwar <alexander@skwar.name> writes:
> >> >> 000002a100b4f0a1 fop_inactive+0x54(300407b9700, 60000c03d98, 1205800,
> >> >> 657700646204ed, 180c000, 60014875980)
> >> >> 000002a100b4f151 dounmount+0xbc(60009ca95c0, 0, 0, 2, 300407b9700, 1)
> >> >> 000002a100b4f201 umount2+0x140(26df8, 0, ffbfff38, 11aac, 0, 0)
> >> >> 000002a100b4f2e1 syscall_trap32+0xcc(26df8, 0, ffbfff38, 11aac, ff36e308,
> > [...]
> >> struct vfs *v_vfsp = 0x60014875980
> >
> > Try doing a "0x60014875980::whatis" in mdb. If it says that this
> > buffer was freed, then I think you've hit CR 6564619.
>
> adm@winds02 /pool/savecore $ echo '0x60014875980::whatis' | sudo mdb -k 0
> 60014875980 is 60014875980+0, freed from kmem_alloc_192
>
> I suppose during an init 6, a forced unmount is being done, right?
It can be, yes.
--
James Carlson, Solaris Networking <james.d.carlson@sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 |