Charlie Romer Posted May 9 Share Posted May 9 2 minutes ago, Igor said: We are on the same side. This is what I've been trying to say the whole time... I know many distros are small projects with no full time developers. I saw in this thread that it looked like you guys could use some help and given how new this board is I wasn't expecting anyone to just solve something for me. I wanted to jump in and help if and where I could. What did you expect? Truth or fake happiness and prompt resolving of your problem? The opposite literally. I figured that if I have the ability to help and hardware in hand that I should help (or at least offer to be a guinea pig) - I wasn't and haven't been looking for someone to solve this thing for me but literally offering my assistance as I happen to have the hardware and wanted to give back if I could. This whole conversation has felt like I've been gaslit by people who assume everyone posting for the first time on this forum must be demanding fixes for everything right now. That may be many (or even most) folks but it's not a great feeling when all you're doing is trying to offer help. 0 Quote Link to comment Share on other sites More sharing options...
going Posted May 10 Share Posted May 10 @Charlie Romer Hi. Let's try to figure it out. 5 часов назад, Charlie Romer сказал: I figured that if I have the ability to help and hardware in hand that I should help Core panic - how is this problem solved? It is assumed that you have the kernel source code. You look at the kernel messages, and then using utilities like grep you find the function in the source code. The very function that could not cope and caused panic. This appears in the kernel panic messages. The first probable reason that led to this is that a patch was incorrectly applied to a file with this function. I.e. we are looking for all patches that modified this source code file. In fact, we will need to apply all the patches in the series to the source code in the core git repository. Apply as the "git am" command. We pay special attention to those patches that change our target file. Then we extract a series of our patches from the repository using a script and place it in the target patch folder. I.e., we replace the existing series with a new one, which is applied without offsets and fuzziness. The second reason is the changes in the upstream of the kernel that led to the situation our patch has aged. In this case, we are fixing this patch. We simply make our new changes to the fixation after applying the patch in the process of applying the series step by step. The complexity of the core panic situation in the Armbian project lies in the fact that it is impossible to reproduce this particular problem. Therefore, if you did everything as I wrote and made the necessary corrections from your point of view, then assembled the kernel and the panic repeated, you simply push your changes to your repository on github and only after that you can write here on the forum or ask a question here by specifying a link to your repository and the kernel version to which corrections have been applied. Only after that, the maintainer or the interested user will be able to check it. The third possible option is that the u-boot code does not match the kernel code due to their development. We may have to monitor this loader build process as well. @Igor Did I miss something? Where did the fixed kernel version go in these settings? How is the correct application of patches controlled today? 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted May 10 Share Posted May 10 14 minutes ago, going said: How is the correct application of patches controlled today? Hasn't changed. https://github.com/armbian/build/tree/main/patch/kernel Just symlinking of subfolder are perhaps adding some confusion. 0 Quote Link to comment Share on other sites More sharing options...
going Posted May 10 Share Posted May 10 1 минуту назад, Igor сказал: Hasn't changed. https://github.com/armbian/build/tree/main/patch/kernel Just symlinking of subfolder are perhaps adding some confusion. I meant this line: KERNELBRANCH="tag:v6.1.69" which uniquely determines which version of the kernel patches are applied cleanly. I.e. to version 6.1.69 and not to the current 6.1.90 for today. 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted May 10 Share Posted May 10 1 minute ago, going said: which uniquely determines which version of the kernel patches are applied cleanly. I.e. to version 6.1.69 and not to the current 6.1.90 for today. Oh, yes. This must also work. or "commit:xxxxxxxxxxxxxxxxx" 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.