linux-kernel - Re: [pci] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_crtc.c:94 drm_warn_on_modeset_not_all

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 24 Mar 2014 10:59:14 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Fengguang Wu <fengguang.wu@...el.com>
Cc:	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Alex Deucher <alexander.deucher@....com>,
	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [pci] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_crtc.c:94 drm_warn_on_modeset_not_all_locked()

On Sun, Mar 23, 2014 at 8:53 AM, Fengguang Wu <fengguang.wu@...el.com> wrote:
> Hi Bjorn,
>
> On Fri, Mar 21, 2014 at 12:42:33PM -0600, Bjorn Helgaas wrote:
>> On Thu, Mar 20, 2014 at 8:09 PM, Fengguang Wu <fengguang.wu@...el.com> wrote:
>> > // CC Stephane for RAPL related bug
>> >
>> > Bjorn, sorry this bug report is mis-titled. The only new bug that show
>> > up in aa11fc58dc is on rapl_pmu_init. And it shows up only 1 time, so
>> > it's hard to reproduce and the bisect is likely not accurate.  I'll
>> > retry the bisect with more repeat count. Sorry for the disturbing!
>>
>> This testing is potentially very useful, but only if we don't have
>> many false positives.  I spent a lot of time trying to figure this
>> out, and it turned out not to be a problem at all.
>
> I'm sorry for the false report! I'll be careful and improve the
> process. Currently there are many false positives in our internal
> boot error bisects. And we rely on human reviews to select good
> bisects out of the noises. In this case both the script and me made
> mistakes, which lead to the wrong report.
>
>> As a procedural question, can you help me figure out how to handle a
>> report like this?  What I *hoped* for would be:
>>
>>   - the config you used
>
> Yes.
>
>>   - the dmesg log from the newest good commit
>
> I'll attach it if the first bad commit's parent commit(s) has some
> noise errors. In this case it may help decide whether the bisect is
> wrong: in some cases one bug will hide another one; or the bug message
> may change from one to the other.
>
>>   - the dmesg log from the oldest bad commit (the one you bisected to)
>
> OK, I've fixed the script to attach it (rather than attaching the
> branch HEAD's dmesg).
>
>>   - maybe a hint about how I can reproduce the problem, e.g., the qemu
>> config I need
>
> OK, fixed the reporting script to include the QEMU commands for
> reproducing the problem.
>
>> You did supply the config, which is good.  But you only supplied one
>> dmesg log, and it doesn't seem to be from the oldest bad commit.  In
>> fact, it seems to be from some commit that isn't actually in either
>> Linus' tree or in linux-next.  So I don't know what the connection is
>> with the bad commit.
>
> Sorry the dmesg file is from the internal merge-and-testing branch's
> HEAD -- where the bisect starts.  I'll attach the first bad commit's
> dmesg instead.
>
>> What should I do to try to debug a report like this?  Where should I start?
>
> Thank you very much for the suggestions!

Excellent, thanks!  I think these will make it much easier to figure
out where to start.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/