Add the 6.4.y branch:
The size of that download is 284.36 MiB.

1 members found this post helpful.

Wonderful! You always come up trumps. So I need to use linux-<maj>.<min>.y in future, not just linux-<maj>.<min>. It was pure bad luck that my first bad release this time around had a 2-digit designation.

One interesting point is that 6.5 with my first patch fails silently whereas 6.5.1 with the same patch fails with buzzing. So the patch between 6.4.16 and 6.5 (when I have found it) is not the last one I shall need. There is probably a third patch required between 6.5. and 6.5.1.

After you already gave the command of post #29 and then post #31, you can add the 6.5.y branch:
The download is 18.64 MiB this time. After that 'git tag -l' will list tags like v6.5, v6.5-rc1, v6.4.16, v6.5.1.

I have reached a blockage. And I was doing so well too!

A new download month began yesterday, so I updated my git clone using the commands suggested in this thread, and have been bisecting. Of course I included the tpm patch that I had obtained from the previous bisection before starting each actual build, since I know it won't work without that. Patching worked for the first and second runs of this new series, but now it won't accept the patch for the third run (and there are ten more to do). If I try to do it with the patch command as before, I get
If I use git apply instead, I get
What do I do now? I'm out of my depth.

I think at some point there was either a line removed or added at the position where the patch applies, and it makes the hunk fail. Check post #24 and the modified patch there. Maybe it will work.

No, it still fails with the version in #24. FYI the sequence of events which led up to this impasse was:

1) Patch and first run of this bisection: found Good. When I reported that, git refused to bisect because the code had been patched. It said to revert the patch or commit it. I don't know how to commit, so I reverted it, reported good again and got a new checkout.
2) Patch and second run: found Bad. I reported it, removed the patch as before, and got a new checkout.
3) Tried to patch again for the third run and failed. Like you, I suspect that the code had changed in the area of the patch so that it no longer fits.

The real problem here (or one of them at any rate) is that I'm out of my depth and don't really know what I am doing. I mean I know in a vague kind of way but not the details of how git works. For some time now, I've just been following orders as if I was using Windows!

Is there a way to clear all this and revert back to the beginning of the bisect, then do it again properly?

To go to, say, 6.3.6, I think this will do it: And you should be able to start bisecting withBut I guess the final result will be the same.

In post #22, there is a changelog of dozens of changes in tpm, and I guess they are connected to each other so that it may be impossible to revert single commits to make it work.

I was afraid you'd say that. What about committing the change rather than repeatedly reverting and redoing it? Would it let me do that, given that I'm not a kernel developer? That way I would only need to patch once and I assume the patch would then become a permanent part of my cloned tree, a fork effectively.

I don't know. You can try!

I had a similar problem some time ago. Bisection found the first bad commit. But the commit was one of a patch set of 34 patches, all connected. Reverting only the culprit resulted a non-compilable kernel. So did reverting all 34. I reported the bug in bugzilla.kernel.org and the developer fixed it by modifying one line of code.

No, it won't let me do what I want to do. After I committed the first patch, I started a new bisect in hopes of finding the second one. The version checked out turned out to be bad, so I've just rebooted slackware to register it. And I got
Sure! A bug has been fixed. But there is another one at least, maybe two more, and it won't let me find them. Perhaps the whole thing is just unfixable for this old machine . Both Slackware and Antix, the two systems I run in practice (because LFS has become more of a game for me than a serious endeavour) use old kernels, so it will be quite a while before I run into the buffers. I know I can can boot vanilla kernels up to 6.3.6 and I can keep going up to 6.4.16 with my existing patch.

But eventually I may just have to buy a new machine and I'm afraid that by that time, everything will have been so locked down that you won't be able to install Linux at all.

I'm going to switch focus and try some experimental builds of vanilla kernels with tpm switched off completely. I know that the later kernels won't boot like that (I've tried) but perhaps pre-6.5 kernels will. In that case, I could scrap my git tree (which is probably corrupt by now), clone another one and start from clean to find the next patch.

That sounds like a good plan. If you leave CONFIG_TCG_TPM unset and an older kernel version boots but a newer kernel doesn't, maybe you can bisect another bug not related to tpm.

Good news! Both 6.4.16 and 6.5 boot unpatched when configured with tpm switched off. These tests were both carried out with freshly untarred source, not the git clone. So the patch that I found and added to my git tree (patch no.1) isn't actually necessary on my machine. And the hypothetical patch that I'm calling "patch no.2" that lies somewhere between 6.4.16 and 6.5 (the one that I'm not allowed to test for) must also involve tpm driver code.

If 6.5.1 doesn't boot like this, then patch no.3 is not tpm-related and I might be able to use the same git clone to find it.

The joke is that I don't think my computer actually has a tpm chip. I went into the security section of my UEFI menu and couldn't see any mention of it.

Interesting.

By the way, google found something that could be relevant. Does it help if you use a stock kernel (TPM enabled) if you append this parameter to the kernel command line:

No, I tried that on a later kernel that was buzzing and it didn't help. But it looks like that particular bug was actually cleared in 6.4.4:
https://community.frame.work/t/resol...d/32956?page=3
I keep going off at a tangent! I spent most of yesterday afternoon working out a build protocol that makes my kernels behave consistently in successive builds with different configurations. It turns out that I need to start each time with an mrproper tree, not just a clean one. Who knew! Anyway I can now get 6.5 to behave itself so I am doing a full build/install of that (modules as well) before moving on to 6.5.1.

A couple of days ago I was thinking, "I've finally cracked it. I've found the buzz." But of course it's never that simple for me. I just have the world's worst luck.

A week back, I did an overnight download of the git branch that ends in 6.5.2, the earliest release that buzzes and I've been working on it at intervals. A normal git bisection revealed the attached commit. So I patched 6.5.2, reverting the two changes from alloc to zalloc, and now 6.5.2 boots without buzzing. Hallelujah!

Not! Because when I patched 6.5.3 in the same way, guess what: it refused to boot and just buzzed at me. It's the same as with those earlier tpm errors; there must be a whole slew of successive changes in that code. And I already know from that earlier experience that trying to bisect privately patched code doesn't work. But tpm is only a driver (and an unnecessary one in my case because my machine doesn't actually have a tpm facility) so I was able to just switch it off during configuration. I don't think I can switch off this thing.

It begins to look as if my much-loved desktop computer is doomed. And I resent it. I resent being expected to shell out a couple of hundred pounds for a second-hand laptop (or even more for a new one) when my existing machine otherwise works well. I really dislike laptops but that's all anybody sells nowadays. Even the second hand machines are laptops. Grrr!!

Attached Files

	buzz-diagnostic.txt (1.4 KB, 4 views)
	buzz-patch.txt (893 Bytes, 3 views)