PQ_LAUNDRY: unexpected behaviour
Pete Wright
pete at nomadlogic.org
Fri Jan 6 17:48:46 UTC 2017
On 1/6/17 9:14 AM, Matthew Macy wrote:
>
> > > Please try the drm-next branch now. Up until very recently, the
> > > shrinkers responsible for culling ttm/gem allocations were never run.
> > > I've now implemented the shrinker, but it's driven from vm_lowmem, so
> > > you'll probably still see what looks like a leak until you hit low
> > > memory conditions. The shrinker should probably be run from
> > > uma_timeout, but there isn't an eventhandler for that and I haven't
> > > looked any further.
> > >
> > > -M
> >
> > Hi,
> >
> > I am now testing the `drm-next` branch, but I'm finding it crashes much
> > more frequently (a la
> > https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/96) than
> > `drm-next-4.7`. While the 4.7 branch would sometimes only last a few
> > minutes, it would sometimes run for a day or more. On `drm-next`,
> > however, I think I'm yet to have 20 minutes of uptime. So, I haven't run
> > into the memory shrinker yet because I haven't had enough uptime to use
> > lots of memory. :) I will continue testing... any specific things I
> > ought to be doing?
> >
>
>
>
> I just did the merge and it's using a relatively untested new KPI so regressions aren't too surprising I'm afraid. #96 is more or less content free in terms of providing useful information. Getting a core + backtrace would be a lot more helpful. See the repo's wiki for details on improving your odds of getting a core.
>
I have found the following has enabled me to catch kernel panic's pretty
reliably on the drm-next branch when i have the i915kms module loaded:
dev.drm.skip_ddb=1
-pete
--
Pete Wright
pete at nomadlogic.org
nomadlogicLA
More information about the freebsd-current
mailing list