public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Luck, Tony" <tony.luck@intel.com>,
	"Wang, Rui Y" <rui.y.wang@intel.com>,
	Dave Airlie <airlied@redhat.com>,
	"Clark, Rob" <robdclark@gmail.com>,
	"Roper, Matthew D" <matthew.d.roper@intel.com>,
	"Chen, Gong" <gong.chen@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: drm/mgag200: doesn't work in panic context
Date: Mon, 29 Jun 2015 10:09:14 +0200	[thread overview]
Message-ID: <20150629080914.GB12383@pd.tnic> (raw)
In-Reply-To: <CAKMK7uF3rvUh9hEr8zC9vV8HL4aHRk-6+Gif7GEW-C5cFWQDuQ@mail.gmail.com>

On Sat, Jun 27, 2015 at 07:56:19PM +0200, Daniel Vetter wrote:

<snip very useful explanation for !GPU people>

> Which could all happen very much after the kernel made it's dying
> sigh. Display hw has long stopped being this simple and display
> drivers also.

Thanks for the explanation. I was fearing that it would go in such
direction though. :\ Oh well.

So there are two observations to be ventured here:

* there's still no robust and simple way to save/show oops messages on
laptops. When a laptop crashes and the user has only this one machine,
catching the oops can be a serious PITA. Laptop most likely doesn't have
serial, modeset is hard to do, as you explained, and saving it into
persistent storage (UEFI) might brick it in some cases or whatever the
firmware will do to it. I guess we can keep wishing here for something
better.

* The server aspect might not really need GPU modesetting IMHO because
realistically, servers have serial so the oops can go out there. Which
begs the other question:

Shouldn't drm_fb_helper_panic() and that path below it simply be
removed?

I mean, if it needs to do all that hw-reconf on the panic path and if
that reconfiguration is not completely reliable, maybe we shouldn't do
it all?

This way, we will basically remain as quiet as possible in order not
to muddle the system unreasonably when we're about to die and the only
thing we want to catch is an oops or maybe kexec the crash kernel...

Oops will go out on serial anyway and server will kexec - GPU/fb stuff
doesn't do anything. Yes, no?

Hmmm.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

  reply	other threads:[~2015-06-29  8:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-26  7:55 drm/mgag200: doesn't work in panic context Rui Wang
2015-06-26  9:27 ` Daniel Vetter
2015-06-26 18:30   ` Luck, Tony
2015-06-27 13:52     ` Daniel Vetter
2015-06-27 14:12       ` Borislav Petkov
2015-06-27 17:56         ` Daniel Vetter
2015-06-29  8:09           ` Borislav Petkov [this message]
2015-06-29  9:25             ` Daniel Vetter
2015-06-29  9:42               ` Borislav Petkov
2015-06-29  9:58                 ` Daniel Vetter
  -- strict thread matches above, loose matches on Subject: below --
2015-06-30  2:53 Rui Wang
2015-06-30  6:36 ` Daniel Vetter
2015-06-30  7:23 Rui Wang
2015-06-30 15:23 ` Daniel Vetter
2015-07-01  7:26 Rui Wang
2015-07-01  9:59 ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150629080914.GB12383@pd.tnic \
    --to=bp@alien8.de \
    --cc=airlied@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=gong.chen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.d.roper@intel.com \
    --cc=robdclark@gmail.com \
    --cc=rui.y.wang@intel.com \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox