[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

[randyf at sibernet.com]

   Sorry, I'm only on oi-dev, so feel free to forward elsewhere.

>
> 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).

   It's not as moving as you might think.  A number of things were added 
late in S11 to support non-intel framebuffers, it just seemed proper to 
have i915 use them where appropriate.  Though not sure yet what might 
venture into the next version.

>
> 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.

   As you have identified, gfxp_alloc_kernel_space() is just a wrapper 
around vmem_alloc() using the heap arena.  Can't speculate on what might 
have changed with the segment driver.

   gfxp_load_kernel_space() is effectively a wrapper to hat_devload() 
allowing for the use of caching or write combining (i.e. if CACHED add 
HAT_STORECACHING_OK to the attr's, and if WRITECOMBINED add HAT_MERGING_OK 
| HAT_PLAT_NOCACHE to the attrs otherwise use HAT_STRICTORDER | 
HAT_PLAT_NOCACHE).

   You probably want to leave out the use of mempools (redefined that 
HAS_MEM_POOL always returns "0"), as this will likely be dropped in the 
next version of the driver (it only accounts for a small performance 
increase, but a fair amount of change in the driver that could otherwise 
be performed by a wrapper for Linux kmem_cache_create()).

>
> 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() .

   Like I said, there is little benefit to the current mempool 
implementation, and will likely be dropped in the next version of the 
driver.  So using normal will be your short-term best answer.

   But the NULL dref is interesting.  Possibly a stack trace might offer 
useful data.

> Now that we do have Sun/Oracle's new port, what we want is the new port.

   You probably really want the next port.  The current port is now two 
years old and has lots of deviations from the community version.  The next 
port should be very close to the Linux drivers.

> 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  :(
>

   There is little use of agp in the current driver, and none in the next 
driver.  So likely a red herring, but possibly not.  But knowing where the 
init is getting it's memory might help (possibly a failure path that 
doesn't occur in the Solaris version).


Cheers!

rf