[PATCH] mgag200 fix memmapsl configuration in GCTL6 register
Thomas Zimmermann
tzimmermann at suse.de
Wed Jan 19 08:16:51 UTC 2022
Hi
Am 18.01.22 um 20:06 schrieb Lyude Paul:
> We should probably Cc: stable at 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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220119/6cfa8319/attachment.sig>
More information about the dri-devel
mailing list