j
: Next unread message k
: Previous unread message j a
: Jump to all threads
j l
: Jump to MailingList overview
On 06/04/13 09:27, Artyom Tarasenko wrote:
Unfortunately it's not as helpful as it became under Solaris 2.6+ :
kadb> :c OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 OFMEM: ofmem_map_page_range fef65000 -> 006f77000 00001000 mode 000000bc Begin traceback... sp = f0186b20 Called from ffc017cc, fp=f0186b80, args=9 f013f870 f013f874 0 200 0 Called from f013f83c, fp=f0186c08, args=f01e4000 1 f01e2bf0 fd020000 f0186d88 f01e2ff4 Called from f0140a38, fp=f0186c68, args=f01e563c 1cc5 f01e5652 ff000008 ff000008 4400fe1 Called from f0054f44, fp=f0186cc8, args=f0186d8c 22 ffffffff a f0186d8c 22 Called from f0054724, fp=f0186d28, args=f0186d8c 22 5 0 ffffffff 0 Called from f0054494, fp=f0186e18, args=f01e2173 f0186ec0 5 0 f0186e10 0
^^^^^^^^
From memory the 0xf005... address range in Solaris 8 was used for dynamic kernel modules. So I'd start using kadb/remote GDB to poke around 0xf0054494 in memory until you find some strings that can help you identify which module it is for clues.
BTW does "boot disk -v" give you any suitable output now?
ATB,
Mark.