Bug #117

cbmem ringbuffer is broken

Added by Patrick Rudolph about 2 years ago. Updated about 2 years ago.

Status:NewStart date:05/14/2017
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:userspace utilities
Target version:-

Description

The new ringbuffer doesn't work as intended:
* It's not a ringbuffer at all. New lines do not overwrite old lines.
* The log starts somewhere and ends somewhere, whitout any CBMEM overflowed ... messages.
* coreboot romstage string isn't printed any more.
* Sometimes the log starts in coreboot ramstage starting ...
* The default behaviour of cbmem -c was changed. It should have the old behaviour: print the coreboot log of the current boot.
* Please add on option to print previous boots. Maybe using -1 ?

config (20.3 KB) Patrick Rudolph, 05/16/2017 05:08 PM

cbmem.tar (181 KB) Patrick Rudolph, 05/16/2017 05:19 PM

History

#1 Updated by Nico Huber about 2 years ago

See https://ticket.coreboot.org/projects/coreboot "A good ticket should contain..."

#2 Updated by Julius Werner about 2 years ago

What Nico said. Please attach the full output of 'cbmem -c' (ideally both after a warm reboot and after a cold boot from power-off) and clarify which board you're running on (ideally also attach your full .config). Make sure that your 'cbmem' utility has also been built with the latest coreboot sources.

  • The log starts somewhere and ends somewhere, whitout any CBMEM overflowed ... messages.

This sounds like your 'cbmem' may not have been updated. The old cbmem will still print the full contents of the buffer but may print it out of order.

  • The default behaviour of cbmem -c was changed. It should have the old behaviour: print the coreboot log of the current boot.

This is debatable, I'd say the old behavior was "print the whole console buffer". You can (if everything worked right, we'll need to figure out your case) still see everything you saw before, you can just also scroll a little further up now. I think that's also easier to associate with the '-c' flag, whereas I chose the '-1' flag to mean "one boot".

edit: Oh, and if possible, please also attach the output of 'cbmem -c' when you flash a coreboot that has the CBMEM console change (https://review.coreboot.org/18301) reverted (with otherwise exactly the same code). That may help narrow down if your platform already had console overflows in certain stages before that just get handled differently by the new code.

#3 Updated by Patrick Rudolph about 2 years ago

Tested on Lenovo T430 on 48dbc663d75e6b7e45e50cd099acb88b35e65a0a.
cbmem version v1.1 : b7b64a9f682

Attached config

Attached 7 logfiles:

  1. Ringbuffer reverted
  2. first boot and first boot -1
  3. second boot and second boot -1
  4. third boot and third boot -1

The -1 always starts at ramstage.
The third boot -c starts somewhere and ends somewhere.

#4 Updated by Julius Werner about 2 years ago

Thanks for the logs, I believe we're getting somewhere here.

First of all, I don't believe your ringbuffer_reverted log actually had the right patch reverted. It contains the line "*** Pre-CBMEM console overflowed, log truncated ***" which (with that exact wording) was only introduced in https://review.coreboot.org/18301. However, I think I can see enough from here to understand what you're seeing without further logs.

first_boot looks as it should to me. It ends exactly where it's supposed to end (around "Booting from Hard Disk..."). It starts with romstage output, however that output is truncated because your pre-CBMEM console buffer isn't large enough (as the message dutifully tells you). It differs from what you might have seen before because we're now only keeping the last lines of romstage (and discarding the first ones) if the pre-CBMEM buffer is too small, whereas previously we've been keeping the first lines (and been discarding the last ones). This is a sorta intentional change. You're seeing different lines from romstage now, but you've never seen all of them anyway. The real solution is to increase CONFIG_PRERAM_CBMEM_CONSOLE_SIZE for your board until it fits (note that the max amount you can set it to may be limited by hardware, though... if it just won't fit, there's not much we can do).

third_boot looks okay for coreboot but broken at the end. I believe this is because you're running SeaBIOS and you haven't updated that to support the new format. There was a separate patch for SeaBIOS that you'll need to apply to get correct console behavior: https://review.coreboot.org/cgit/seabios.git/commit/?id=19fdcca4 (You didn't mention that you were running SeaBIOS before or I could've told you earlier.)

The -1 doesn't work right because of the log truncation. I believe I may be able to improve that situation... I'll probably CC you on a patch to test in a bit.

edit: Uploaded a patch at https://review.coreboot.org/#/c/19720, please help test it out!

#5 Updated by Patrick Rudolph about 2 years ago

Tested with SeaBios 1.10.2.

#6 Updated by Julius Werner about 2 years ago

Patrick Rudolph wrote:

Tested with SeaBios 1.10.2.

That version seems to be from February (https://www.seabios.org/Releases#SeaBIOS_1.10.2), so I'm not surprised that it doesn't include the patch from April I linked you to yet. Try compiling SeaBIOS from master.

Also available in: Atom PDF