Hyperion Entertainment Message Boards

xeno74 wrote: Wed Oct 06, 2021 4:52 pm I don't know what we can do next. What should we do next?

I do not see any other way forward than go back to rb4 and continue to hunt the 'type 1' issue as I originally did. I could also test whether removing the SCSI controller has any effect... But that would not tell which amendment in 4.10 caused the issue.

Anyway, we must have a brake in testing as I will be a few weeks away from my machine.

OK, please report if you have new results for the rb4, rb5 etc.

xeno74 wrote: Wed Oct 06, 2021 11:08 pm OK, please report if you have new results for the rb4, rb5 etc.

I'm now back to my own machine and restarted testing from rb4.... Do you have time to make new bisects?

Roland wrote: Sat Nov 20, 2021 8:22 pm I'm now back to my own machine and restarted testing from rb4.... Do you have time to make new bisects?

Yes, I have. Could you please test the first test kernels carefully? If you don’t test the kernels carefully then the next test kernels will have all wrong bisect results.

xeno74 wrote: Sun Nov 21, 2021 8:09 am Yes, I have. Could you please test the first test kernels carefully? If you don’t test the kernels carefully then the next test kernels will have all wrong bisect results.

Yes I will... I have already been testing rb4 two days, no problems seen so far. But to be sure we are on the right track, I retested today rb2 which was originally the first 'bad' test kernel, and now I got the problem visible as soon as I opened a stream in VLC. So, rb2 is definitely 'bad'! Now I'm retesting rb3 to check if it is really 'good' as it seemed to be in earlier tests.

It came tro my mind.... Would it be possible to test this kind of issue also with 'fifty-fifty' method, so that you would always have a pair of kernels to test side-by-side, one of which forcibly includes the problematic component? In theory the continuous bisect method is faster, but when the problem is not automatically seen, fifty-fifty method would give faster the correct result as you can switch to test the other kernel of the pair if the issue is not immediately seen with the other one.

Roland wrote: Sun Nov 21, 2021 3:10 pm It came tro my mind.... Would it be possible to test this kind of issue also with 'fifty-fifty' method, so that you would always have a pair of kernels to test side-by-side, one of which forcibly includes the problematic component?

Unfortunately it isn’t possible.

Have not encountered problems with rb3 nor rb4. I think we can now continue...

rb4 "git bisect good"

Roland wrote: Mon Nov 22, 2021 8:11 pm Have not encountered problems with rb3 nor rb4. I think we can now continue...

rb4 "git bisect good"

But you had big problems with the rb4.

Roland wrote: Wed Sep 29, 2021 5:18 pm I got now the issue third time... This time the system did not freeze immediately, and when I moved the terminal window around on the desktop it created quite a mess on the screen.

So, "git bisect bad" for rb4!

I think I have now a 'recipe' how to recreate the issue within a half an hour. This will simplify further tests...

Please also test the RC2 of kernel 5.16. I'd like to know if this issue still exists.

xeno74 wrote: Mon Nov 22, 2021 8:22 pm
But you had big problems with the rb4.

That was because I used the new 'test setting' which showed a different problem, also with the earlier kernel generations, and derouted our testing! Now I'm back to the original testing (for hunting the 'Type 1' problem), which was the whole idea of this new testing process. You seem to have forgotten that...