Date: Tue, 24 May 2016 21:37:56 -0700 From: Matthew Macy <mmacy@nextbsd.org> To: "Nils Beyer" <nbe@renzel.net> Cc: "<freebsd-x11@freebsd.org>" <freebsd-x11@freebsd.org> Subject: Re: Re: Update 2 the state of drm-next-4.6 and next steps Message-ID: <154e6346d2e.10672302e141790.3018205346870992567@nextbsd.org> In-Reply-To: <154e4727f68.d96d4366265964.4046041328395915864@nextbsd.org> 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> <154e4727f68.d96d4366265964.4046041328395915864@nextbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?154e6346d2e.10672302e141790.3018205346870992567>