# [SOLVED] No video on new kernel...

## The_Great_Sephiroth

I just did a fresh install on a system we have had for a while. The thing is, the Intel video on-board won't give me any video after post, so I must have missed something with the new kernel.

```

g9nj1r1 ~ # lspci -knn

00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM Controller [8086:2e10] (rev 03)

        Subsystem: Dell 4 Series Chipset DRAM Controller [1028:0420]

00:01.0 PCI bridge [0604]: Intel Corporation 4 Series Chipset PCI Express Root Port [8086:2e11] (rev 03)

        Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e12] (rev 03)

        Subsystem: Dell 4 Series Chipset Integrated Graphics Controller [1028:0420]

        Kernel driver in use: i915

00:02.1 Display controller [0380]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e13] (rev 03)

        Subsystem: Dell 4 Series Chipset Integrated Graphics Controller [1028:0420]

00:03.0 Communication controller [0780]: Intel Corporation 4 Series Chipset HECI Controller [8086:2e14] (rev 03)

        Subsystem: Dell 4 Series Chipset HECI Controller [1028:0420]

        Kernel driver in use: mei_me

00:03.2 IDE interface [0101]: Intel Corporation 4 Series Chipset PT IDER Controller [8086:2e16] (rev 03)

        Subsystem: Dell 4 Series Chipset PT IDER Controller [1028:0420]

        Kernel driver in use: ata_generic

        Kernel modules: pata_acpi, ata_generic

00:03.3 Serial controller [0700]: Intel Corporation 4 Series Chipset Serial KT Controller [8086:2e17] (rev 03)

        Subsystem: Dell 4 Series Chipset Serial KT Controller [1028:0420]

        Kernel driver in use: serial

00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM-3 Gigabit Network Connection [8086:10de] (rev 02)

        Subsystem: Dell 82567LM-3 Gigabit Network Connection [1028:0276]

        Kernel driver in use: e1000e

00:1a.0 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #4 [8086:3a67] (rev 02)

        Subsystem: Dell 82801JD/DO (ICH10 Family) USB UHCI Controller [1028:0420]

        Kernel driver in use: uhci_hcd

00:1a.1 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #5 [8086:3a68] (rev 02)

        Subsystem: Dell 82801JD/DO (ICH10 Family) USB UHCI Controller [1028:0420]

        Kernel driver in use: uhci_hcd

00:1a.2 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #6 [8086:3a69] (rev 02)

        Subsystem: Dell 82801JD/DO (ICH10 Family) USB UHCI Controller [1028:0420]

        Kernel driver in use: uhci_hcd

00:1a.7 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 Family) USB2 EHCI Controller #2 [8086:3a6c] (rev 02)

        Subsystem: Dell 82801JD/DO (ICH10 Family) USB2 EHCI Controller [1028:0420]

        Kernel driver in use: ehci-pci

00:1b.0 Audio device [0403]: Intel Corporation 82801JD/DO (ICH10 Family) HD Audio Controller [8086:3a6e] (rev 02)

        Subsystem: Dell 82801JD/DO (ICH10 Family) HD Audio Controller [1028:0420]

        Kernel driver in use: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation 82801JD/DO (ICH10 Family) PCI Express Port 1 [8086:3a70] (rev 02)

        Kernel driver in use: pcieport

00:1c.1 PCI bridge [0604]: Intel Corporation 82801JD/DO (ICH10 Family) PCI Express Port 2 [8086:3a72] (rev 02)

        Kernel driver in use: pcieport

00:1d.0 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #1 [8086:3a64] (rev 02)

        Subsystem: Dell 82801JD/DO (ICH10 Family) USB UHCI Controller [1028:0420]

        Kernel driver in use: uhci_hcd

00:1d.1 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #2 [8086:3a65] (rev 02)

        Subsystem: Dell 82801JD/DO (ICH10 Family) USB UHCI Controller [1028:0420]

        Kernel driver in use: uhci_hcd

00:1d.2 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #3 [8086:3a66] (rev 02)

        Subsystem: Dell 82801JD/DO (ICH10 Family) USB UHCI Controller [1028:0420]

        Kernel driver in use: uhci_hcd

00:1d.7 USB controller [0c03]: Intel Corporation 82801JD/DO (ICH10 Family) USB2 EHCI Controller #1 [8086:3a6a] (rev 02)

        Subsystem: Dell 82801JD/DO (ICH10 Family) USB2 EHCI Controller [1028:0420]

        Kernel driver in use: ehci-pci

00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev a2)

00:1f.0 ISA bridge [0601]: Intel Corporation 82801JDO (ICH10DO) LPC Interface Controller [8086:3a14] (rev 02)

        Subsystem: Dell 82801JDO (ICH10DO) LPC Interface Controller [1028:0420]

        Kernel driver in use: lpc_ich

00:1f.2 SATA controller [0106]: Intel Corporation 82801JD/DO (ICH10 Family) SATA AHCI Controller [8086:3a02] (rev 02)

        Subsystem: Dell 82801JD/DO (ICH10 Family) SATA AHCI Controller [1028:0420]

        Kernel driver in use: ahci

00:1f.3 SMBus [0c05]: Intel Corporation 82801JD/DO (ICH10 Family) SMBus Controller [8086:3a60] (rev 02)

        Subsystem: Dell 82801JD/DO (ICH10 Family) SMBus Controller [1028:0420]

        Kernel driver in use: i801_smbus

```

My kernel configuration can be viewed here.

*UPDATE*

The solution can be found here.

----------

## The_Great_Sephiroth

I just realized I had forgotten to set two EDID options. I have set them and am building a clean kernel using a chroot from System Rescue CD. This is likely my problem. I will report the results.

----------

## Tony0945

Why did you re-install rather than just update?

----------

## Hu

I don't think he reinstalled all of Gentoo.  Rather, he had no viable installed kernels, so he had to use the rescue media to bring the system to a point that he could make his intended kernel changes.

----------

## The_Great_Sephiroth

It was a reinstall. It had Debian 7 on it. No direct path to Gentoo except for a clean install. Either way I have no video in the shell but the X server does show up. The issue with this is that I cannot create user accounts due to no shell.

----------

## steveL

 *The_Great_Sephiroth wrote:*   

> It was a reinstall. It had Debian 7 on it. No direct path to Gentoo except for a clean install. Either way I have no video in the shell but the X server does show up. The issue with this is that I cannot create user accounts due to no shell.

  Is it EFI? You should be able to get a console using the EFI bios (there's a kernel module for that.) In my case, it starts up with that, and then switches to radeon (which required linux-firmware.)

You should be able to get a shell in X via an xterm, and su - to get root access. (for future ref, if you've reinstalled.)

Also, I noticed you have a subsidiary pci device 00:02.1 on your graphics controller, listed as Intel, then Dell.

There's no module listed for that, not sure if it matters.

----------

## The_Great_Sephiroth

Without a user account I cannot login to X to open a console. I do get X to come up, but no shell prior to that. Also, this system does not support EFI/UEFI. It is BIOS only.

----------

## steveL

OK, but it's sorted now, as you did a reinstall?

----------

## The_Great_Sephiroth

No. I had Debian. I zeroed the disk. I installed Gentoo. No video until X comes up. No account so no login to X. If I press CTRL+ALT+F1 to switch to VT1 the mouse cursor disappears and I get a still image of the login screen. Pressing ALT+F7 takes me back to the actual login screen. I still have no shell video. I do not have EFI/UEFI.

----------

## Tyrus

This is what I would try:

Use a minimal gentoo image. Boot it, mount the new gentoo and chroot into it.

Then I would take out the autostart for the x-server.

I don't know if you use openrc or systemd, but you need to take out the service temporarily.

Assuming you use xdm as service and openrc 

```

rc-config delete xdm default

```

You can also add users now or just reboot and do it then.

Start the xserver with startx until your problems are resolved.

----------

## steveL

Nice post, Tyrus. Succinct, helpful and useful.

----------

## The_Great_Sephiroth

If I do that I am dumped to a black screen after GRUB and then have to hold the power button to kill it. The issue does not concern X, I need video in the shell. Disabling xdm will simply prevent me from getting anything at all because when X starts I then get SDDM for login. Disabling it leaves the screen black. Already tried that to see if I could get a login. For whatever reason, the shell is setting an unsupported resolution. The monitors says something along the lines of "Input not supported".

----------

## steveL

 *The_Great_Sephiroth wrote:*   

> If I do that I am dumped to a black screen after GRUB and then have to hold the power button to kill it. The issue does not concern X, I need video in the shell. Disabling xdm will simply prevent me from getting anything at all because when X starts I then get SDDM for login. Disabling it leaves the screen black. Already tried that to see if I could get a login. For whatever reason, the shell is setting an unsupported resolution. The monitors says something along the lines of "Input not supported".

  OK, so we will stop being puzzled as to why a "fresh reinstall" has no user accounts. ;-)

Do you get the same result when you boot from sysresccd?

----------

## P.Kosunen

 *The_Great_Sephiroth wrote:*   

> No. I had Debian. I zeroed the disk. I installed Gentoo. No video until X comes up. No account so no login to X. If I press CTRL+ALT+F1 to switch to VT1 the mouse cursor disappears and I get a still image of the login screen. Pressing ALT+F7 takes me back to the actual login screen. I still have no shell video. I do not have EFI/UEFI.

 

You might be missing some framebuffer driver from kernel.

----------

## The_Great_Sephiroth

Kosunen, that is what I thought, but I posted my configuration and I have the simple framebuffer and the VESA framebuffer selected. There are no user accounts because I build the system before adding accounts since the groups I need are not available until then. User accounts are not the issue though. The blank screen between GRUB and X is the issue.

----------

## P.Kosunen

```
supermicro ~ # lspci -knn | grep VGA

00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller [8086:0be2] (rev 0b)

supermicro ~ # grep FB /usr/src/linux/.config | grep -v '#'

CONFIG_FB=y

CONFIG_FB_CMDLINE=y

CONFIG_FB_NOTIFY=y

CONFIG_FB_CFB_FILLRECT=y

CONFIG_FB_CFB_COPYAREA=y

CONFIG_FB_CFB_IMAGEBLIT=y

CONFIG_FB_MODE_HELPERS=y

CONFIG_FB_TILEBLITTING=y

CONFIG_FB_EFI=y
```

```
nuc ~ # lspci -knn | grep VGA

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09)

nuc ~ # grep FB /usr/src/linux/.config | grep -v '#'

CONFIG_DRM_KMS_FB_HELPER=y

CONFIG_DRM_FBDEV_EMULATION=y

CONFIG_DRM_FBDEV_OVERALLOC=100

CONFIG_FB=y

CONFIG_FB_CMDLINE=y

CONFIG_FB_NOTIFY=y

CONFIG_FB_BOOT_VESA_SUPPORT=y

CONFIG_FB_CFB_FILLRECT=y

CONFIG_FB_CFB_COPYAREA=y

CONFIG_FB_CFB_IMAGEBLIT=y

CONFIG_FB_SYS_FILLRECT=y

CONFIG_FB_SYS_COPYAREA=y

CONFIG_FB_SYS_IMAGEBLIT=y

CONFIG_FB_SYS_FOPS=y

CONFIG_FB_DEFERRED_IO=y

CONFIG_FB_MODE_HELPERS=y

CONFIG_FB_VESA=y

CONFIG_FB_EFI=y
```

```
beebox ~ # lspci -knn | grep VGA

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 620 [8086:5916] (rev 02)

beebox ~ # grep FB /usr/src/linux/.config | grep -v '#'

CONFIG_X86_SYSFB=y

CONFIG_DRM_KMS_FB_HELPER=y

CONFIG_DRM_FBDEV_EMULATION=y

CONFIG_DRM_FBDEV_OVERALLOC=100

CONFIG_FB=y

CONFIG_FB_CMDLINE=y

CONFIG_FB_NOTIFY=y

CONFIG_FB_CFB_FILLRECT=y

CONFIG_FB_CFB_COPYAREA=y

CONFIG_FB_CFB_IMAGEBLIT=y

CONFIG_FB_SYS_FILLRECT=y

CONFIG_FB_SYS_COPYAREA=y

CONFIG_FB_SYS_IMAGEBLIT=y

CONFIG_FB_SYS_FOPS=y

CONFIG_FB_DEFERRED_IO=y

CONFIG_FB_MODE_HELPERS=y

CONFIG_FB_TILEBLITTING=y

CONFIG_FB_EFI=y
```

I have these framebuffer drivers enabled in Intel machines, check if some of those help. Might not need all of them. IIRC i too lost boot output when upgrading kernel some time ago, had to enable more of them. Haswell NUC boot background is currently green.

----------

## steveL

 *The_Great_Sephiroth wrote:*   

> There are no user accounts because I build the system before adding accounts since the groups I need are not available until then. User accounts are not the issue though. The blank screen between GRUB and X is the issue.

  I do not understand why you don't have root access to a fresh install, since part of the install process is setting the password, and indeed adding a user account.

You must have a medium you can boot from, that gives you a display. Follow the handbook and you will have root and at least one user account too.

Do your install without any X at all, then add X to USE, and so on, after you have a working install that you can use at terminal.

That is a "fresh install".

----------

## The_Great_Sephiroth

User and root are two different things. I have a root account. I allowed SSH login and can SH into the system, but the monitor attached shows no video. Do not worry about accounts. The issue is video. I have no video. I can SSH in all day long, the issue is that when sitting at the PC, I have no video unless X starts. If I need to do anything in the shell, outside of X, I have to setup another system and SSH into this one.

----------

## The_Great_Sephiroth

OK, this may be a broken Intel driver in 4.9.95. I just updated my laptop to the new kernel and now have the same problem, no video in the shell. I am typing this from said laptop, because again, when X starts, I get video. Kernel 4.9.76 works fine, as does 4.9.72, but this one seems to be busted. I checked dmesg and saw a few errors I'll post here. This is after a clean boot into 4.9.95.

```

[    0.007262] Spectre V2 : Spectre mitigation: kernel not compiled with retpoline; no mitigation available!

[    9.406055] cgroup: cgroup2: unknown option "nsdelegate"

[   12.438524] udevd[640]: Error calling EVIOCSKEYCODE on device node '/dev/input/event5' (scan code 0x100150, key code 190): Invalid argument

[  138.338295] [drm:0xffffffff813d3c9b] *ERROR* CPU pipe A FIFO underrun

```

No other errors. The entire log can be found here. Help?

----------

## steveL

 *The_Great_Sephiroth wrote:*   

> User and root are two different things. I have a root account. I allowed SSH login and can SH into the system, but the monitor attached shows no video. Do not worry about accounts. The issue is video. I have no video. I can SSH in all day long, the issue is that when sitting at the PC, I have no video unless X starts. If I need to do anything in the shell, outside of X, I have to setup another system and SSH into this one.

  OK, I understand you have an install with working X and no working video outside X.

What I do not understand is how you got to that as a "fresh install" without a console display. Doing a fresh install usually means doing the base console setup first, and only tackling X once that base reboots cleanly, and is usable as a console machine.

Nor do I understand why you cannot add at least one admin-level user account, given that you can ssh in.

I'll stop commenting now, as it clearly isn't adding anything; nonetheless that would remain my advice, and I believe that was effectively what Tyrus advised too.

I don't see the point in worrying about X graphics, when you have no console display; it's putting the cart before the horse (and means you haven't yet completed the "fresh install".)

Good luck, anyhow.

----------

## The_Great_Sephiroth

OK, third system updated to 4.9.95 and third system with no shell video. It does not matter if I do "make oldconfig" or start with an "allnoconfig" and build it manually, 4.9.95 appears to break all Intel video. No clue what's going on. I do keep getting messages like the following, but not sure if it is related.

```

[  358.167348] [drm:0xffffffff813d484b] *ERROR* CPU pipe A FIFO underrun

```

*EDIT*

Steve, you posted while I was posting. This isn't a hard thing to understand.

Boot System Rescue CD

Partition, format, mount, unzip tarball, build kernel, build GRUB, build sysklogd, cronie, etc

Edit sshd config to allow root login as a backup method

Boot into system which has no video output due to only being shell

Figure out IP address, SSH into box

Build X, Plasma, etc

Add local accounts

Reboot, SDDM shows up, can login and use X

The issue is not user accounts. It seems you're hung up on user accounts and X being usable. My issue is that the second the kernel does its modesetting crap I lose all shell video. I do work in the real shell on and off. For example, if I do a major upgrade from a terminal I have had the screen locker break and prevent me from unlocking the desktop to use the system. All X and Plasma upgrades I do in the real shell. With no video, I cannot use the real shell.

Does that clear things up?

----------

## Hu

Since you found working and non-working versions, you could bisect the patches in the stable series to find where this broke, then report it and request a revert.

----------

## steveL

 *The_Great_Sephiroth wrote:*   

> Does that clear things up?

  Heh, I'm afraid not. You boot sysresccd, which clearly is able to drive the display in console mode since it doesn't boot to X by default.

I would simply leave out X, along with all the ssh stuff, and sort out the console display first, following lspci -k in sysresccd.

ie: Don't do all that other stuff, until you have a working console login, booting solely from the machine; where you have "Boot into system which has no video output due to only being shell." That isn't actually you doing anything: it's more a description of a state of affairs that you need to correct before you do anything else.

Or you aren't following the handbook, that I recall. In any event, it's the wrong way round, IME.

As for being "hung up on user accounts", that is because you mentioned it as "the issue" in one of your earlier posts.

Since it isn't, forget about it.

Obviously, you are where you are, and you'll do what you want with your machine (which could never affect me or mine.)

Good luck with it, however you get there.

I just find it much easier to do an install bottom-up, adding bits as you go to a working base at every point (once you've got it booting into a console, which is the base kernel install, IME: hard-disk controller, rootfs, network and VGA or EFI console.)

If the bit you're adding breaks the boot, then it's easy to go back a step. And from there on in, you can usually always drop back to the console, with a live-disk on hand (or on-disk) for the occasional snafu.

Mind: everything (especially after base console install) becomes much more complex when using systemdbust, from what others have posted.

----------

## The_Great_Sephiroth

OK, I see how what I said could be confusing, so let me start over. I installed Gentoo on a freshly zeroed disk per the install guide. I reboot into my new system and have no shell video. At this point there is no X server or anything so I am stuck. My solution was to find the system IP address using nmap on a second, working system, and then SSH into the box. Before I boot into my new install I always allow root access through SSH and add sshd to the default runlevel. I could then continue installing the system since I could access the box. In fact I did install the entire system including Plasma, LibreOffice, the whole nine yards! I then added accounts and while the desktop now works as it should, I still have no shell video, which is a major issue for me.

In other words, so long as I never need the real shell and X/Plasma never update, I am golden. Unfortunately, we both know that isn't the case.

Now, System Rescue CD is on a much older kernel then 4.9.95 and, as I have previously said, all kernels up to and including 4.9.76 work fine. It is only 4.9.95 which kills Intel video on every system I own. To get the kernel configuration for 4.9.95 I did my usual thing of copying the old kernel in, then doing "make oldconfig" and verified that it did work via the menu. I also started with an "allnoconfig" and manually configured the entire kernel. No dice either way. These systems are BIOS systems, not EFI. I am going to rebuild my laptop kernel with EFI support and see if it helps despite not having an EFI system. I seem to recall that helping on a server.

So the system is complete, but I cannot get shell video, which cripples me for certain tasks.

*EDIT*

FYI: I despise systemd and do not use it. In fact the simple thing which drove me to Gentoo years ago was Debian not allowing me to choose not to use it.

----------

## Hu

There are 1951 commits present in v4.9.95 and not present in v4.9.76.  Assuming a clean bisect, that means log2(1951) = ~11 steps to find the bad patch.  If you start by testing specific stable releases (v4.9.94, v4.9.93, etc.), you can shrink the search space before beginning.  That may or may not be worth the overhead.  If you want to gamble that the bad change is in drivers/video, then there are only 15 commits to test.

As above, I suggest that you find which commit (not just which stable release) breaks display support for you, then report it upstream.  If you do not, you are dependent on someone else discovering the problem and doing these steps, or on someone accidentally fixing it later.

----------

## steveL

OK, got it, though at the point where you could not log in and get a console, I would always sort that out first, which you can still do now.

Start by using an older kernel, where you know you can get video, so you at least have a properly functional machine.

Then I'd follow Hu's advice, if you can git; if not, #git are lovely souls, very helpful and informative.

Chances are at least 2 or 3 people in there will walk you through the bisect.

----------

## The_Great_Sephiroth

I've never done any of that. My issue right now is time. I am swamped at work, now doing 10+ hour days, so time to sit down, learn bisect, test different kernels, and what-not is very slim. I believe the best thing to do for now is roll back to 4.9.76 and worry about this when I am back to normal operating hours. Spring is usually one of our busy seasons. I will look into what bisect is, but again, limited time. Thanks to both of you for the help.

----------

## Hu

I found https://wiki.gentoo.org/wiki/Kernel_git-bisect via Google search for git bisect kernel and read through it.  It looks like a decent guide.  I disagree with its implicit recommendation to use the root account to build the kernel, but that is irrelevant to your current problem.  Your experiment may go faster if you have one machine building kernels and a separate machine to try them, so that you can start building a new kernel immediately upon identifying whether the latest result is good or bad.  If you did it all on one machine, you would need to get back to a working build environment after each reboot.  According to my earlier post, you'll need about 11 build/install/test cycles to find the bad patch.  The time required for that will vary quite a bit depending on how long it takes you to build one kernel (which depends on how many features are enabled) and to some extent on how many of those patches change headers.  If a header is changed, all the files that use it rebuild, which in the worst case means rebuilding everything.  If only a source file changes, the rebuild only recompiles that file and relinks the kernel.  git diff --stat v4.9.76 v4.9.95 -- '*.h' says 232 header files changed in that window.  Some of them are irrelevant to you (other architectures, tools rather than kernel, etc.), but that's still a lot.  Conservatively, figure at least the first half of the bisection run will be mostly full recompiles.

If you have a trusted rookie and a sacrificial machine, this task can be delegated to that person.  There is little creativity in the process, and almost no use for expertise.  It only involves a human element at all because we don't have a good automated recognizer for determining that the resulting kernel is "bad," since we don't know yet why the screen comes up blank on bad kernels and it is not worth writing a tool to use a webcam to watch the screen and diagnose automatically from the image.  :Smile: 

----------

## steveL

 *Hu wrote:*   

> There is little creativity in the process, and almost no use for expertise.  It only involves a human element at all because we don't have a good automated recognizer for determining that the resulting kernel is "bad," since we don't know yet why the screen comes up blank on bad kernels and it is not worth writing a tool to use a webcam to watch the screen and diagnose automatically from the image. :)

 Hmm wrt that use-case, on kernels, it seems to me one could easily automate it, given a two-machine setup; you just set up the one booting the test kernel to send out a known packet, which it might do for net startup anyway (so you could likely just use existing tools to verify. netcat comes to mind, but i'd ask #bash first.)

Obviously you'd need a bit of hw connect, for power/reset, but not much.

----------

## Hu

It might be subject to automation in some cases, but in this case, it is not.  The "bad" kernels boot and run fine.  They does not panic, nor fail any particular system call, nor omit any particular device.  The only problem with them is that they do not drive the text console over his monitor, and he objects to doing everything blind.  So far, no one in the thread has identified a way to programmatically detect that the monitor is not producing useful output.  If we had that, then yes, the bisection could be easily automated.

----------

## The_Great_Sephiroth

OK, so I did one last thing this evening. I opened two konsole sessions in Plasma and went through every single item in the menu config, one at a time. On the old kernels an option to support framebuffer consoles was built-in, but on the new one it was a module. I am betting this was the issue. The kernel wouldn't load it. So I am now recompiling with this option built-in. Cross your fingers for me, would you? I'll report back in a bit!

----------

## The_Great_Sephiroth

OK, that was it. I had to build the option "Framebuffer console support" into the kernel. Using it as a module prevents framebuffers from working. No idea why it was a module in this kernel version, but that fixed everything. It was on my end, not the kernel. I just wish there was an easier way to compare kernel configurations. Still, I am golden now!

----------

## steveL

 *Hu wrote:*   

> It might be subject to automation in some cases, but in this case, it is not. .. So far, no one in the thread has identified a way to programmatically detect that the monitor is not producing useful output.  If we had that, then yes, the bisection could be easily automated.

  Lul, fair enough (though ofc it is feasible.)

Glad it got sorted out, GS.

----------

## Tony0945

 *Hu wrote:*   

>  then there are only 15 commits to test. 

 Actually no more than 5 steps using binary search. Start with 4.9.96

Don't worry about which commit did it until you know at which kernel it failed.

----------

## Hu

 *The_Great_Sephiroth wrote:*   

> I just wish there was an easier way to compare kernel configurations.

 diff -u? *steveL wrote:*   

> (though ofc it is feasible.)

 I would consider it theoretically possible, but not feasible unless there were a nearly turn-key environment to combine running the kernel and detecting via optical input (i.e. webcam) whether the kernel was producing acceptable video output.  Trusted rookies are great for this, but The_Great_Sephiroth seems not to have any on hand.  Is there some automation framework that would have been readily appropriate here? *Tony0945 wrote:*   

>  *Hu wrote:*    then there are only 15 commits to test.  Actually no more than 5 steps using binary search. Start with 4.9.96
> 
> Don't worry about which commit did it until you know at which kernel it failed.

 The rest of this post was written before I noticed the oddity of "15 commits" and reread the thread history to realize you were reacting to my (not quoted) qualifier about drivers/video.  Since it shows some general analysis, I decided to post it anyway.  It assumes no such gamble is made, and that the tester must consider every commit as potentially suspect.

---

Five steps to identify the stable kernel release in which it failed, but then you still need to know which commit is at fault, which means more tests within the identified kernel.  If testing within that kernel requires more than 6 steps, you come out worse than doing a raw release-unaware bisection.  Some kernels can easily cause that:

```
$ seq 76 94 | while read a; do b=$a; (( ++ b)); echo -n "v4.9.$a..v4.9.$b: "; git log --oneline "v4.9.$a..v4.9.$b" | wc; done

v4.9.76..v4.9.77:      99     803    6586

v4.9.77..v4.9.78:      49     399    3203

v4.9.78..v4.9.79:      68     593    4527

v4.9.79..v4.9.80:      87     781    5871

v4.9.80..v4.9.81:      92     697    6054

v4.9.81..v4.9.82:      88     736    6083

v4.9.82..v4.9.83:      76     630    5090

v4.9.83..v4.9.84:     146    1199    9841

v4.9.84..v4.9.85:      40     351    2801

v4.9.85..v4.9.86:      57     493    3757

v4.9.86..v4.9.87:      66     574    4327

v4.9.87..v4.9.88:      87     719    5706

v4.9.88..v4.9.89:     238    2162   16391

v4.9.89..v4.9.90:     177    1567   12077

v4.9.90..v4.9.91:      68     606    4616

v4.9.91..v4.9.92:      29     251    1920

v4.9.92..v4.9.93:     103     936    7342

v4.9.93..v4.9.94:     312    2717   21233

v4.9.94..v4.9.95:      69     585    4734
```

Any line that has more than 2**6 -> 64 commits is a line where you need more than 6 steps within the kernel revision.  Filtering for kernels with at least 64 commits gives:

```
$ seq 76 94 | while read a; do b=$a; (( ++ b)); c=$(git log --oneline "v4.9.$a..v4.9.$b" | wc -l); [[ "$c" -gt 64 ]] && echo "v4.9.$a..v4.9.$b: $c"; done                                                        

v4.9.76..v4.9.77: 99

v4.9.78..v4.9.79: 68

v4.9.79..v4.9.80: 87

v4.9.80..v4.9.81: 92

v4.9.81..v4.9.82: 88

v4.9.82..v4.9.83: 76

v4.9.83..v4.9.84: 146

v4.9.86..v4.9.87: 66

v4.9.87..v4.9.88: 87

v4.9.88..v4.9.89: 238

v4.9.89..v4.9.90: 177

v4.9.90..v4.9.91: 68

v4.9.92..v4.9.93: 103

v4.9.93..v4.9.94: 312

v4.9.94..v4.9.95: 69
```

There are 15 such lines.  There are only 19 released stable kernels in the test range.  So he has a 15/19 chance of doing more work with a two step bisection than with a raw release-unaware bisection.

----------

## The_Great_Sephiroth

Thankfully it was an option I overlooked instead of a real issue. I was not looking forward to figuring out a new process and reporting stuff right now. I am studying for my amateur radio license (technician), working 50+hrs a week, raising my daughter, and working on a phantom coolant leak on my BMW. So who wants to come replace my cooling system?  :Very Happy: 

----------

## Tony0945

From a recent NeddySeagoon post: *Quote:*   

> You don't have any console drivers set in your kernel. That's not a problem for booting but your console is limited to black text on a black background. I've done that too. Its rather hard to read. 

 

----------

## steveL

 *Hu wrote:*   

> I would consider it theoretically possible, but not feasible unless there were a nearly turn-key environment to combine running the kernel and detecting via optical input (i.e. webcam) whether the kernel was producing acceptable video output. ...  Is there some automation framework that would have been readily appropriate here?

 My bad, Hu: I was being nerdy, and thinking of the webcam (with a switch.)

No, I don't know of any such.

----------

## Hu

It's OK.  I like technical solutions, but in this case, a trusted rookie (maybe an RCG?) is probably more cost effective.  :Wink: 

----------

