Den 12.03.2019 18.37, skrev Noralf Trønnes:
>
>
> 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,
Now I remember, it is so I can catch the null pointer debugfs test, but
that's not necessary since this is designed for panics, so I should
remove that test.
Noralf.
> 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,
> };
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
