Am 11.09.2013 10:53, schrieb Markus Trippelsdorf:
On 2013.09.10 at 16:40 -0400, Alex Deucher wrote:
On Tue, Sep 10, 2013 at 2:27 PM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
Alex Deucher <alexdeucher@xxxxxxxxx> writes:
On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf
<markus@xxxxxxxxxxxxxxx> wrote:
IIRC Alex said the sanity checks are expensive and boot-time could be
improved by dropping them. Maybe he can chime in?
They shouldn't be necessary with a proper shutdown, but in this
particular case, they are not very expensive. What is expensive is
having a separate sanity check functions for all the various hw blocks
to teardown everything on startup prior to starting it up in case
kexec, etc. left the system in a bad state. It ends up amounting to a
full tear down sequence followed by a full start up sequence every
time you load the driver.
I can't really comment on the first patch, but the rest seem fine.
Let me reask the question just a little bit.
Is it the sanity checks that are expensive? Or is it the
reinitialization that is triggered by the sanity checks that is
expensive?
From what Christian said in the other reply it sounds like this is a
game we will never completely win, but it would be nice to have half a
chance in the kexec on panic case to have video. So I am curious to
know if the checks are expensive when we are coming at hardware in a
clean state.
The particular sanity checks from this patch set are not expensive,
but we had previously discussed more extensive sanity checks for other
aspects of the chips in prior conversations. Prior to this patch set,
the hw is not torn down properly (might have been in the middle of DMA
for example) when kexec happens. That's why the sanity checks were
added in the first place. With this patch set, the sanity checks
shouldn't be necessary.
I think you're talking past each other.
What Eric worries about is the »kexec on panic« case, where the shutdown
method *isn't* called. In this case the sanity checks, that are only
superfluous when the hardware was shutdown normally during kexec (the
default case), may actually help. And because the checks aren't
expensive, it wouldn't hurt to just leave them in place.
When we don't know the state the hardware is in it is really hard to get
into a working configuration again, even with the sanity checks in place.
For example you can't just cut power or reset the UVD block without
knowing it's state, cause then you have a good chance that you hit into
the middle of a register or memory access of the VCPU. This usually
results in the next few registers accesses only return either 0x0 or
0xffffffff and after that the system completely locks up.
Isn't it possible to know that we are in a "kexec after panic" case and
only try to initialize the display hardware and not all the other
blocks? That would at least allow us to get an error message of what
happened on the screen and otherwise advise the user to do a clean reset.
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
