From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues Date: Mon, 29 Jul 2013 11:10:31 -0700 Message-ID: <87k3k9z17s.fsf@xmission.com> References: <20130729075132.GA354@x4> <20130729140957.GA355@x4> <73ccbe50-7ff5-4b04-80b0-55fa89cce19e@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by gabe.freedesktop.org (Postfix) with ESMTP id CCCD5E66BE for ; Mon, 29 Jul 2013 11:10:44 -0700 (PDT) In-Reply-To: (Alex Deucher's message of "Mon, 29 Jul 2013 14:02:26 -0400") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Alex Deucher Cc: Alex Deucher , dri-devel@lists.freedesktop.org, Markus Trippelsdorf List-Id: dri-devel@lists.freedesktop.org Alex Deucher writes: > On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman > wrote: >> >> >> Alex Deucher wrote: >>>On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf >>> wrote: >>>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote: >>>>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf >>>>> wrote: >>>>> > On my test machine Xorg doesn't start anymore when I kexec into a >>>>> > 3.11.0-rc3 kernel. >>>>> >>>>> With kexec, dpm doesn't get torn down properly which can result in a >>>>> bad hardware state when the driver loads again. Does the attached >>>>> patch help? It attempts to disable dpm at startup in case it wasn't >>>>> torn down properly previously. >>>> >>>> dpm initialization now works, but unfortunately GPU acceleration >>>still gets >>>> disabled: >>> >>>Stupid kexec complicates things. We need to make sure dpm is torn >>>down before we init the rest of the GPU, but dpm needs get initialized >>>later in the init process since it depends on certain other state from >>>the driver. I need to think about this for a bit. I'm not sure of a >>>good way to handle this. >> >> You might just want to implement a shutdown method that cleans things up properly. At least as a first pass until you worry about things like kexec on panic. >> >> Or can you not shutdown the graphics stack on reboot because of the need to display the kernels shutdown progress? > > Does kexec actually call this shutdown method? The driver implements > appropriate clean-up measures if it's shutdown properly. Absoltuely. All parts of the reboot path call ->shutdown. Including kexec. You don't get a device remove/hotunplug but unless this is a kexec on panic ->shutdown is most definitely called. Now I am talking about the device layer/pci layer shutdown method I don't know how gpu drivers are wired up. GPU land was a little strange last I looked. Hopefully it isn't so strange that there is a method named shutdown that is not wired up. Eric