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

[Matthew Macy]

 ---- On Tue, 24 May 2016 08:31:09 -0700 Nils Beyer <nbe at renzel.net> wrote ---- 
 > Matthew Macy wrote: 
 > >> "kldload" hangs at the "vmwait" state (checked via CTRL+T). On a second console, 
 > >> I can enter a username; but after entering the username "root" and pressing 
 > >> enter, the login process hangs at the "pfault" state. 
 > >>   
 > >> Hopefully, this information helps you a little bit... 
 > >  
 > > That actually gives me more to go on. Running "procstat -kk <kldload pid>" would help even more. 
 >  
 > well, "procstat" doesn't work because any command like "ps" (to find out the PID of 
 > "kldload") during that hanging "kldload" leads to "pfault" and hangs as well (I've 
 > pre-logged-in to a second console before). 
 >  
 > 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