linux-kernel - Re: [BISECTED] drm: random hang since 620f378 "drm: prune modes when ..."

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <200912082259.48715.arnd@arndb.de>
Date:	Tue, 8 Dec 2009 22:59:48 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Dave Airlie <airlied@...hat.com>
Cc:	Adam Jackson <ajax@...hat.com>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sourceforge.net
Subject: Re: [BISECTED] drm: random hang since 620f378 "drm: prune modes when ..."

On Monday 07 December 2009, Arnd Bergmann wrote:
> After upgrading one of my machines to 2.6.32, I saw hangs after one to thirty minutes after
> booting, with random data written to parts of the frame buffer. I've bisected it down
> to 620f37811d "drm: prune modes when output is disconnected.", which was merged
> in 2.6.32-rc1. Connecting a serial console does not reveal any output at the time of
> the crash.
> 
> The machine uses an Intel G45 chipset with the i915 kernel mode setting enabled.
> 
> I have no clue what that patch does or why reverting it fixes the problem but 2.6.32
> with this revert applied has not shown these hangs yet.
> 
> Signed-off-by: Arnd Bergmann <arnd@...db.de>

Scratch this, the machine crashed again in the same way, but only after
a some hours of uptime (normally it took a few minutes). It still looks like
 this commit makes the bug much more likely, but it could also be
attributed to complete coincedence and bad timing. 2.6.31 certainly never
showed the problem and the bisection clearly pointed in the general direction
of i915.

I hate debugging sporadic hangs...

Sorry for blaming the wrong patch, especially if it already caused a lot 
of work. I'll try blaming ec2a4c3fdc8 "drm/i915: get the bridge device
once" now, that is the next-best candidate that my bisection pointed to,
but I'll do more rigorous testing.

	Arnd
--
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/