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? > 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) _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
