Hi,
I've tested the patch and I can confirm that it fixed the issue.
Tested on Fedora 36 with kernel 6.0.8.
Thanks,
Matthieu
On Tue, Nov 8 2022 at 04:40:52 PM +0100, Matthieu CHARETTE
wrote:
I didn't test the patch yet. I will do. But even without testing I
can tell you that it will work (It
I didn't test the patch yet. I will do. But even without testing I can
tell you that it will work (It will not crash).
Currently when the crash occurs, all screens remain black after resume.
I'm not able to login with ssh neither. And logs end before the
suspend. So the crash seems to be some ki
On Sun, 06 Nov 2022, Matthieu CHARETTE wrote:
> Hi,
>
> Can you tell me what are we waiting for? Maybe I can help.
Have you tried the patch? Is it an improvement over the status quo?
The "crash" is still ambiguous to me. Do you observe it with the patch?
Do you have logs? Etc.
BR,
Jani.
>
> T
Hi,
Can you tell me what are we waiting for? Maybe I can help.
Thanks.
Matthieu
On Wed, Oct 12 2022 at 07:16:29 PM +0200, Matthieu CHARETTE
wrote:
By crash, I mean that an error is returned here:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git/+/refs/heads/master
By crash, I mean that an error is returned here:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git/+/refs/heads/master/drivers/gpu/drm/drm_edid_load.c#195
I don't really know what happens next, but on my machine the built-in
screen and the external remains dark. Also the
It should fix the issue. Meanwhile, the system will still crash if a
new monitor is plugged while the machine is suspended. We might need to
precache the EDID to prevent that.
Matthieu
On Fri, Oct 7 2022 at 01:21:46 AM +0300, Jani Nikula
wrote:
We've used a temporary platform device for fir
Currently the EDID is requested during the resume. But since it's
requested too early, this means before the filesystem is mounted, the
firmware request fails. This make the DRM driver crash when resuming.
This kind of issue should be prevented by the firmware caching process
which cache every firm
On Tue, 11 Oct 2022, Matthieu CHARETTE wrote:
> Currently the EDID is requested during the resume. But since it's
> requested too early, this means before the filesystem is mounted, the
> firmware request fails. This make the DRM driver crash when resuming.
> This kind of issue should be prevented
On Tue, 11 Oct 2022, Matthieu CHARETTE wrote:
> It should fix the issue. Meanwhile, the system will still crash if a
> new monitor is plugged while the machine is suspended. We might need to
> precache the EDID to prevent that.
Please elaborate.
BR,
Jani.
>
> Matthieu
>
> On Fri, Oct 7 2022
We've used a temporary platform device for firmware EDID loading since
it was introduced in commit da0df92b5731 ("drm: allow loading an EDID as
firmware to override broken monitor"), but there's no explanation why.
Do we need to?
Maybe this fixes the suspend/resume issue?
(Yes, I'll rewrite the
10 matches
Mail list logo
