coreboot

coreboot@coreboot.org

3 participants
39681 discussions

[coreboot - Bug #276] SPI flash console output causes `SMM Handler caused a stack overflow`
by Filip Lewiński 21 Jun '24

21 Jun '24

Issue #276 has been updated by Filip Lewiński. Paul Menzel wrote: > On the Lenovo T60 (Type 2007 with dedicated ATI/AMD graphics device), coreboot built with *SPI Flash console output* (`CONFIG_CONSOLE_SPI_FLASH=y`) fails to boot due to a stack overflow: > > ``` > FMAP: area COREBOOT found @ 60200 (1703424 bytes) > CBFS: Locating 'fallback/dsdt.aml' > CBFS: Found @ offset 39300 size 3138 > FMAP: area COREBOOT found @ 60200 (1703424 bytes) > CBFS: Locating 'fallback/slic' > CBFS: 'fallback/slic' not found. > ACPI: Writing ACPI tables at bfb51000. > ACPI: * FACS > ACPI: * DSDT > FMAP: area CONSOLE found @ 0 (131072 bytes) > > > coreboot-4.12-1529-gaba8103093 Sun Jul 19 07:24:18 UTC 2020 smm starting (log level: 7)... > canary 0x0 != 0xbfeffc00 > SMM Handler caused a stack overflow > ``` I've experienced the same with coreboot+EDK2(MrChromeBox) on a Thinkpad T400. If you still have trouble booting the platform, I've somehow managed to bypass it by rebuilding with 64bit mode enabled. ---------------------------------------- Bug #276: SPI flash console output causes `SMM Handler caused a stack overflow` https://ticket.coreboot.org/issues/276#change-1863 * Author: Paul Menzel * Status: New * Priority: Normal * Start date: 2020-07-19 ---------------------------------------- On the Lenovo T60 (Type 2007 with dedicated ATI/AMD graphics device), coreboot built with *SPI Flash console output* (`CONFIG_CONSOLE_SPI_FLASH=y`) fails to boot due to a stack overflow: ``` FMAP: area COREBOOT found @ 60200 (1703424 bytes) CBFS: Locating 'fallback/dsdt.aml' CBFS: Found @ offset 39300 size 3138 FMAP: area COREBOOT found @ 60200 (1703424 bytes) CBFS: Locating 'fallback/slic' CBFS: 'fallback/slic' not found. ACPI: Writing ACPI tables at bfb51000. ACPI: * FACS ACPI: * DSDT FMAP: area CONSOLE found @ 0 (131072 bytes) coreboot-4.12-1529-gaba8103093 Sun Jul 19 07:24:18 UTC 2020 smm starting (log level: 7)... canary 0x0 != 0xbfeffc00 SMM Handler caused a stack overflow ``` -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

VBT versions compatibility with different FSP/GOP versions
by Paul Menzel 18 Jun '24

18 Jun '24

Dear coreboot folks, I noticed commit 5d1494adda44 (mb/system76/tgl: Update VBTs to version 250) [1]: > mb/system76/tgl: Update VBTs to version 250 > > Commit 4c7e97b26a34 ("Update fsp submodule to upstream master branch") > included an update to the VBT from 240 to 250, breaking parsing of > existing VBTs. > > After that commit, the VBT was parsed as (from gaze16-3060-b): > > [DEBUG] PCI: 00:02.0 init > [INFO ] GMA: Found VBT in CBFS > [INFO ] GMA: Found valid VBT in CBFS > [INFO ] framebuffer_info: bytes_per_line: 4096, bits_per_pixel: 32 > [INFO ] x_res x y_res: 1024 x 768, size: 3145728 at 0xd0000000 > [DEBUG] PCI: 00:02.0 init finished in 6 msecs > > When the expected output is: > > [DEBUG] PCI: 00:00:02.0 init > [INFO ] GMA: Found VBT in CBFS > [INFO ] GMA: Found valid VBT in CBFS > [INFO ] framebuffer_info: bytes_per_line: 7680, bits_per_pixel: 32 > [INFO ] x_res x y_res: 1920 x 1080, size: 8294400 at 0xd0000000 > [DEBUG] PCI: 00:00:02.0 init finished in 6 msecs > > Generate blobs for the new version using Intel Display Configuration > Tool (DisCon) v3.3, based on the existing 237 and 240 VBTs. > > (For our edk2 payload, the UEFI GOP driver was updated to 17.0.1077.) Updating the submodule pointer of 3rdparty/fsp brings in commit 849ce8261bb0 (Tiger Lake FSP A.0.7E.70) with no commit message body. The diff contains: TigerLakeFspBinPkg/Client/SampleCode/Vbt/Vbt.json @@ -23891,7 +24584,7 @@ }, { "WidgetType": "Label", - "WidgetName": "VBT Version: 240", + "WidgetName": "VBT Version: 250",^M "Visibility": "", "Data": [], "HelpText": "", Vladimir (φ-coder) also published the tool intelvbtupgrader [2] to address this problem. I would have assumed that FSP versions would be backwards compatible. I attache the output of `intel_vbt_decode` of both VBT files. Does somebody have more insight? Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/82246 [2]: https://review.coreboot.org/c/coreboot/+/82722

1 0

MrChromebox-2405 Release Announcement
by Matt DeVillier 17 Jun '24

17 Jun '24

As coreboot changed its version numbering to a YYMM scheme earlier this year, MrChromebox releases will now do the same. This new release is based on the coreboot 24.05 tag (May 2024) and now supports well over 300 different devices. It includes the following notable changes: - Rebased on coreboot tag 24.05 - Added support for several new Intel Jasperlake boards (beadrix, boxy, dexi, peezer, taranza) - Added latest Google-built EC-RW updates for all Jasperlake boards - Updated the EC-RW firmware for Fizz boards (Intel 7th/8th-gen Chromeboxes) - Updated the EC-RW firmware for Zork boards (AMD Picasso) - Updated the signed PSP verstage binaries for Zork/Guybrush boards (AMD Picasso, Cezanne) - Updated EC-RW software update code for improved compatibility - Fixed SMBUS subsystem ID on several Sandy/Ivybridge Chromebooks - Increased the UMA VRAM to 128MB on Zork boards (AMD Picasso boards) - Filtered out some spurious error messages in the coreboot console log All source code (and blobs) for coreboot, edk2, and Chrome-EC can be found on my github repos: https://github.com/MrChromebox/coreboot/commits/MrChromebox-2405 https://github.com/MrChromebox/edk2/commits/uefipayload_2402 https://github.com/MrChromebox/chrome-ec/branches/all https://github.com/MrChromebox/blobs/ For device compatibility and installation, see https://mrchromebox.tech cheers, Matt

1 0

2024-06-12 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 13 Jun '24

13 Jun '24

# 2024-06-12 - coreboot Leadership Meeting ## Attendees Werner Zeh, Matt DeVillier, David Hendricks, Mina Asante, Jonathan Hall, Martin Roth, Felix Singer, Felix Held, Nico Huber, Jay Talbott, Rhys Perry, Karthik Ramasubramanian, Shelley Chen, Nicholas Chin, Ron Minnich, Mike Banon, Julius Werner, Marshall Dawson. ## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing * OSFC will be in Bochum Germany - September 3-5 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-03-20 * Martin:To Add a note to the gerrit guidelines to email the leadership for further discussion and guidance when code submissions are not up to standard. * 2024-03-06 * Martin: To update gerrit contributing guidelines documentation. (https://doc.coreboot.org/contributing/index.html) * 2024-01-10 * Nico: [https://review.coreboot.org/q/topic:enforce_region_api] * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Felix S/Martin] We’ve got a OSFF booth accepted for [FOSSY conference](https://sfconservancy.org/fossy) * 1st - 4th August * Looking for volunteers to help with the booth. * Please reach out to FelixS or Martin if you’re interested. We might be able to help out some with travel or hotel costs. ### [Martin] Infrastructure * We need additional people to help with coreboot infra. * Using NixOS for the base OS * Docker images for gerrit, jenkins, other services. * Reach out to coreboot leadership if interested. * Felix will be the infra lead, but if we can’t find people in the community, we may need to hire someone (some company) to help with this. * Obviously this will cost the project cash * [MattD] We need a backstop, even if we have volunteers, so hiring a company would probably be good anyway. * If any or our contract companies have recommendations, please suggest good companies. ### [Elyes] Add lint rule to avoid duplicated includes. * I’ve added some lint rules to warn when a header is duplicated through another header which is supposed to provide it. (see [https://review.coreboot.org/c/coreboot/+/81907]) The rules I’ve used are those in: ``Documentation/contributing/coding_style.md`` As per Nico’s comments, we need some rules (if this is something we want to do.) * Headers can still be included in other header files. * [Martin]: This is (or should be) just enforcing what’s already documented in the coding style document. If this is a bad idea, let’s remove it from the coding style and not have a conflict between what we’re willing to enforce and the coding style guide. * [Nico]: This could make updating headers more difficult. * [Ron]: This seems like a slippery slope - do we want to alphabetize the header list? Christmas tree header list. * Those aren’t how we do things here. No required alphabetization or other styles for headers. * [David]: IWYU may make things fragile. Good in theory, if it's easy and reliable to use/enforce then we should do it. * [Julius]: The coding style wastes reviewers time. Do we really need to worry about this? * [Martin]: This patch would fix that. * [Nico]: Do we want to just prohibit bulk cleanups? * [Martin]: Does that mean we should get rid of the coding style? If we’re not going to enforce it, why have it? * [Nico]: it’s good for new users. * [FelixS]: could IWYU be used instead of self-written scripts to supply suggestions? * [David]: Maybe we should roll this out slowly before enforcing it. Hopefully this won’t introduce a bunch of Diffs. * The work is already done, so let’s prevent new style violations from going in. * [Martin]: Can we agree that we can submit this and if it causes issues we can roll it back? * [David]: We shouldn’t block it unless we can articulate exactly why it’s a problem. Let’s think about it for a week and if there aren’t any explicit issues, then let’s merge it. ### [Yidi Lin] [Do we consider GPIO ball names definitions in <soc/gpio.h> as part of <gpio.h>](https://review.coreboot.org/c/coreboot/+/82813/1/src/mainboard/google/kukui/gpio.h) ? * This is related to the above header issue. * Listed in the style guide as an example * [Nico]: These two gpio headers aren’t really the same thing. One is hardware, the other is the general function headers. * [Matt]: Does the main GPIO.h automatically include soc/gpio.h? * Felix: Yes, and includes the IWYU annotation that it should be supplied. * [Matt]: As long as we’re being consistent across the codebase, it should be fine. It looks like we’re normally including soc/gpio.h in mainboards. There are currently 364 instances of that - so let’s not change it to comply with the style guide. Let’s update the style guide and update the patch. * [Julius]: Let’s just leave things as they are and not do bulk updates. * [Jonathan]: This seems like a misinterpretation of the style guide - it’s saying that you don’t need to include both. It doesn’t seem to say that you should use gpio.h instead. Let’s edit the style guide to clarify this. * **Decision**: Let’s just edit the style guide for clarity and not force inclusion. That means that we’d drop these patches (unless the board owner prefers it.) ### [Felix H] Usage of LLM outputs making the commit messages bad * I’ve seen commit messages (patchset 2 of 82871, 82872) that look very much like output from some LLM that say little in much text and I’d very much prefer that we keep commit messages concise, so I’d like to discuss if we want to allow usage of LLM output and if so how we should make sure to mainly get possible advantages of that but keep the disadvantages to a minimum * [Martin] Yes, I think we want to allow the output from LLMs in patch descriptions, in fact I was just talking about creating some automation to generate a description of the patch that could be (optionally) used to update the commit message. People who are less fluent in English could really benefit from this. * [Martin]: Let’s just say that commit messages should be concise and related to the patch. ### [Karthik] RFC - Extend Coreboot FileSystem to disk * [Extend CBFS to Storage Media](https://docs.google.com/document/d/1LFXIr38_u2bnXY9G6-uJHYxIAFqwX9tU… Look at the document for reasoning. Please review it and make comments. * [Martin]: I kind of hate the idea of loading firmware from the drive for stages before the payload - this feels like a slippery slope and that next we’re going to need network drivers in coreboot to support loading the firmware over the network. Payload can do what it wants. * [David]: This sort of thing is pretty normal in the non-x86 world. * [Werner]: The mass storage device is really owned by the OS. If the firmware is on the drive, we could break the boot when the drive is formatted or replaced. * [Karthik]: only boot critical components would be moved to the disk. * [Martin/Felix]: This seems like a large security hole - your system can be owned from the boot firmware instead of just the OS. * [Julius]: This is just extending cbfs to the disk and not a part of an OS file system. This is mainly intended for CSME update. This would be only Ramstage or later and would be optional. * [Werner]: Requires adding mass storage devices. Allows coreboot to read the entire disk. How does that affect security? * [David]: Let’s assume that Google didn't screw up their implementation, and focus on how this would fit into upstream or if it should be blocked. It seems like it could be an advantage for cost savings (as Julius points out) by making it so laptop vendors don't need a huge flash chip for things like CSME binaries. * [Martin]: This needs further discussion, so please review the document and make comments there. In general I feel like if something is needed by some coreboot users, we should try to be accepting of their needs (assuming that it’s not adding additional binary blobs. # Next Leadership Meeting * June 26,2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes *[2024-06-12](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit?p1).

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 12 Jun '24

12 Jun '24

Issue #121 has been updated by Patrick Rudolph. > I tried booting with kernel command line parameter idle=nomwait. That should make the OS use the `hlt` instruction instead of `mwait`, which is similar to package C1-state. When using `powertop` or similar tools it should show how much time it spends in specific C-states. I would expect it to draw a bit more power, but probably just ~1Watt. > not in my case (t520i, i7-3840qm) - its almost as if the freezes are more frequent with this option 🤷 I would also expect it to not freeze any more, since C1-states where reported to be working fine. Quote: > As an update to the above, intel_idle.max_cstate=3 was not stable but intel_idle.max_cstate=2 was and I haven't had any crashes in about a month. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1860 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Anastasios Koutian 12 Jun '24

12 Jun '24

Issue #121 has been updated by Anastasios Koutian. Alex Gravitos wrote in #note-97: > Anastasios Koutian wrote in #note-96: > > I tried booting with kernel command line parameter idle=nomwait. > > There were no freezes for 1 week, 5 days and 16 hours, which was not possible previously. > > After this, I powered down and removed the parameter to see what happens. The system froze after 15 hours and 7 minutes. > > Intel PCM is showing no negative impact on idle power consumption with idle=nomwait. > > I recommend to people following this bug to try this out and confirm if it works for them. > > not in my case (t520i, i7-3840qm) - its almost as if the freezes are more frequent with this option 🤷 That's interesting. I have not seen freezes since adding this option, but it's possible that it's just a coincidence, since this bug is quite random. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1859 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Alex Gravitos 12 Jun '24

12 Jun '24

Issue #121 has been updated by Alex Gravitos. Anastasios Koutian wrote in #note-96: > I tried booting with kernel command line parameter idle=nomwait. > There were no freezes for 1 week, 5 days and 16 hours, which was not possible previously. > After this, I powered down and removed the parameter to see what happens. The system froze after 15 hours and 7 minutes. > Intel PCM is showing no negative impact on idle power consumption with idle=nomwait. > I recommend to people following this bug to try this out and confirm if it works for them. not in my case (t520i, i7-3840qm) - its almost as if the freezes are more frequent with this option 🤷 ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1858 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[Invitation - Tomorrow 4PM UTC] Dasharo "User Group #6 & Developers vPub 0xB" event
by Mike Banon 12 Jun '24

12 Jun '24

Dear Friends, I invite you to Dasharo "User Group (DUG) #6 & Developers vPub 0xB" joint event that starts tomorrow at 4 PM UTC ! 1) on DUG we will discuss the Dasharo coreboot firmware distribution and explore the new supported platforms: in particular you will see a special demo of upcoming NovaCustom V54/V56 laptops with modern & powerful Intel 14th Gen Meteor Lake CPUs 2) vPub will feature our prominent guests from Intel and Karlsruhe Institute of Technology with a couple of interesting talks, and a cosy free-for-all chat about anything opensource firmware/hardware-related! ;-) Join links & full schedule are available here - https://vpub.dasharo.com/e/13/dasharo-user-group-6 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 10 Jun '24

10 Jun '24

Dear coreboot community, Please note that our upcoming coreboot leadership meeting is scheduled for Wednesday, June 12, 2024.[1] You are welcome to review and update the current agenda items with any matters you wish to see discussed during the meeting.[2] Below are the items currently on the agenda. ## Current Agenda Items ### [Elyes] Add lint rule to avoid duplicated includes. * I’ve added some lint rules to warn when a header is duplicated through another header which is supposed to provide it. (see https://review.coreboot.org/c/coreboot/+/81907 ). The rules I’ve used are those in: `Documentation/contributing/coding_style.md` As per Nico’s comments, we need some rules… ### [Yidi Lin] Do we consider GPIO ball names definitions in <soc/gpio.h> as part of <gpio.h> ? ## Improving coreboot processes ### [Martin] bi-weekly review meetings * In an attempt to get patches merged more quickly, we’re looking at adding a meeting to review patches and try to get blocking issues sorted out. This will start as a bi-weekly meeting of 1 hour and we’ll see where things progress from there. Any preference for Tues/Wed/Thurs? 16:00, 17:00, or 18:00 UTC? (should we define it in UTC or in some other timezone that may switch based on daylight savings?) ### [Martin] Merge SLOsl * Can we define objectives for timeframes to get patches merged to different areas in the codebase? An individual mainboard that doesn’t affect the rest of the codebase doesn’t need as much scrutiny as core code that affects every platform. ## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing * OSFC will be in Bochum Germany - September 3-5, 2024 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

Re: Gerrit is auto-closing replies to last comment on change logs. Bug?
by Keith Hui 09 Jun '24

09 Jun '24

Hi Max, > I have the same issue but only quite rarely. I assumed the issue was gone since I did not have it for quite a while (~3 months). Although I am not sure if it only happened for me on the most recent comments. I assumed it was just bad javascript from gerrit. By any chance are you using your smartphone to answer comments? Mostly smartphone, but also happened on my laptop. > > greetings, > Max Cheers Keith

2 1

← Newer
1
...
7
8
9
10
11
12
13
...
3969
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot