Date: Tue, 24 May 2016 13:26:29 -0700 From: Matthew Macy <mmacy@nextbsd.org> To: "Nils Beyer" <nbe@renzel.net> Cc: "<freebsd-x11@freebsd.org>" <freebsd-x11@freebsd.org> Subject: Re: Update 2 the state of drm-next-4.6 and next steps Message-ID: <154e4727f68.d96d4366265964.4046041328395915864@nextbsd.org> In-Reply-To: <2036793.4G1HTRBqfD@asbach.renzel.net> References: <1540c0ceea9.126b592b988423.8774357707501817476@nextbsd.org> <15449ec286e.11def424858288.297669375175006270@nextbsd.org> <1549f266cc5.ea588cba219264.3594536435079440635@nextbsd.org> <20160521231734.GM21899@ivaldir.etoilebsd.net> <CAASDrV=h7C8JjqQPcWWE4=Z6=F%2BvG1aU_YqPgLDoTM2-362PVQ@mail.gmail.com> <57436A8E.4020109@gmail.com> <154df5bc8e2.b7d4a800194520.6901257599921444588@nextbsd.org> <5743824C.6050308@gmail.com> <154dfc5f7e9.109281b7a199490.5235064548489806889@nextbsd.org> <1854718.X2I93raCOV@asbach.renzel.net> <154e1d87643.b5b82861225515.4992131373924163574@nextbsd.org> <2036793.4G1HTRBqfD@asbach.renzel.net>
next in thread | previous in thread | raw e-mail | index | archive | help
---- On Tue, 24 May 2016 08:31:09 -0700 Nils Beyer <nbe@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?154e4727f68.d96d4366265964.4046041328395915864>