From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jani Nikula Subject: Re: DRM-based Oops viewer Date: Mon, 11 Mar 2019 11:04:19 +0200 Message-ID: <87mum1lr3g.fsf@intel.com> References: <20190310013142.GA3376@darwi-home-pc> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id B17D089A1F for ; Mon, 11 Mar 2019 09:02:31 +0000 (UTC) In-Reply-To: <20190310013142.GA3376@darwi-home-pc> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: "Ahmed S. Darwish" , David Airlie , Daniel Vetter , Joonas Lahtinen , Rodrigo Vivi , Alex Deucher , Christian =?utf-8?Q?K=C3=B6nig?= , David Zhou , Ard Biesheuvel , Matt Fleming Cc: Greg Kroah-Hartman , Linus Torvalds , dri-devel@lists.freedesktop.org, John Ogness , linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gU3VuLCAxMCBNYXIgMjAxOSwgIkFobWVkIFMuIERhcndpc2giIDxkYXJ3aXNoLjA3QGdtYWls LmNvbT4gd3JvdGU6Cj4gSGVsbG8gRFJNL1VFRkkgbWFpbnRhaW5lcnMsCj4KPiBTZXZlcmFsIHll YXJzIGFnbywgSSB3cm90ZSBhIHNldCBvZiBwYXRjaGVzIHRvIGR1bXAgdGhlIGtlcm5lbAo+IGxv ZyB0byBkaXNrIHVwb24gcGFuaWMgLS0gdGhyb3VnaCBCSU9TIElOVCAweDEzIHNlcnZpY2VzLiBb MV0KPgo+IFRoZSBvdmVyd2hlbG1pbmcgcmVzcG9uc2Ugd2FzIHRoYXQgaXQncyB1bnNhZmUgdG8g ZG8gdGhpcyBpbiBhCj4gZ2VuZXJpYyBtYW5uZXIuIExpbnVzIHByb3Bvc2VkIGEgdmlkZW8tYmFz ZWQgdmlld2VyIGluc3RlYWQ6IFsyXQo+Cj4gICAgIElmIHlvdSB3YW50IHRvIGRvIHRoZSBCSU9T IHNlcnZpY2VzIHRoaW5nLCBkbyBpdCBmb3IgdmlkZW86IGNvcHkgdGhlCj4gICAgIG9vcHMgdG8g bG93IFJBTSwgcmV0dXJuIHRvIHJlYWwgbW9kZSwgcmUtcnVuIHRoZSBncmFwaGljcyBjYXJkIFBP U1QKPiAgICAgcm91dGluZXMgdG8gaW5pdGlhbGl6ZSB0ZXh0LW1vZGUsIGFuZCB1c2UgdGhlIEJJ T1MgdG8gcHJpbnQgb3V0IHRoZQo+ICAgICBvb3BzLiAgVGhhdCBpcyBXQVkgbGVzcyBzY2FyeSB0 aGFuIHdyaXRpbmcgdG8gZGlzay4KPgo+IE9mIGNvdXJzZSBpdCdzIDIwMTkgbm93IHRob3VnaCwg YW5kIGl0J3MgcXVpdGUga25vd24gdGhhdAo+IEludGVsIGlzIG9mZmljaWFsbHkgb2Jzb2xldGlu ZyB0aGUgUEMvQVQgQklPUyBieSAyMDIwLi4gWzNdCj4KPiBSZXNlYXJjaGluZyB3aGV0aGVyIHRo aXMgY2FuIGJlIGRvbmUgZnJvbSBVRUZJLCBpdCB3YXMgYWxzbyBjbGVhcgo+IHRoYXQgVUVGSSAi UnVudGltZSBTZXJ2aWNlcyIgZG8gbm90IHByb3ZpZGUgYW55IHJlLWluaXRpYWxpemF0aW9uCj4g cm91dGluZXMuIFs0XQo+Cj4gVGhlIG1heGltdW0gcG9zc2libGUgdGhhdCBVRUZJIGNhbiBwcm92 aWRlIGlzIGEgR09QLXByb3ZpZGVkCj4gZnJhbWVidWZmZXIgdGhhdCdzIHJlYWR5IHRvIHVzZSBi eSB0aGUgT1MgLS0gZXZlbiBhZnRlciB0aGUgVUVGSQo+IGJvb3QgcGhhc2UgaXMgbWFya2VkIGFz IGRvbmUgdGhyb3VnaCBFeGl0Qm9vdFNlcnZpY2VzKCkuIFs1XQo+Cj4gT2YgY291cnNlLCBvbmNl IG5hdGl2ZSBkcml2ZXJzIGxpa2UgaTkxNSBvciByYWRlb24gdGFrZSBvdmVyLAo+IHN1Y2ggYSBm cmFtZWJ1ZmZlciBpcyB0b2FzdC4uLiBbNl0KPgo+IFRodXMgYSBwb3NzaWJsZSByZW1haW5pbmcg b3B0aW9uLCBpcyB0byBkaXNwbGF5IHRoZSBvb3BzIHRocm91Z2gKPiAibWluaW1hbCIgRFJNIGRy aXZlcnMgcHJvdmlkZWQgZm9yIGVhY2ggSFcgdmFyaWFudC4uLiBTaW5jZQo+IHRoZXNlIHNwZWNp YWwgZHJpdmVycyB3aWxsIHJ1biBvbmx5IGFuZCBmdWxseSB1bmRlciBhIHBhbmljKCkKPiBjb250 ZXh0IHRob3VnaCwgc2V2ZXJhbCBjb25zdHJhaW50cyBleGlzdDoKPgo+ICAgLSBUaGUgY29kZSBz aG91bGQgYmUgZnVsbHkgc3luY2hyb25vdXMgKGlycXMgYXJlIGRpc2FibGVkKQo+ICAgLSBJdCBz aG91bGQgbm90IGFsbG9jYXRlIGFueSBkeW5hbWljIG1lbW9yeQo+ICAgLSBJdCBzaG91bGQgbWFr ZSBtaW5pbWFsIGFzc3VtcHRpb25zIGFib3V0IEhXIHN0YXRlCj4gICAtIEl0IHNob3VsZCBub3Qg Y2hhaW4gaW50byBhbnkgb3RoZXIga2VybmVsIHN1YnN5c3RlbQo+ICAgLSBJdCBoYXMgYW1wbGUg ZnJlZWRvbSB0byB1c2UgZGVsYXktYmFzZWQgbG9vcHMgYW5kIHRoZQo+ICAgICBsaWtlLCB0aGUg a2VybmVsIGlzIGFscmVhZHkgZGVhZC4KPgo+IEhvdyBmZWFzaWJsZSBpcyBpdCB0byBoYXZlIHN1 Y2ggYSBzcGVjaWFsICJEUk0gdmlld29vcHMiCj4gZnJhbWV3b3JrICsgaXRzIG1pbmltYWwgZHJp dmVycyBpbiB0aGUga2VybmVsPwoKUGxlYXNlIGZpcnN0IGJldHRlciBkZWZpbmUgd2hhdCB5b3Ug d2FudCB0byBhY2hpZXZlLgoKRG8geW91IHdhbnQgdG8gc3RvcmUgdGhlIGRtZXNnIG9yIG9vcHMg KGxpa2UgeW91ciBvcmlnaW5hbCBzZXJpZXMKc3VnZ2VzdHMpIG9yIGRvIHlvdSB3YW50IHRvIGRp c3BsYXkgdGhlIG9vcHM/IERvIHlvdSB3YW50IHRoZSBmYWNpbGl0eQp0byBiZSBmdW5jdGlvbmlu ZyBhdCBhbGwgdGltZXMsIG9yIG9ubHkgd2hlbiBzcGVjaWZpY2FsbHkgcmVxdWVzdGVkIGluCmFk dmFuY2UgYnkgdGhlIHVzZXI/IElmIHlvdSB3YW50IHRvIGRpc3BsYXkgdGhlIG9vcHMsIGRvIHlv dSB3YW50IGl0IHRvCmFsc28gd29yayB3aGVuIHRoZSBkaXNwbGF5IGlzIGRpc2FibGVkIGF0IHRo ZSB0aW1lIG9mIHRoZSBvb3BzPyBXaGF0IGlmCnRoZSBkaXNwbGF5IGlzIGF0IGF0dGFjaGVkIHRv IGEgcG9ydCBvbiBhIGRvY2s/CgpUaGVyZSdzIGF0IGxlYXN0IGtkdW1wLCByYW1vb3BzLCBhbmQg bmV0Y29uc29sZSB0aGF0IGNhbiBiZSB1c2VkIHRvCmFjaGlldmUgc29tZSBvZiB3aGF0IHlvdSB3 YW50LiBIb3cgZG8gdGhleSBmYWxsIHNob3J0IGZvciB5b3U/CgpCUiwKSmFuaS4KCgo+Cj4gVGhl IHRhcmdldCBpcyB0byBzdGFydCBmcm9tIGk5MTUsIHNpbmNlIHRoYXQncyB3aGF0IGluIG15Cj4g bGFwdG9wIG5vdywgYW5kIHdvcmsgZnJvbSB0aGVyZS4uCj4KPiBTb21lIGZpbmFsIG5vdGVzOgo+ Cj4gICAtIFRoZSBOVCBrZXJuZWwgaGFzIGEgc2ltaWxhciBjb25jZXB0LCBidXQgZm9yIHN0b3Jh Z2UgaW5zdGVhZC4KPiAgICAgVGhleSdyZSB1c2VkIHRvIGR1bXAgY29yZSB1bmRlciBrZXJuZWwg cGFuaWMoKSBzaXR1YXRpb25zLAo+ICAgICBhbmQgYXJlIGNhbGxlZCAiTWlub3BvcnQgc3RvcmFn ZSBkcml2ZXJzIi4gWzddCj4KPiAgIC0gU2luY2UgV2luZG93cyA3KywgYSB2ZXJ5IGZhbmN5IEJs dWUgU2NyZWVuIG9mIERlYXRoIGlzCj4gICAgIGRpc3BsYXllZCwgd2l0aCBVbmljb2RlIGFuZCB3 aGF0bm90LCBpbXBseWluZyBHUFUgZHJpdmVycwo+ICAgICBpbnZvbHZlbWVudC4gWzhdCj4KPiAg IC0gTWFjIE9TIFggYWxzbyBkb2VzIHNvbWV0aGluZyBzaW1pbGFyIFs5XQo+Cj4gICAtIE9uIExp bnV4IGxhcHRvcHMsIHRoZSBjdXJyZW50IHNpdHVhdGlvbiBpcyBfcmVhbGx5XyBiYWQuCj4KPiAg ICAgSW4gYW55IGdyYXBoaWNhbCBzZXNzaW9uLCB0eXBlICJlY2hvIGMgPiAvcHJvYy9zeXNycS10 cmlnZ2VyIjsKPiAgICAgdGhlIHNjcmVlbiB3aWxsIGp1c3QgY29tcGxldGVseSBmcmVlemUuLi4K Pgo+ICAgICBEZXNpcmVkIGZpcnN0IGdvYWw6IGp1c3QgcHJpbnQgdGhlIHBhbmljKCkgbG9nCj4K PiBUaGFua3MgYSBsb3QsCj4KPiBbMV0gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcvbGttbC8yMDEx MDEyNTEzNDc0OC5HQTEwMDUxQGxhcHRvcAo+IFsyXSBodHRwczovL2xvcmUua2VybmVsLm9yZy9s a21sL0FBTkxrVGluVTBLWWlDZDRwPXorPW9qYmtlRW9UMkcrQ0FZdmRSVTAyS0pFbkBtYWlsLmdt YWlsLmNvbQo+Cj4gWzNdIGh0dHBzOi8vdWVmaS5vcmcvc2l0ZXMvZGVmYXVsdC9maWxlcy9yZXNv dXJjZXMvQnJpYW5fUmljaGFyZHNvbl9JbnRlbF9GaW5hbC5wZGYKPgo+IFs0XSBVRUZJIHYyLjcg c3BlYywgQ2hhcHRlciA4LCAiU2VydmljZXMg4oCUIFJ1bnRpbWUgU2VydmljZXMiCj4gWzVdIFVF RkkgdjIuNyBzcGVjLCBTZWN0aW9uIDEyLjksICJHcmFwaGljcyBPdXRwdXQgUHJvdG9jb2wiCj4g ICAgICJUaGUgR3JhcGhpY3MgT3V0cHV0IFByb3RvY29sIHN1cHBvcnRzIHRoaXMgY2FwYWJpbGl0 eSBieQo+ICAgICAgcHJvdmlkaW5nIHRoZSBFRkkgT1MgbG9hZGVyIGFjY2VzcyB0byBhIGhhcmR3 YXJlIGZyYW1lIGJ1ZmZlcgo+ICAgICAgYW5kIGVub3VnaCBpbmZvcm1hdGlvbiB0byBhbGxvdyB0 aGUgT1MgdG8gZHJhdyBkaXJlY3RseSB0bwo+ICAgICAgdGhlIGdyYXBoaWNzIG91dHB1dCBkZXZp Y2UuIgo+Cj4gWzZdIGxpbnV4L2RyaXZlcnMvZ3B1L2RybS9pOTE1L2k5MTVfZHJ2LmM6Omk5MTVf a2lja19vdXRfZmlybXdhcmVfZmIoKQo+ICAgICBsaW51eC9kcml2ZXJzL2dwdS9kcm0vcmFkZW9u L3JhZGVvbl9kcnYuYzo6cmFkZW9uX3BjaV9wcm9iZSgpCj4KPiBbN10gaHR0cHM6Ly9kb2NzLm1p Y3Jvc29mdC5jb20vZW4tdXMvd2luZG93cy1oYXJkd2FyZS9kcml2ZXJzL3N0b3JhZ2UvcmVzdHJp Y3Rpb25zLW9uLW1pbmlwb3J0LWRyaXZlcnMtdGhhdC1tYW5hZ2UtdGhlLWJvb3QtZHJpdmUKPgo+ IFs4XSBodHRwczovL3VwbG9hZC53aWtpbWVkaWEub3JnL3dpa2lwZWRpYS9jb21tb25zL2FyY2hp dmUvNS81Ni8yMDE4MTAxOTE1MTkzNyUyMUJzb2R3aW5kb3dzMTAucG5nCj4gWzldIGh0dHBzOi8v dXBsb2FkLndpa2ltZWRpYS5vcmcvd2lraXBlZGlhL2NvbW1vbnMvNC80YS9NYWNfT1NfWF8xMC4y X0tlcm5lbF9QYW5pYy5qcGcKPgo+IC0tZGFyd2kKPiBodHRwOi8vZGFyd2lzaC5jaGFzaW5ncG9p bnRlcnMuY29tCgotLSAKSmFuaSBOaWt1bGEsIEludGVsIE9wZW4gU291cmNlIEdyYXBoaWNzIENl bnRlcgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmkt ZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6 Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWw= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1E13C43381 for ; Mon, 11 Mar 2019 09:02:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A6C892075C for ; Mon, 11 Mar 2019 09:02:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727023AbfCKJCc convert rfc822-to-8bit (ORCPT ); Mon, 11 Mar 2019 05:02:32 -0400 Received: from mga09.intel.com ([134.134.136.24]:59742 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725850AbfCKJCc (ORCPT ); Mon, 11 Mar 2019 05:02:32 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2019 02:02:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,467,1544515200"; d="scan'208";a="153885151" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.172]) by fmsmga001.fm.intel.com with ESMTP; 11 Mar 2019 02:02:27 -0700 From: Jani Nikula To: "Ahmed S. Darwish" , David Airlie , Daniel Vetter , Joonas Lahtinen , Rodrigo Vivi , Alex Deucher , Christian =?utf-8?Q?K=C3=B6nig?= , David Zhou , Ard Biesheuvel , Matt Fleming Cc: Linus Torvalds , Greg Kroah-Hartman , John Ogness , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: DRM-based Oops viewer In-Reply-To: <20190310013142.GA3376@darwi-home-pc> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20190310013142.GA3376@darwi-home-pc> Date: Mon, 11 Mar 2019 11:04:19 +0200 Message-ID: <87mum1lr3g.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 10 Mar 2019, "Ahmed S. Darwish" wrote: > Hello DRM/UEFI maintainers, > > Several years ago, I wrote a set of patches to dump the kernel > log to disk upon panic -- through BIOS INT 0x13 services. [1] > > The overwhelming response was that it's unsafe to do this in a > generic manner. Linus proposed a video-based viewer instead: [2] > > If you want to do the BIOS services thing, do it for video: copy the > oops to low RAM, return to real mode, re-run the graphics card POST > routines to initialize text-mode, and use the BIOS to print out the > oops. That is WAY less scary than writing to disk. > > Of course it's 2019 now though, and it's quite known that > Intel is officially obsoleting the PC/AT BIOS by 2020.. [3] > > Researching whether this can be done from UEFI, it was also clear > that UEFI "Runtime Services" do not provide any re-initialization > routines. [4] > > The maximum possible that UEFI can provide is a GOP-provided > framebuffer that's ready to use by the OS -- even after the UEFI > boot phase is marked as done through ExitBootServices(). [5] > > Of course, once native drivers like i915 or radeon take over, > such a framebuffer is toast... [6] > > Thus a possible remaining option, is to display the oops through > "minimal" DRM drivers provided for each HW variant... Since > these special drivers will run only and fully under a panic() > context though, several constraints exist: > > - The code should be fully synchronous (irqs are disabled) > - It should not allocate any dynamic memory > - It should make minimal assumptions about HW state > - It should not chain into any other kernel subsystem > - It has ample freedom to use delay-based loops and the > like, the kernel is already dead. > > How feasible is it to have such a special "DRM viewoops" > framework + its minimal drivers in the kernel? Please first better define what you want to achieve. Do you want to store the dmesg or oops (like your original series suggests) or do you want to display the oops? Do you want the facility to be functioning at all times, or only when specifically requested in advance by the user? If you want to display the oops, do you want it to also work when the display is disabled at the time of the oops? What if the display is at attached to a port on a dock? There's at least kdump, ramoops, and netconsole that can be used to achieve some of what you want. How do they fall short for you? BR, Jani. > > The target is to start from i915, since that's what in my > laptop now, and work from there.. > > Some final notes: > > - The NT kernel has a similar concept, but for storage instead. > They're used to dump core under kernel panic() situations, > and are called "Minoport storage drivers". [7] > > - Since Windows 7+, a very fancy Blue Screen of Death is > displayed, with Unicode and whatnot, implying GPU drivers > involvement. [8] > > - Mac OS X also does something similar [9] > > - On Linux laptops, the current situation is _really_ bad. > > In any graphical session, type "echo c > /proc/sysrq-trigger"; > the screen will just completely freeze... > > Desired first goal: just print the panic() log > > Thanks a lot, > > [1] https://lore.kernel.org/lkml/20110125134748.GA10051@laptop > [2] https://lore.kernel.org/lkml/AANLkTinU0KYiCd4p=z+=ojbkeEoT2G+CAYvdRU02KJEn@mail.gmail.com > > [3] https://uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf > > [4] UEFI v2.7 spec, Chapter 8, "Services — Runtime Services" > [5] UEFI v2.7 spec, Section 12.9, "Graphics Output Protocol" > "The Graphics Output Protocol supports this capability by > providing the EFI OS loader access to a hardware frame buffer > and enough information to allow the OS to draw directly to > the graphics output device." > > [6] linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb() > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe() > > [7] https://docs.microsoft.com/en-us/windows-hardware/drivers/storage/restrictions-on-miniport-drivers-that-manage-the-boot-drive > > [8] https://upload.wikimedia.org/wikipedia/commons/archive/5/56/20181019151937%21Bsodwindows10.png > [9] https://upload.wikimedia.org/wikipedia/commons/4/4a/Mac_OS_X_10.2_Kernel_Panic.jpg > > --darwi > http://darwish.chasingpointers.com -- Jani Nikula, Intel Open Source Graphics Center