mgag200 fix memmapsl configuration in GCTL6 register
Jocelyn Falempe
jfalempe at redhat.com
Fri Jan 14 09:47:53 UTC 2022
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
If some other architectures require the VGA memory to be at 0xA0000, I can
write another patch which won't change the memmapsl bits, (so assuming the
BIOS or UEFI already set it to the right value).
Another solution would be to set it to 0x0d only on x86.
Let me know what you think is the best way to fix it.
More information about the dri-devel
mailing list