Update 2 the state of drm-next-4.6 and next steps

[Matthew Macy]

> > But DDB via CTRL+ALT+ESC works. The backtrace of the "kldload" process says 
> > something like: 
> > ============================================================================== 
> > sched_switch 
> > [sleep stuff] 
> > vm_wait+0xeb 
> > uma_small_alloc+0x65 
> > intel_detect_pch+0x66 
> > [...] 
> > ============================================================================== 
> > 
> > I'm not that familiar with DDB or remote debugging at all. If you tell me the 
> > needed commands in DDB - especially to write the output to disk somewhere - I 
> > can provide you better informations. 
> > 
> > My current GIT stamp says "1e9ceda(drm-next-4.6)-dirty". "dirty" because I've 
> > removed WITNESS and other debugging stuff apart from KDB/DDB out off my kernel 
> > config... 
>
>Removing DEBUG functionality when you're testing new unproven code is not a good idea. INVARIANTS and WITNESS are there for your benefit. Nonetheless, you've identified where the memory leak is happening:
>
>in i915_drv.c :470 the loop run for ever. I need to fix the code to take the pch that's passed back and re-use that on subsequent calls rather allocating a second time. That just begs the question as to what I need to be iterating over. Nonetheless, if I haven't fixed it by the next update I'll at least have made pch detection failure less disastrous.
>
>
>     * In some virtualized environments (e.g. XEN), there is irrelevant
>     * ISA bridge in the system. To work reliably, we should scan trhough
>     * all the ISA bridge devices and check for the first match, instead
>     * of only checking the first one.
>     */
>    while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>        if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>            unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>            dev_priv->pch_id = id;
>
>Please file an issue against our repo on github so that I have this in my queue later this week when I have time to work on it.
>
>-M


This change should fix the memory leak you're seeing:
https://github.com/freebsd/freebsd-base-graphics/commit/308354eb2196b0adcbd24f4f7ba6a8da14e0d98e

Note that the remote has changed:

https://github.com/FreeBSDDesktop/freebsd-base-graphics.git

I doubt this will magically make Atom support work. But it will allow us to make it to the next problem.

-M