[SOLVED] No video on new kernel...

steveL · Posted: Sat May 12, 2018 12:28 am Post subject:

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 · Posted: Sun May 13, 2018 3:42 pm Post subject:

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.
_________________
Ever picture systemd as what runs "The Borg"?

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

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.

steveL · Posted: Mon May 14, 2018 2:28 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

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 · Posted: Tue May 15, 2018 3:09 am Post subject:

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!
_________________
Ever picture systemd as what runs "The Borg"?

The_Great_Sephiroth · Posted: Tue May 15, 2018 3:32 am Post subject:

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!
_________________
Ever picture systemd as what runs "The Borg"?

steveL · Posted: Tue May 15, 2018 5:37 pm Post subject:

Tony0945 · Posted: Tue May 15, 2018 11:40 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

The_Great_Sephiroth · Posted: Wed May 16, 2018 2:14 am Post subject:

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?

_________________
Ever picture systemd as what runs "The Borg"?

Tony0945 · Posted: Thu May 17, 2018 2:52 am Post subject:

From a recent NeddySeagoon post:

steveL · Posted: Thu May 17, 2018 3:30 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

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