Hi
Am 20.11.20 um 11:51 schrieb David Laight:
From: Thomas Zimmermann
Sent: 20 November 2020 10:14
...
Is there any way to bisect through the parts of the drm merge patch into v5.10-rc1 ?
That ought to be quicker (and less error prone) than the bisect builds I was doing.
Note that the stack 'splat' is due to a later change. It is separate from the broken pixel alignment.
I actually saw the vga text go 'funny' while the boot was outputting all the [OK] messages (from systemd?) before the graphic login stole tty1 (bloody stupid to use tty1).
I don't need to use the failing system today, I'll have another go at isolating the failure.
You can use drm-tip for testing, where many of the DRM patches go through.
https://cgit.freedesktop.org/drm/drm-tip/It's fairly up-to-date.
Any idea of tags either side of the 5.10 merge?
The final commit before v5.9 appears to be
Fixes: 33c8256b3bcc ("drm/amd/display: Change ABM config init interface")
I'd try this as a good commit. For the bad commit, just try HEAD.
Best regards Thomas
I have two systems with AST chips and neither shows any of the symptoms you describe; nor do we have such reports about drivers that use a similar stack (hibmc, bochs). Could you provide the output of
dmesg | grep drm[ 2.112303] fb0: switching to astdrmfb from EFI VGA [ 2.120222] ast 0000:02:00.0: [drm] Using P2A bridge for configuration [ 2.120233] ast 0000:02:00.0: [drm] AST 2400 detected [ 2.120247] ast 0000:02:00.0: [drm] Analog VGA only [ 2.120257] ast 0000:02:00.0: [drm] dram MCLK=408 Mhz type=1 bus_width=16 [ 2.121121] [drm] Initialized ast 0.1.0 20120228 for 0000:02:00.0 on minor 0 [ 2.125838] fbcon: astdrmfb (fb0) is primary device [ 2.152179] ast 0000:02:00.0: [drm] fb0: astdrmfb frame buffer device [ 6.061034] systemd[1]: Condition check resulted in Load Kernel Module drm being skipped.
The output is the same for both good and bad kernels.
David
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)