<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt'>
<p>I worked on troubleshooting this, but didn't get very far.<br /> <br /> 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?</p>
<p>The warning messages are about the framebuffer (or lack of it). These two are of interest:<br />WARNING !set->fb failed at /usr/src/sys/dev/drm/drm/../drm_atomic_helper.c:2750</p>
<p>and a bit later:</p>
<p>WARNING state->crtc && !state->fb failed at /usr/src/sys/dev/drm/drm/../drm_atomic.c:862</p>
<p>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.</p>
<div> </div>
<p>Chuck</p>
<p>On 2021-05-24 00:34, karu.pruun wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Yes you can try all the gop modes and see if any of them work fine.<br /> Choosing a different mode means allocating a different framebuffer,<br /> with a different size, at boot.<br /><br /> So the main idea how this works is as follows. The syscons driver that<br /> you see working when in console is based on two other drivers, a<br /> keyboard and a video driver. The video driver is either vga or a drm<br /> driver, i915 or radeon. When the machine boots, syscons first uses the<br /> vga driver. The latter also takes the framebuffer (fb) that UEFI has<br /> set up while booting.<br /><br /> Enter drm/i915. At loading i915, the i915 sets up a new fb and<br /> registers it with the syscons. But something apparently goes wrong<br /> with this; and as your test showed, it did work in dragonfly 5.8.<br /><br /> There are two routines that carry out the bulk of the work in setting up the fb:<br /><br /> (1) drm_fb_helper.c: drm_fb_helper_single_fb_probe()<br /> (2) intel_fbdev.c: intelfb_create()<br /><br /> Actually, (1) calls (2). At the end of (1), register_framebuffer() is<br /> called, this tells syscons to use the newly allocated fb.<br /><br /> Both (1) and (2) have changed from 5.8 to 6.0. We just need to figure<br /> out what fails in those two functions.<br /><br /> Later in the week, I can try pulling out an older intel machine and<br /> see if I can replicate the problem. If yes, then we can hopefully<br /> figure out a patch. If not, then I can send you a couple of patches to<br /> test what fails.<br /><br /> Alternatively, if you feel like you can try chase down the problem in<br /> the two routines, and possibly in others called by them. It would be<br /> easiest if you could compare the output of debugging of 5.8 and 6.0<br /> --- then you could see where the calculations deviate. If you see<br /> garbage output on the screen, then it might mean that the address of<br /> fb is at least partially right, but possibly other parameters (e.g.<br /> pitch, ie the number of bytes that are in each row on screen) are<br /> wrong.<br /><br /> Peeter<br /><br /> --<br /><br /> On Sun, May 23, 2021 at 7:58 PM Chuck Musser <<a href="mailto:cmusser@sonic.net">cmusser@sonic.net</a>> wrote:
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><br /> I couldn't complete all the tests you mention, but here's what I found:<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">(1) whether 5.8 with UEFI still works fine. You can boot the 5.8 img<br /> in the UEFI mode and load i915 manually.</blockquote>
<br /> Using USB sticks with 5.8 and 6.0 images, I booted the system via UEFI,<br /> logged in as root, and then attempted to 'kldload i915'. 5.8<br /> successfully<br /> switched into a framebuffer console (is that the term people use?). 6.0<br /> garbled the top half of the screen, as described earlier.<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><br /> (2) Also, can you try if 6.0 boots in the legacy BIOS mode, and then<br /> load i915 manually.</blockquote>
<br /> I couldn't get it to boot. What I did was put the system back into<br /> "legacy" (BIOS) boot mode and tried booting from the stick. I ran<br /> into "couldn't mount rootvp". There was some discussion about this<br /> at some point, having do do with disabling the ehci driver. I did<br /> try that, but no luck.<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><br /> The fact that console output stops at that point seems to indicate<br /> that i915 has not succeeded in correctly setting up the framebuffer<br /> for the console driver (syscons).</blockquote>
<br /> Out of curiosity, how does the "gop set" command issued in the loader<br /> affect this? Maybe I did not try enough of the valid values to hit<br /> one that would make it work.
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><br /> Just an idle thought: did you update the DragonFly UEFI loader image<br /> when you upgraded to 6.0? It should not matter, but better be safe.<br /> You can do this by mounting the EFI partition and copying over the<br /> /boot/boot1.efi to the correct location.</blockquote>
<br /> Yes I did do that after I did the upgrade because I figured that this<br /> was something that the upgrade might not be able to touch.</blockquote>
</div>
</blockquote>
</body></html>