On Fri, Dec 10, 2021 at 07:54:34PM -0500, Felix Kuehling wrote:
> Do you actually need to restore the exact boot-up mode? If you have the same
> framebuffer memory layout (width, height, bpp, stride) the precise display
> timing doesn't really matter. So we "just" need to switch to a mode that's
On 2021-12-10 10:13 a.m., Christian König wrote:
Am 10.12.21 um 15:25 schrieb Guilherme G. Piccoli:
On 10/12/2021 11:16, Alex Deucher wrote:> [...]
Why not just reload the driver after kexec?
Alex
Because the original issue is the kdump case, and we want a very very
tiny kernel - also, the
On Fri, Dec 10, 2021 at 10:24 AM Guilherme G. Piccoli
wrote:
>
> On 10/12/2021 12:13, Christian König wrote:
> > [...]
> > How about issuing a PCIe reset and re-initializing the ASIC with just
> > the VBIOS?
> >
> > That should be pretty straightforward I think.
> >
> > Christian.
>
>
> Thanks
On Fri, Dec 10, 2021 at 9:25 AM Guilherme G. Piccoli
wrote:
>
> On 10/12/2021 11:16, Alex Deucher wrote:> [...]
> > Why not just reload the driver after kexec?
> >
> > Alex
>
> Because the original issue is the kdump case, and we want a very very
> tiny kernel - also, the crash originally could
Am 10.12.21 um 16:24 schrieb Guilherme G. Piccoli:
On 10/12/2021 12:13, Christian König wrote:
[...]
How about issuing a PCIe reset and re-initializing the ASIC with just
the VBIOS?
That should be pretty straightforward I think.
Christian.
Thanks Christian, that'd be perfect! Is it
On 10/12/2021 12:13, Christian König wrote:
> [...]
> How about issuing a PCIe reset and re-initializing the ASIC with just
> the VBIOS?
>
> That should be pretty straightforward I think.
>
> Christian.
Thanks Christian, that'd be perfect! Is it feasible? Per Alex comment,
we'd need to run
Am 10.12.21 um 15:25 schrieb Guilherme G. Piccoli:
On 10/12/2021 11:16, Alex Deucher wrote:> [...]
Why not just reload the driver after kexec?
Alex
Because the original issue is the kdump case, and we want a very very
tiny kernel - also, the crash originally could have been caused by
On 10/12/2021 11:16, Alex Deucher wrote:> [...]
> Why not just reload the driver after kexec?
>
> Alex
Because the original issue is the kdump case, and we want a very very
tiny kernel - also, the crash originally could have been caused by
amdgpu itself, so if it's a GPU issue, we don't want to
On Fri, Dec 10, 2021 at 9:09 AM Guilherme G. Piccoli
wrote:
>
> Thanks a lot Alex / Gerd and Thomas, very informative stuff! I'm glad
> there are projects to collect/save the data and reuse after a kdump,
> this is very useful.
>
> I'll continue my study on the atombios thing of AMD and QXL,
Thanks a lot Alex / Gerd and Thomas, very informative stuff! I'm glad
there are projects to collect/save the data and reuse after a kdump,
this is very useful.
I'll continue my study on the atombios thing of AMD and QXL, maybe at
least we can make it work in qemu, that'd be great (like a small
Hi
Am 09.12.21 um 19:17 schrieb Guilherme G. Piccoli:
Thanks again Alex! Some comments inlined below:
On 09/12/2021 15:06, Alex Deucher wrote:
Not really in a generic way. It's asic and platform specific. In
addition most modern displays require link training to bring up the
display, so you
Hi,
> > The drivers are asic and platform specific. E.g., the driver for
> > vangogh is different from renoir is different from skylake, etc. The
> > display programming interfaces are asic specific.
>
> Cool, that makes sense! But if you (or anybody here) know some of these
> GOP drivers,
Hi all, I have a question about the possibility of reusing a framebuffer
after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not
a separate GPU hardware), but I guess the question is kinda generic
hence I've looped most of the lists / people I think does make sense
(apologies for
On 09/12/2021 14:31, Alex Deucher wrote:
> [...]
> Once the driver takes over, none of the pre-driver state is retained.
> You'll need to load the driver in the new kernel to initialize the
> displays. Note the efifb doesn't actually have the ability to program
> any hardware, it just takes over
Thanks again Alex! Some comments inlined below:
On 09/12/2021 15:06, Alex Deucher wrote:
> Not really in a generic way. It's asic and platform specific. In
> addition most modern displays require link training to bring up the
> display, so you can't just save and restore registers.
Oh sure, I
On Thu, Dec 9, 2021 at 1:18 PM Guilherme G. Piccoli wrote:
>
> Thanks again Alex! Some comments inlined below:
>
> On 09/12/2021 15:06, Alex Deucher wrote:
> > Not really in a generic way. It's asic and platform specific. In
> > addition most modern displays require link training to bring up
On Thu, Dec 9, 2021 at 1:00 PM Guilherme G. Piccoli wrote:
>
> On 09/12/2021 14:31, Alex Deucher wrote:
> > [...]
> > Once the driver takes over, none of the pre-driver state is retained.
> > You'll need to load the driver in the new kernel to initialize the
> > displays. Note the efifb doesn't
On Thu, Dec 9, 2021 at 12:04 PM Guilherme G. Piccoli
wrote:
>
> Hi all, I have a question about the possibility of reusing a framebuffer
> after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not
> a separate GPU hardware), but I guess the question is kinda generic
> hence I've
Hi Guilherme,
Am 09.12.21 um 17:00 schrieb Guilherme G. Piccoli:
Hi all, I have a question about the possibility of reusing a framebuffer
after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not
a separate GPU hardware), but I guess the question is kinda generic
hence I've
19 matches
Mail list logo
