I worked on troubleshooting this, but didn't get very far. For both 5.8 and 6.0, I set drm.debug to 0x777, booted the system, and then kldloaded i915. I captured dmesg to a file in both cases for later perusal. They are somewhat different: 6.0 does print more stuff and it has couple warning messages that 5.8 doesn't show. Not sure what's the best way to transmit those. Should I just attach files to the mail I send to the list?
The warning messages are about the framebuffer (or lack of it). These two are of interest: WARNING !set->fb failed at /usr/src/sys/dev/drm/drm/../drm_atomic_helper.c:2750 and a bit later: WARNING state->crtc && !state->fb failed at /usr/src/sys/dev/drm/drm/../drm_atomic.c:862 I tried to understand the control flow a bit better by putting some additional trace messages in the drm modules and rebuilding with 'make quickkernel' and 'make installkernel'. My traces did not appear in dmesg after a reboot which is either because the traces are in the wrong place or I am not actually running the kernel I expect. The 'uname' command and the messages at the start of dmesg contain a date is in the past, but I expected that date to be the date I built the kernel, i.e. right now. Chuck On 2021-05-24 00:34, karu.pruun wrote: > Yes you can try all the gop modes and see if any of them work fine. > Choosing a different mode means allocating a different framebuffer, > with a different size, at boot. > > So the main idea how this works is as follows. The syscons driver that > you see working when in console is based on two other drivers, a > keyboard and a video driver. The video driver is either vga or a drm > driver, i915 or radeon. When the machine boots, syscons first uses the > vga driver. The latter also takes the framebuffer (fb) that UEFI has > set up while booting. > > Enter drm/i915. At loading i915, the i915 sets up a new fb and > registers it with the syscons. But something apparently goes wrong > with this; and as your test showed, it did work in dragonfly 5.8. > > There are two routines that carry out the bulk of the work in setting up the > fb: > > (1) drm_fb_helper.c: drm_fb_helper_single_fb_probe() > (2) intel_fbdev.c: intelfb_create() > > Actually, (1) calls (2). At the end of (1), register_framebuffer() is > called, this tells syscons to use the newly allocated fb. > > Both (1) and (2) have changed from 5.8 to 6.0. We just need to figure > out what fails in those two functions. > > Later in the week, I can try pulling out an older intel machine and > see if I can replicate the problem. If yes, then we can hopefully > figure out a patch. If not, then I can send you a couple of patches to > test what fails. > > Alternatively, if you feel like you can try chase down the problem in > the two routines, and possibly in others called by them. It would be > easiest if you could compare the output of debugging of 5.8 and 6.0 > --- then you could see where the calculations deviate. If you see > garbage output on the screen, then it might mean that the address of > fb is at least partially right, but possibly other parameters (e.g. > pitch, ie the number of bytes that are in each row on screen) are > wrong. > > Peeter > > -- > > On Sun, May 23, 2021 at 7:58 PM Chuck Musser <[email protected]> wrote: > I couldn't complete all the tests you mention, but here's what I found: > > (1) whether 5.8 with UEFI still works fine. You can boot the 5.8 img > in the UEFI mode and load i915 manually. > Using USB sticks with 5.8 and 6.0 images, I booted the system via UEFI, > logged in as root, and then attempted to 'kldload i915'. 5.8 > successfully > switched into a framebuffer console (is that the term people use?). 6.0 > garbled the top half of the screen, as described earlier. > > (2) Also, can you try if 6.0 boots in the legacy BIOS mode, and then > load i915 manually. > I couldn't get it to boot. What I did was put the system back into > "legacy" (BIOS) boot mode and tried booting from the stick. I ran > into "couldn't mount rootvp". There was some discussion about this > at some point, having do do with disabling the ehci driver. I did > try that, but no luck. > > The fact that console output stops at that point seems to indicate > that i915 has not succeeded in correctly setting up the framebuffer > for the console driver (syscons). > Out of curiosity, how does the "gop set" command issued in the loader > affect this? Maybe I did not try enough of the valid values to hit > one that would make it work. > Just an idle thought: did you update the DragonFly UEFI loader image > when you upgraded to 6.0? It should not matter, but better be safe. > You can do this by mounting the EFI partition and copying over the > /boot/boot1.efi to the correct location. > Yes I did do that after I did the upgrade because I figured that this > was something that the upgrade might not be able to touch.
