Re: 2.6.29 git master and PAT problems

["Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>]

On Mon, Mar 30, 2009 at 03:31:09PM -0700, Arkadiusz Miskiewicz wrote:
> On Monday 30 of March 2009, Pallipadi, Venkatesh wrote:
> 
> More info follows. Now I've switched to
> e1c502482853f84606928f5a2f2eb6da1993cda1 which contains latest drm fixes and
> now I get much lower numbers of PAT errors but still.
> 
> > On Mon, 2009-03-30 at 14:31 -0700, Arkadiusz Miskiewicz wrote:
> > > On Monday 30 of March 2009, Pallipadi, Venkatesh wrote:
> > > > Patch here should get rid of these errors.
> > > >
> > > > http://marc.info/?l=linux-kernel&m=123788806506230&w=2
> > > >
> > > > The patch is in tip and on its way to upstream.
> > >
> > > The problem is that kernel I'm running already contains this patch (it's
> > > merged already). Other ideas?
> > >
> > > ratelimiting that error is good IMO anyway.
> >
> > Rate limiting will just work around the problem here. Ideally we should
> > never see these errors. So, it will be better if we can narrow down on
> > the bug resulting in these error messages.
> 
> Of course it's better. I'm saying that when these messages "fire" then it's
> hard to do anything else on the system for a while until these stop.
> 
> > Can you please send me the output of
> > # cat /debug/x86/pat_memtype_list
> > with debugfs mounted.
> > and
> > # cat /proc/mtrr
> 
> Two complets of logs below (second part done after reboot).
> 
> # cat /debug/x86/pat_memtype_list
> PAT memtype list:
> uncached-minus @ 0xbd6d1000-0xbd6d2000
> uncached-minus @ 0xbd6d2000-0xbd6d3000
> uncached-minus @ 0xbd6d3000-0xbd6d4000
> uncached-minus @ 0xbd706000-0xbd707000
> uncached-minus @ 0xbd707000-0xbd708000
> uncached-minus @ 0xbd96a000-0xbd96b000
> uncached-minus @ 0xbd96a000-0xbd96b000
> uncached-minus @ 0xbd96a000-0xbd97a000
> uncached-minus @ 0xbd979000-0xbd97a000
> uncached-minus @ 0xbd979000-0xbd97a000
> uncached-minus @ 0xbd979000-0xbd97a000
> uncached-minus @ 0xbd979000-0xbd97a000
> uncached-minus @ 0xbd979000-0xbd97a000
> uncached-minus @ 0xbd979000-0xbd97a000
> uncached-minus @ 0xbd979000-0xbd97a000
> uncached-minus @ 0xbd97b000-0xbd97c000
> uncached-minus @ 0xbd98b000-0xbd98e000
> uncached-minus @ 0xbd98b000-0xbd98d000
> uncached-minus @ 0xbd98d000-0xbd98e000
> uncached-minus @ 0xbd98e000-0xbd98f000
> uncached-minus @ 0xbd98e000-0xbd98f000
> uncached-minus @ 0xc2000000-0xc2001000
> write-combining @ 0xd0000000-0xe0000000
> write-combining @ 0xd2000000-0xd2020000
> write-combining @ 0xd2020000-0xd2512000
> write-combining @ 0xd2522000-0xd2523000
> write-combining @ 0xd26b7000-0xd26b8000
> write-combining @ 0xd26b8000-0xd26b9000
> write-combining @ 0xd26b9000-0xd26ba000
> write-combining @ 0xd26ba000-0xd26bb000
> write-combining @ 0xd26bb000-0xd26bc000
> write-combining @ 0xd26bc000-0xd26bd000
> write-combining @ 0xd26bd000-0xd26be000
> write-combining @ 0xd26be000-0xd26bf000


There seems to be two different problems here.
- We should not have that many single page ranges reserved. That will cause a
performance problem with drm even without the "freeing invalid type" error.
- "freeing invalid type" error itself. Seems to be caused due to some
unbalanced free along the drm path. We tried to find anything obvious in the
code that may be causing problem here. But, haven't found anything so far.
Will try to reproduce the problem internally and debug it further.

Thanks,
Venki