From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Trippelsdorf Subject: Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues Date: Tue, 30 Jul 2013 13:27:20 +0200 Message-ID: <20130730112720.GA8608@x4> References: <20130729075132.GA354@x4> <20130729140957.GA355@x4> <73ccbe50-7ff5-4b04-80b0-55fa89cce19e@email.android.com> <87k3k9z17s.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail.ud10.udmedia.de (ud10.udmedia.de [194.117.254.50]) by gabe.freedesktop.org (Postfix) with ESMTP id A3477E6E89 for ; Tue, 30 Jul 2013 04:27:22 -0700 (PDT) Content-Disposition: inline In-Reply-To: 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 , "Eric W. Biederman" , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 2013.07.29 at 15:53 -0400, Alex Deucher wrote: > On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman > wrote: > > 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. > > It doesn't look like the drm infrastructure has a shutdown callback. > The drm drivers register a drm_driver callback struct that includes an > unload callback which takes care of all the device teardown (if you > unload the module for example). I don't know that it actually gets > called at kexec time however. I don't know enough about how kexec > works. BTW there is r100_restore_sanity() in drm/radeon/r100.c that explicitly handles the kexec case during init. So maybe an r600_restore_sanity() function is needed? (One of the advantages of using kexec (besides the much quicker boot time) is that the monitor is not switched off and then on during boot. I guess that advantage would be lost if the unload callback would be called.) -- Markus