Quiet mode is not so quiet

[maxnet]

When specifying "quiet" in cmdline.txt there should not be any console output unless something goes fatally wrong.
Instead various modules still output to console:

timer_set_mode: unhandled mode:1 timer_set_mode: unhandled mode:3 bcm2708_gpio: bcm2708_gpio_probe c0cffc18 vcos: [1]: vchiq: initialised - version 2 (min 2), device 251.0 drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

Please refrain from using loglevel KERN_ERR for informational messages.

arch/arm/mach-bcm2708/bcm2708.c: printk(KERN_ERR "timer_set_mode: unhandled mode:%d\n", arch/arm/mach-bcm2708/bcm2708_gpio.c: printk(KERN_ERR DRIVER_NAME ": bcm2708_gpio_probe %p\n", dev) drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c: vcos_log_error("vchiq: initialised - version %d (min %d), device %d.%d",

[rebroad]

speaking of which, what is the "drivers/rtc/hctosys.c: unable to open rtc device (rtc0)" message about?

[Ferroin]

@rebroad it means that the rtc driver which tries to set the system time from the first RTC device it can find didn't find any RTC's.

@maxnet from the point of view of a developer, the first two messages are errors, and the last one could be considered as such.

[maxnet]

The way I see it is that the function chooses not to handle CLOCK_EVT_MODE_SHUTDOWN and CLOCK_EVT_MODE_RESUME.

It would only have been an error if it was known to the calling code beforehand that those were not implemented.

[popcornmix]

I can get rid most of the errors.
Removing:
CONFIG_RTC_HCTOSYS
gets rid of the RTC one. This may upset some RTC users. Any thoughts?

[maxnet]

"CONFIG_RTC_HCTOSYS: Set system time from RTC on startup and resume"

I wonder if that option even works given that in the defconfig the support for individual RTC chips is build as module instead of built-into the kernel.
If it tries to fetch the time when booting the kernel, no modules are loaded yet.

Perhaps double-check with someone that has a RTC unit if that option does anything?

[maxnet]

From the full description:

config RTC_HCTOSYS
    bool "Set system time from RTC on startup and resume"
    default y
    help
      If you say yes here, the system time (wall clock) will be set using
      the value read from a specified RTC device. This is useful to avoid
      unnecessary fsck runs at boot time, and to network better.

config RTC_HCTOSYS_DEVICE
    string "RTC used to set the system time"
    depends on RTC_HCTOSYS = y
    default "rtc0"
    help
      The RTC device that will be used to (re)initialize the system
      clock, usually rtc0. Initialization is done when the system
      starts up, and when it resumes from a low power state. This
      device should record time in UTC, since the kernel won't do
      timezone correction.

      The driver for this RTC device must be loaded before late_initcall
      functions run, so it must usually be statically linked.

      This clock should be battery-backed, so that it reads the correct
      time when the system boots from a power-off state. Otherwise, your
      system will need an external clock source (like an NTP server).

      If the clock you specify here is not battery backed, it may still
      be useful to reinitialize system time when resuming from system
      sleep states. Do not specify an RTC here unless it stays powered
      during all this system's supported sleep states.

Like I expected: "The driver for this RTC device must be loaded before late_initcall functions run, so it must usually be statically linked."

Since no support for RTC devices is statically build into the kernel, removing the option shouldn't make a difference.
Think RTC users use their own startup script that loads module, and sets clock.

[popcornmix]

@maxnet
Thanks for info. I'll remove the option.

[popcornmix]

Latest kernel should be quiet.

[maxnet]

Thanks.
Boot is now more silent.

With CMA enabled still have the following messages left:

[    0.000000] early_vc_cma_mem(0/0x1c00000@0x1d000000)
[    0.000000]  -> initial 0, size 1c00000, base 1d000000
[    1.932076] vchiq_get_state: g_state.remote->initialised != 1 (0)
[    1.932860] vchiq_get_state: g_state.remote->initialised != 1 (0)

Retry loop works fine BTW.

[maxnet]

Fixed in last commit.
Thanks.

[tobire42]

looks like the "unable to open rtc device" line is back now? (with "quiet" in cmdline.txt)

[popcornmix]

@tobire42
Looks like it comes from this config option: CONFIG_RTC_HCTOSYS.
Unfortunately it's a bool setting (so can't make it a module) and if we disable then people with RTC hardware won't be able to use it.

Not sure if there's a way to disable it.

[maxnet]

Looks like it comes from this config option: CONFIG_RTC_HCTOSYS.
Unfortunately it's a bool setting (so can't make it a module) and if we disable then people with RTC hardware won't
be able to use it.

Same option as before.
What use does it have to people with RTC hardware?

"The driver for this RTC device must be loaded before late_initcall functions run, so it must usually be statically linked."

All the RTC hardware support is build as module, and not built-into the kernel, right?

[popcornmix]

@maxnet
So suggestion is to disable CONFIG_RTC_HCTOSYS?
I have no evidence that it is required by anyone, so I could try that.

[maxnet]

So suggestion is to disable CONFIG_RTC_HCTOSYS?

Yes.
You did the same for the rpi-3.6 branch back when this bug was first reported.

Assuming nobody complained about that, it should be safe to do the same in the new branch.

[rotx]

FYI, disabling this option breaks RTC clock sync on boot, see http://www.raspberrypi.org/forums/viewtopic.php?p=692662#p692662

[maxnet]

FYI, disabling this option breaks RTC clock sync on boot

Have you actually build a kernel with this option enabled and tested that it solved the problem for you?

Enabling this option ALONE should not do anything.
Yes, it will try to set time on boot, but it will only do so using the zero RTC drivers we currently have build statically into the kernel, as external kernel modules are not loaded yet at boot time, but later with help from user-space by udev/systemd.

Enabling the option would only make sense, if you also build all RTC drivers into the kernel. Which may be an option if they all have device tree support, and stay quiet if they are not in the tree.