Hi

Am 18.01.22 um 20:06 schrieb Lyude Paul:
> We should probably  Cc: stable@vger.kernel.org this as well, see:
> 
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for
> more info. As well, some useful tools for adding the appropriate Fixes: tags:
> 
> https://drm.pages.freedesktop.org/maintainer-tools/dim.html
> 
> At least on my end this is:
> 
> Acked-by: Lyude Paul <lyude@redhat.com>
> 
> I'd very much like Thomas Zimmerman to verify that this patch is OK though
> with an R-b before we push anything upstream.

Yep, I'll give it a try on my test system. I'll also add a TODO comment 
that summarizes the situation.

A real fix would detect that the kdump kernel is running and not use the 
display then.

Best regards
Thomas

> 
> On Fri, 2022-01-14 at 10:47 +0100, Jocelyn Falempe wrote:
>> On some server with MGA G200e (rev 42), booting with Legacy BIOS,
>> The hardware hangs when using kdump and kexec into the kdump kernel.
>> This happens when the uncompress code tries to write "Decompressing Linux"
>> to the VGA Console.
>>
>> It can be reproduced by writing to the VGA console (0xB8000) after
>> booting to graphic mode, it generates the following error:
>>
>> kernel:NMI: PCI system error (SERR) for reason a0 on CPU 0.
>> kernel:Dazed and confused, but trying to continue
>>
>> The root cause is a bad configuration of the MGA GCTL6 register
>>
>> According to the GCTL6 register documentation:
>>
>> bit 0 is gcgrmode:
>>      0: Enables alpha mode, and the character generator addressing system is
>> activated.
>>      1: Enables graphics mode, and the character addressing system is not
>> used.
>>
>> bit 1 is chainodd even:
>>      0: The A0 signal of the memory address bus is used during system memory
>>      addressing.
>>      1: Allows A0 to be replaced by either the A16 signal of the system
>> address (if
>>      memmapsl is ‘00’), or by the hpgoddev (MISC<5>, odd/even page select)
>> field,
>>      described on page 3-294).
>>
>> bit 3-2 are memmapsl:
>>      Memory map select bits 1 and 0. VGA.
>>      These bits select where the video memory is mapped, as shown below:
>>          00 => A0000h - BFFFFh
>>          01 => A0000h - AFFFFh
>>          10 => B0000h - B7FFFh
>>          11 => B8000h - BFFFFh
>>
>> bit 7-4 are reserved.
>>
>> Current driver code set it to 0x05 => memmapsl to b01 => 0xA0000
>> but on x86, the VGA console is at 0xB8000
>> arch/x86/boot/compressed/misc.c define vidmem to 0xb8000 in extract_kernel()
>> so it's better to configure it to b11
>> Thus changing the value 0x05 to 0x0d
>>
>> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
>> ---
>>   drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
>> b/drivers/gpu/drm/mgag200/mgag200_mode.c
>> index b983541a4c53..c7f63610b278 100644
>> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
>> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
>> @@ -529,7 +529,7 @@ static void mgag200_set_format_regs(struct mga_device
>> *mdev,
>>          WREG_GFX(3, 0x00);
>>          WREG_GFX(4, 0x00);
>>          WREG_GFX(5, 0x40);
>> -       WREG_GFX(6, 0x05);
>> +       WREG_GFX(6, 0x0d);
>>          WREG_GFX(7, 0x0f);
>>          WREG_GFX(8, 0x0f);
>>   
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev