Den 12.03.2019 18.25, skrev Ville Syrjälä:
> On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 12.03.2019 17.17, skrev Ville Syrjälä:
>>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
>>>> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
>>>>> This adds support for outputting kernel messages on panic().
>>>>> A kernel message dumper is used to dump the log. The dumper iterates
>>>>> over each DRM device and it's crtc's to find suitable framebuffers.
>>>>>
>>>>> All the other dumpers are run before this one except mtdoops.
>>>>> Only atomic drivers are supported.
>>>>>
>>>>> Signed-off-by: Noralf Trønnes <noralf@xxxxxxxxxxx>
>>>>> ---
>>>>> [...]
>>>>>
>>>>> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
>>>>> index f0b34c977ec5..f3274798ecfe 100644
>>>>> --- a/include/drm/drm_framebuffer.h
>>>>> +++ b/include/drm/drm_framebuffer.h
>>>>> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
>>>>> struct drm_file *file_priv, unsigned flags,
>>>>> unsigned color, struct drm_clip_rect *clips,
>>>>> unsigned num_clips);
>>>>> +
>>>>> + /**
>>>>> + * @panic_vmap:
>>>>> + *
>>>>> + * Optional callback for panic handling.
>>>>> + *
>>>>> + * For vmapping the selected framebuffer in a panic context. Must
>>>>> + * be super careful about locking (only trylocking allowed).
>>>>> + *
>>>>> + * RETURNS:
>>>>> + *
>>>>> + * NULL if it didn't work out, otherwise an opaque cookie which is
>>>>> + * passed to @panic_draw_xy. It can be anything: vmap area, structure
>>>>> + * with more details, just a few flags, ...
>>>>> + */
>>>>> + void *(*panic_vmap)(struct drm_framebuffer *fb);
>>>>
>>>> FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
>>>> drivers:
>>>>
>>>> Framebuffers are normally tiled, writing to them with the CPU results in
>>>> garbled output.
>>>>
>>
>> In which case the driver needs to support the ->panic_draw_xy callback,
>> or maybe it's possible to make a generic helper for tiled buffers.
>>
>>>> With a discrete GPU having a large amount of VRAM, the framebuffer may
>>>> not be directly CPU accessible at all.
>>>>
>>
>> I would have been nice to know how Windows works around this.
>>
>>>>
>>>> There would need to be a mechanism for switching scanout to a linear,
>>>> CPU accessible framebuffer.
>>>
>>> I suppose panic_vmap() could just provide a linear temp buffer
>>> to the panic handler, and panic_unmap() could copy the contents
>>> over to the real fb.
>>>
>>> That said, this approach of scribbling over the primary plane's
>>> framebuffer has some clear limitations:
>>> * something may overwrite the oops message before the user
>>> can even read it
>>
>> When the dumper drm_panic_kmsg_dump() runs, the other CPU's should have
>> been stopped. See panic().
>
> GPUs etc. may still be executing away.
>
Would it be safe to stop it in a panic situation? It would ofc be bad to
crash the box even harder.
>>
>>> * there may be other planes obscuring part or all of the
>>> primary plane
>>>
>>
>> Yeah, this is a problem, again I wonder how Windows deals with this.
>
> Probably just disables all other planes. Not that it uses planes
> all that heavily.
>
>>
>>> Also scribbling over the user's framebuffer seems rather rude
>>> to me, so I'm thinking this approach should be limited to kernel
>>> panics only.
>>>
>>
>> Yes this will only happen on kernel panics:
>>
>> panic() -> kmsg_dump() -> drm_panic_kmsg_dump()
>>
>> (Unless invoking through debugfs ofc)
>
> I thought you set the max_level or whatever to OOPS. Doesn't that mean
> it gets involved for non-panics as well?
>
I do that in the debugfs code, but I can't remember why I lower level, I
think can just change the level when invoking the dumper:
drm_panic_file_panic_write(...)
- kmsg_dump(KMSG_DUMP_OOPS);
+ kmsg_dump(KMSG_DUMP_PANIC);
This is the dumper config:
static struct kmsg_dumper drm_panic_kmsg_dumper = {
.dump = drm_panic_kmsg_dump,
.max_reason = KMSG_DUMP_PANIC,
};
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
