On 12.10.2013 14:54, Fengguang Wu wrote:
> On Sat, Oct 12, 2013 at 07:47:05AM +1000, Dave Airlie wrote:
This is my preferred method of fixing it as I don't think the lifetimes
need
to be tied so closely, though this requires review my someone to make sure
my unregistering etc i
> >[ 97.260371] BUG: Bad page map in process killall5 pte:4f426de0
> >pmd:0f4f4067
> >[ 97.261114] addr:3fc0 vm_flags:00100173 anon_vma:4f4066c0 mapping:
> >(null) index:3ffe6
> >[ 97.261912] CPU: 0 PID: 334 Comm: killall5 Not tainted
> >3.12.0-rc3-00156-gdaeb5e3 #1
> >[ 97.262633]
On Sat, Oct 12, 2013 at 07:47:05AM +1000, Dave Airlie wrote:
> >>
> >> This is my preferred method of fixing it as I don't think the lifetimes
> >> need
> >> to be tied so closely, though this requires review my someone to make sure
> >> my unregistering etc is correct and in the right place.
> >
>>
>> This is my preferred method of fixing it as I don't think the lifetimes need
>> to be tied so closely, though this requires review my someone to make sure
>> my unregistering etc is correct and in the right place.
>
> Apparently this fixes the problem for Fengguang, and the code looks
> clean
On Thu, Oct 10, 2013 at 10:05 PM, Dave Airlie wrote:
>
> This is my preferred method of fixing it as I don't think the lifetimes need
> to be tied so closely, though this requires review my someone to make sure
> my unregistering etc is correct and in the right place.
Apparently this fixes the pr
As reported in the thread
[xen] double fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
on Linux kernel the drm has a crappy interaction model with the sysfs objects.
This is my preferred method of fixing it as I don't think the lifetimes need
to be tied so closely, though this requires review my some