[coreboot] Re: failure cherry-picking patches from https://review.coreboot.org/coreboot
On Thu, May 20, 2021 at 11:05 PM Bensaid, Selma wrote: > Thanks Peter and Aaaron! > For more context we observe this failure on our local coreboot hosted in > GitHub (Intel Org). Cherry-picking from coreboot.org worked well until > few days ago, where the failure showed up. > Looking into the logs (that I cannot attach) and if I understand well > while fetching from a remote git looks for a common ancestor between the > local repo and the remote. In our case this common ancestor is quite old ( > https://review.coreboot.org/c/coreboot/+/34368). It seems that the remote > (coreboot.org) has a timeout mechanism that triggers before we find the > common ancestor. > I think I figured out a dirty WA ☹, any idea will be more than welcome! > This is not original thought, but since the ancestor is so old maybe it is the solution in the article: raise limits to get all the SHAs of the trees and objects. If it's too big then that might cause the hangup. I think it'd be good for someone on your end to do a proper rebase. Once that's complete I expect the fetchting to start working again. > Thanks, > Selma. > > > -Original Message- > From: Peter Stuge > Sent: Thursday, May 20, 2021 10:57 AM > To: coreboot@coreboot.org > Subject: [coreboot] Re: failure cherry-picking patches from > https://review.coreboot.org/coreboot > > Aaron Durbin via coreboot wrote: > > > We are observing since 3 days instabilities while cherry-picking > > > patches from coreboot.org: > > > > > > git fetch https://review.coreboot.org/coreboot > > > refs/changes/40/52140/3 && git cherry-pick FETCH_HEAD > > > > > > fatal: The remote end hung up unexpectedly > > > > > > fatal: protocol error: bad pack header > > > > > > This is happening on several machines, our automation is also impacted. > > > Any change/issue that could explain such behavior? > > > > I think it's on your end, Selma. Perhaps the git repo got corrupted? > .. > > The root cause is likely the first error: remote end hung up > unexpectedly. > > The following might be helpful. > > > > https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-une > > xpectedly-while-git-cloning > > My guess is either a change in an outgoing proxy at Intel or that all your > repos changed in the same way at the same time to now interact badly with > how outgoing proxying has always worked. (HTTP request larger than > http.postBuffer git config setting leading to HTTP/1.1 chunked transfer.) > > > > Also if there's a way to get more verbose logging out that might help > > point in the right direction. > > Do try (from that stackoverflow): > > # Linux > > export GIT_TRACE_PACKET=1 > > export GIT_TRACE=1 > > export GIT_CURL_VERBOSE=1 > > > #Windows > > set GIT_TRACE_PACKET=1 > > set GIT_TRACE=1 > > set GIT_CURL_VERBOSE=1 > > > Before the git command, and see what comes out. > > > //Peter > ___ > coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an > email to coreboot-le...@coreboot.org > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
Hi Thanks for sharing your findings. THe flash is 256K big, which is quite small these days. When building coreboot with default settings but without a payload I find that there is 69K empty space left for payloads. Some future developments I have been working on might give a bit more breathing space. - I want to make romstage optional and include the sources in the bootblock: That should shave off roughly 10K of romstage. - I have compressing postcar working (maybe you can also disable the postcar console to reduce size). That's also 2-3k size gains at likely the const of a tiny bit of boot performance on this platform. - I also have some WIP code to merge postcar into ramstage which would save 15k. Maybe on coreboot release 4.15 you will have a better time building a fully working image with the default configuration. Kind regards Arthur Heymans On Fri, May 21, 2021 at 7:08 AM Paul Menzel wrote: > Dear Branden, > > > Am 21.05.21 um 05:36 schrieb Branden Waldner: > > When testing the latest coreboot code before the 4.14 release, I found > > I couldn't build a working image with the default (or what I usually > > use) config for the asus/p2b. I figured out that it failed to build > > with an error of not enough space in cbfs after the merge to enable > > bootblock console for intel 440bx. > > Following this, I just disabled microcode firmware to free up space > > and it worked fine, even without the microcode update. Specifically > > selecting the microcode for the cpu I'm using would probably be better > > though. > > I'm just commenting on my findings, not really expecting anything. I > > had intended on trying to obtain some larger flash chips yet, though I > > never got around to it. It would still leave a broken default build > > config though with the standard rom size. > > Thank you for sharing your findings. All default configurations are > tested – without a payload though I believe –, so please attach your > configuration, `defconfig` created by `make savedefconfig`, and your > payload and size. > > > Kind regards, > > Paul > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
Dear Branden, Am 21.05.21 um 05:36 schrieb Branden Waldner: When testing the latest coreboot code before the 4.14 release, I found I couldn't build a working image with the default (or what I usually use) config for the asus/p2b. I figured out that it failed to build with an error of not enough space in cbfs after the merge to enable bootblock console for intel 440bx. Following this, I just disabled microcode firmware to free up space and it worked fine, even without the microcode update. Specifically selecting the microcode for the cpu I'm using would probably be better though. I'm just commenting on my findings, not really expecting anything. I had intended on trying to obtain some larger flash chips yet, though I never got around to it. It would still leave a broken default build config though with the standard rom size. Thank you for sharing your findings. All default configurations are tested – without a payload though I believe –, so please attach your configuration, `defconfig` created by `make savedefconfig`, and your payload and size. Kind regards, Paul ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: failure cherry-picking patches from https://review.coreboot.org/coreboot
Thanks Peter and Aaaron! For more context we observe this failure on our local coreboot hosted in GitHub (Intel Org). Cherry-picking from coreboot.org worked well until few days ago, where the failure showed up. Looking into the logs (that I cannot attach) and if I understand well while fetching from a remote git looks for a common ancestor between the local repo and the remote. In our case this common ancestor is quite old (https://review.coreboot.org/c/coreboot/+/34368). It seems that the remote (coreboot.org) has a timeout mechanism that triggers before we find the common ancestor. I think I figured out a dirty WA ☹, any idea will be more than welcome! Thanks, Selma. -Original Message- From: Peter Stuge Sent: Thursday, May 20, 2021 10:57 AM To: coreboot@coreboot.org Subject: [coreboot] Re: failure cherry-picking patches from https://review.coreboot.org/coreboot Aaron Durbin via coreboot wrote: > > We are observing since 3 days instabilities while cherry-picking > > patches from coreboot.org: > > > > git fetch https://review.coreboot.org/coreboot > > refs/changes/40/52140/3 && git cherry-pick FETCH_HEAD > > > > fatal: The remote end hung up unexpectedly > > > > fatal: protocol error: bad pack header > > > > This is happening on several machines, our automation is also impacted. > > Any change/issue that could explain such behavior? > > I think it's on your end, Selma. Perhaps the git repo got corrupted? .. > The root cause is likely the first error: remote end hung up unexpectedly. > The following might be helpful. > > https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-une > xpectedly-while-git-cloning My guess is either a change in an outgoing proxy at Intel or that all your repos changed in the same way at the same time to now interact badly with how outgoing proxying has always worked. (HTTP request larger than http.postBuffer git config setting leading to HTTP/1.1 chunked transfer.) > Also if there's a way to get more verbose logging out that might help > point in the right direction. Do try (from that stackoverflow): # Linux export GIT_TRACE_PACKET=1 export GIT_TRACE=1 export GIT_CURL_VERBOSE=1 #Windows set GIT_TRACE_PACKET=1 set GIT_TRACE=1 set GIT_CURL_VERBOSE=1 Before the git command, and see what comes out. //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
When testing the latest coreboot code before the 4.14 release, I found I couldn't build a working image with the default (or what I usually use) config for the asus/p2b. I figured out that it failed to build with an error of not enough space in cbfs after the merge to enable bootblock console for intel 440bx. Following this, I just disabled microcode firmware to free up space and it worked fine, even without the microcode update. Specifically selecting the microcode for the cpu I'm using would probably be better though. I'm just commenting on my findings, not really expecting anything. I had intended on trying to obtain some larger flash chips yet, though I never got around to it. It would still leave a broken default build config though with the standard rom size. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: failure cherry-picking patches from https://review.coreboot.org/coreboot
Aaron Durbin via coreboot wrote: > > We are observing since 3 days instabilities while cherry-picking patches > > from coreboot.org: > > > > git fetch https://review.coreboot.org/coreboot refs/changes/40/52140/3 && > > git cherry-pick FETCH_HEAD > > > > fatal: The remote end hung up unexpectedly > > > > fatal: protocol error: bad pack header > > > > This is happening on several machines, our automation is also impacted. > > Any change/issue that could explain such behavior? > > I think it's on your end, Selma. Perhaps the git repo got corrupted? .. > The root cause is likely the first error: remote end hung up unexpectedly. > The following might be helpful. > > https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-unexpectedly-while-git-cloning My guess is either a change in an outgoing proxy at Intel or that all your repos changed in the same way at the same time to now interact badly with how outgoing proxying has always worked. (HTTP request larger than http.postBuffer git config setting leading to HTTP/1.1 chunked transfer.) > Also if there's a way to get more verbose logging out that might > help point in the right direction. Do try (from that stackoverflow): # Linux export GIT_TRACE_PACKET=1 export GIT_TRACE=1 export GIT_CURL_VERBOSE=1 #Windows set GIT_TRACE_PACKET=1 set GIT_TRACE=1 set GIT_CURL_VERBOSE=1 Before the git command, and see what comes out. //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: failure cherry-picking patches from https://review.coreboot.org/coreboot
On Wed, May 19, 2021 at 6:25 PM Bensaid, Selma wrote: > Hi, > > We are observing since 3 days instabilities while cherry-picking patches > from coreboot.org: > > git fetch https://review.coreboot.org/coreboot refs/changes/40/52140/3 && > git cherry-pick FETCH_HEAD > > fatal: The remote end hung up unexpectedly > > fatal: protocol error: bad pack header > > This is happening on several machines, our automation is also impacted. > Any change/issue that could explain such behavior? > I think it's on your end, Selma. Perhaps the git repo got corrupted? I just tried your instructions and the fetch was successful. The root cause is likely the first error: remote end hung up unexpectedly. The following might be helpful. Also if there's a way to get more verbose logging out that might help point in the right direction. https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-unexpectedly-while-git-cloning > Thanks, > > Selma. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Free coreboot training! - and how you can help it
This summer, free & open-source OpenSecurityTraining website - will be relaunched as OpenSecurityTraining2 ( https://x.ost.fyi/ ) with even higher quality free training courses! Since Piotr Król volunteered as a content provider for coreboot-related topics, we at 3mdeb developed a new "Architecture 4031: x86-64 Reset Vector Implementation: coreboot" course. And now, we're looking for beta testers for the introductory coreboot class. If you: * learned coreboot elsewhere and willing to provide your expert feedback, * or you are getting started with coreboot and want to learn it faster, - please help us to improve this class! Feel free to share your valuable ideas, and even the fixes for the auto-generated captions will be a huge help. Beta testing will end by mid-June, so - if you're interested in this course, please subscribe by this link to access its' beta version - https://newsletter.3mdeb.com/subscription/23ERA9Fb0 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
