[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170714161027.5htn5jlswvfgphzw@hirez.programming.kicks-ass.net>
Date: Fri, 14 Jul 2017 18:10:27 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Mike Galbraith <efault@....de>
Cc: Ilia Mirkin <imirkin@...m.mit.edu>,
LKML <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>,
David Airlie <airlied@...ux.ie>,
Ben Skeggs <bskeggs@...hat.com>, jeyu@...nel.org
Subject: Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP:
drm_calc_vbltimestamp_from_scanoutpos+335
On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote:
> On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote:
> > Urgh, is for some mysterious reason the __bug_table section of modules
> > ending up in RO memory?
> >
> > I forever get lost in that link magic :/
>
> +1
>
> drm.ko
> 20 __bug_table 00000630 0000000000000000 0000000000000000 0004bff3 2**0
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> vmlinux
> 15 __bug_table 0000ba84 ffffffff81af26c0 0000000001af26c0 00cf26c0 2**0
> CONTENTS, ALLOC, LOAD, READONLY, DATA
>
> Danged if I know... um um RELOC business mucks things up?
Argh, it shouldn't be READONLY for vmlinux either, but apparently that
is working for mysterious reasons.
Some architectures were in fact complaining that I broke that, and hence
patch:
b5effd3815cc ("debug: Fix __bug_table[] in arch linker scripts")
I think we need professional help with this linking stuff, but who to
ask?
Powered by blists - more mailing lists