From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 6 Jan 2013 21:55:11 +0100 From: Daniel Vetter To: Linus Torvalds Cc: Alexey Zaytsev , Chris Wilson , Linux Kernel Mailing List , Daniel Vetter , Jesse Barnes , Rodrigo Vivi , Peter Ujfalusi , stable Subject: Re: Linux 3.8-rc2 Message-ID: <20130106205511.GR5737@phenom.ffwll.local> References: <6c3329$7ukf5e@orsmga002.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: On Thu, Jan 03, 2013 at 03:18:54PM -0800, Linus Torvalds wrote: > On Thu, Jan 3, 2013 at 3:12 PM, Alexey Zaytsev wrote: > > > > Chris: The patch does not seem to have any effect on the problem. > > > > Peter: I've attached the dmesgs, as well as the diff between the > > interesting parts. The patch does not seem to make any difference > > there. > > Alexey, what happens if you just avoid the divide-by-zero? There might > be other complications downstream, but something like the attached > patch should at least avoid doing the "divide-by-clock" when clock is > zero.. Yeah, that looks like the better duct-tape. For context, we're in the middle of the long road to fastboot, i.e. taking over the output setup done by the bios to avoid a costly modeset at boot-up (at least for somewhat sane firmware which doesn't use legacy vga mode any more but the native resolution of the panel). But since we don't yet read out the full hw state some assumptions are now broken in our code, so we need to catch them. Chris has a more complete patch covering all the other generations/code-paths accessing crtc->mode.clock (but lost you from cc). I'll forward his patch asap (still digging through the mail flood from vacation). Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch