[oi-dev] 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

Fri Nov 27 18:43:29 UTC 2015

Hello after a short long week of 18-20 hour days busy with what I wanted to publish here as one of the next success stories.

sorry I couldn't check a single e-mail nor follow any activities on any mailing list nor thank anybody for the 3 (as it looks now) further donations that arrived on my paypal account as I just see. I also didn't leave this room for the same time, except once for food.
It is like in hell, because I cannot get across these panics on 11.0 and earlier.

Sorry also that I could not read or respond to a single other (non-public) email.
This only as a FYI to notify you that I'm still with OI/DilOS/OpenSolaris/OpenSXCE/Illumos as promised.

I sucessfully backported https://java.net/projects/solaris-x11/sources/x-s12-clone/show/open-src/kernel?rev=1586 to live without mempools and without the newer interfaces intrudoced in 11.1++'s gfxp.

To get drm_gem_create_mmap_offset() working without the presence of gfxp_alloc_kernel_space() which was introduced in 11.1 I needed to implement gfxp_alloc_kernel_space() and gfxp_load_kernel_space(), dealing with the final topics in "Solaris Internals" (not covered or even mentioned a single time in "Solaris Systems Programming", tealing with the kmem infrastructure,  the slab allocator, magazines, I ended up in calling vmem_alloc directly after having read BONWICK https://www.usenix.org/legacy/event/usenix01/full_papers/bonwick/bonwick_html/index.html

However, although I backported it to live on older Solaris releases (and ensured that they are not used on my 11.3, 11.2 and 11.1 test installations) it does work without  them as expected, but as not expected only on 11.1 releases which don't benefit of my backport of the port because they have the interfcaces natively and don't need any hacks.

For a long time I had wished that somebody at Sun/Oracle might give as a view at their modern gfxp implementation, which has proven to be a highly moving target (unfortunately only since after the closing of OS/Net).

Because I would really be interested in their omplementation of (preferred) the gfxp mempool or at least gfxp_alloc_kernel_space() and gfxp_load_kernel_space. The bm functions are not important, I simulated those that are really needed.

nm, dis and objdump combined with modern 11.1++ headers were a small help.

As said: My backport which I must now clean a bit and upload to github and this list does meanwhile work and brings up X11 and compiz, but for some reason does so only there where it is not needed anyway: On 11.1, 11.2 and 11.3.

On 11.0 and Illumos it instantly segfaults early during ddi_dma_mem_alloc() due to a page fault related to dereferencing a NULL pointer.
The DEADBEEF in crash dump isn't very helpful this time, it happens during gtt initialization.

It makes me MAD this problem and I would gently like to ask Sun for some hints regarding the mempool usage, because after all this I would like to rather switch forth to using drm_gem_object_alloc_internal_mempool() rather than the old style drm_gem_object_alloc_internal_normal() .

Any help would be highly anticipated/appreciated.

That's the short FYI which is only a one-liner compared to what I need to write into a real README then.
Was only meant to inform you that I am still working on it.

TNX for the 3 new donations as now also in http://svr4.opensxce.org/RELEASE_NOTES__OpenSXCE2014.05_x86_x64_INTEL32-64_AMD32-64____sun4u_sun4v_SPARC.txt

20151127    John Groenveld           25 EUR
20151120   W David Pooser            50 EUR
20151120   David CARLIER             50 EUR

BIG TNX  :):):)

As you see, your donations were well invested and I keppt and continue to keep my word.
My old 2013 port didn't have to deal with anything of this, consider it obsolete.
Now that we do have Sun/Oracle's new port, what we want is the new port.
Ahh, before you test anything: To get at least started you also need to heavily update agpgart and all associated sub-modules.
To do so it is for now enough to use OpenSXCE2014.05's packages.  But that only as a preliminary side note (yes, I thought of all this and rebooted my bare metal machine about 250 times (if that's enough).
I also placed Sun?Oracle's newer agpgart drivers into my odlder installations and vide versa and all such stuff, to find out more about the behavior. But it didn't affect the kernel panics nor could the use of older agpgart aor xsvc reproduce the same panics on newer 11.1 releases. I tried aperture anstead of xsvc, no difference  :(

Willl now release the src diffs although they are not yet working on earler than 11.1 gfxp.
Maybe somebody with access to Sol11.x src can help  then.

This for now, the mentioned src's after some cleaning on about Sunday.

rgds. from East-Berlin, 
%martin

-- 
Мартин Бохниг