Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754697AbYKJXfx (ORCPT ); Mon, 10 Nov 2008 18:35:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752692AbYKJXfn (ORCPT ); Mon, 10 Nov 2008 18:35:43 -0500 Received: from gate.crashing.org ([63.228.1.57]:47198 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751922AbYKJXfm (ORCPT ); Mon, 10 Nov 2008 18:35:42 -0500 Subject: Re: [Bug #11875] radeonfb lockup in .28-rc (bisected) From: Benjamin Herrenschmidt To: Andreas Schwab Cc: "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Andrew Morton , "David S. Miller" , James Cloos , Paul Collins , Linus Torvalds In-Reply-To: References: <1226295985.7731.7.camel@pasglop> <1226353979.7530.8.camel@pasglop> Content-Type: text/plain Date: Tue, 11 Nov 2008 10:34:54 +1100 Message-Id: <1226360094.7530.18.camel@pasglop> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1454 Lines: 36 > There seems to be some race involved here. I cannot reproduce the > problem ATM. I wonder if it's related to the new acceleration at all then. I've tried various suspend/resume cycles in straight console mode using directly snooze -f (kernel ioctl) and from X using ubuntu intrepid and gnome power manager and it worked fine on a 5,6 which should be fairly similar to your 6,7 I think. It's possible that there's yet another X related race though. I've seen cases of X whacking the chip -after- it has religuished the console back to the kernel (back to KD_TEXT) in the past which is very wrong, though I didn't spot that during my testing, there could be some race lurking there. Can you describe your problem more precisely ? I didn't see (or forgot) your initial report. Did it crash on suspend or wakeup ? what symptoms ? Note also that on PowerBooks, there's a platform hook that allows radeonfb to wake up the video chip _very_ early, thus allowing easier debugging of the boot process, so even races like that on wakeup would surprise me since we do wakup up the chip before we even get a chance to schedule userspace again (in fact before we even bring back the L2 cache !) Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/