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
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
