[oi-dev] [OpenIndiana-discuss] Sun/Oracle China's DRM//KMS Sol11.2 port backported to function on old-style gfxp_private from pre-2010 era but still immediatedly PANICS

[Мартин Бохниг]

Hey Randy!


I could hardly believe what I just saw  :)
I thank you from the bottom of my heart (also in the name of the overall hardcore OpenSolaris community) for taking the time to deal with us here :)

These thanks also go to Alan because presumably he helped in making you aware of my appeal for help.
Sadly I can only continue on all these OpenSolaris related matters after Wednesday.
I'm online only for a minute.

But be sure that I release all the long promised things already mentioned directly afterwards, after Wednesday asap in accord speed:

{
#0.) last week's KMS diffs, to be created 
#1.) Thunderbird42 diffs and bins pkg for x86
#2.) and cpu related kernel diffs for Illumos developed in 2013 allowing the Flash-Plugin 11.x to function, 
#3.) plus the cw for userland [at the end of the mentioned series, because it has the smallest priority to non-OpenSXCE distros]
}

What you suggested sounds great (that a new port is on the horizon, even making it simpler for us here in the future to upgrade the code directly from LinUX git).

Your other outlined sugegstions and steps are also correctly hitting the nail.
I already walked through the steps you mentioned. Because without implementing such mempools myself (and I'm not enrtirely sure in which way your calls to it expect it to be implemented) I cannot use mempools on Illumos anyway, because according to S11.3's gfx_private.h they were implemented in a file now belonging to the misc/amd64/gfx_private submodule which does not even exists at all on Illumos: gfxp_bitmap.c

So this having said I didn't have any other option (while continuing to avoid implementing such mempools myself [which is, as you say, not a recommened idea anyway]). That's why I already did perform the steps you suggsted last week.
It works great without all newer Sol11.1++ functions and structs, only - although there is no reason - on earlier releases (S11.0 and Illumos) it instatly causes a TRAP and panics the host, leaving even Xorg.log.0 empty (not yet written to disk).
Booting into the kernel debugger shows the backtrace, as explained last week in the following link, 2 lines deeper:

Last week I announced that lucky/sad success/but_not_on_11.0_or_Illumos status and maybe you didn't see it, because here was quite some activity on this list:  
http://openindiana.org/pipermail/oi-dev/2015-November/003858.html
(sorry for the numerous spelling errors)


Once again: Your post really gives me hope we soon get it functioning.
I think we are less than one line of code apart from having it working also on S11.0 and Illumos.

Of yourse I'm glad to year that you take the time to analyse the dump.
Normally such things are doable, but in this case I failed.

I publish the dump files (several, also from S11.0) - although the problem always happens at the same point and looks identical - and the bins plus src diffs directly in about 48 hours.
I could attach the bins right now, but I'm afaraid it is some later version I messed with and recompiled.
Therefore it is certainly better to do this slowly and completely, in a proper release in 2 days.
Fortunately I took snapshots at each milestone.


Once again:  THANK YOU    http://us.123rf.com/450wm/mybaitshop/mybaitshop1202/mybaitshop120200066/12701366-thank-you-word-cloud-concept-with-great-terms-in-different-languages-such-as-merci-mahalo-danke-grac.jpg




cheers!

%mb



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20151201/f3676ed6/attachment-0001.html>