Solved - problem was with the s390x implementation of copystr that is used by
pn_get_buf().
This message posted from opensolaris.org
___
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opens
* snow <[EMAIL PROTECTED]> [2007-05-23 23:46]:
> When I use some command within MDB,I got error:
> >::showrev
> mdb:invalid command '::showrev':unknow dcmd name.
::showrev is in both the kvm and proc targets (at least), so I suppose
the next question is: what's the output of ::status? (The a
> I imagine there might be a reason for this zigzagging
> between C and assembly and this myriad of function
> pointers being called everywhere, though this is too
> much for me to digest at once :-)
It's historical. _locore_start was long ago the
kernel entry point. Then krtld and modules
were in
Further analysis shows the following call in devi_config_one fails as the
ramdisk dev_ops has a null bus_ops field. Now I'm assuming because this works
on i86 there's something not configured correctly on my system.
if (!NEXUS_DRV(ddi_get_driver(pdip)))
return (NDI_FAILU
2007/5/24, Eric Saxe <[EMAIL PROTECTED]>:
Thomas De Schampheleire wrote:
>
> All calls to dispdeq() are immediately followed by a call to either
> setfrontdq() or setbackdq(). Only in one place is this not the case:
> in the swapout() function. If I understand correctly, this will swap a
> proces
