New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quiet mode is not so quiet #163

Closed
maxnet opened this Issue Nov 25, 2012 · 17 comments

Comments

Projects
None yet
6 participants
@maxnet
Contributor

maxnet commented Nov 25, 2012

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",

rodero95 pushed a commit to rodero95/rpi-kernel that referenced this issue Dec 8, 2012

b43legacy: Fix crash on unload when firmware not available
commit 2d838bb upstream.

When b43legacy is loaded without the firmware being available, a following
unload generates a kernel NULL pointer dereference BUG as follows:

[  214.330789] BUG: unable to handle kernel NULL pointer dereference at 0000004c
[  214.330997] IP: [<c104c395>] drain_workqueue+0x15/0x170
[  214.331179] *pde = 00000000
[  214.331311] Oops: 0000 [#1] SMP
[  214.331471] Modules linked in: b43legacy(-) ssb pcmcia mac80211 cfg80211 af_packet mperf arc4 ppdev sr_mod cdrom sg shpchp yenta_socket pcmcia_rsrc pci_hotplug pcmcia_core battery parport_pc parport floppy container ac button edd autofs4 ohci_hcd ehci_hcd usbcore usb_common thermal processor scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh fan thermal_sys hwmon ata_generic pata_ali libata [last unloaded: cfg80211]
[  214.333421] Pid: 3639, comm: modprobe Not tainted 3.6.0-rc6-wl+ #163 Source Technology VIC 9921/ALI Based Notebook
[  214.333580] EIP: 0060:[<c104c395>] EFLAGS: 00010246 CPU: 0
[  214.333687] EIP is at drain_workqueue+0x15/0x170
[  214.333788] EAX: c162ac40 EBX: cdfb8360 ECX: 0000002a EDX: 00002a2a
[  214.333890] ESI: 00000000 EDI: 00000000 EBP: cd767e7c ESP: cd767e5c
[  214.333957]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  214.333957] CR0: 8005003b CR2: 0000004c CR3: 0c96a000 CR4: 00000090
[  214.333957] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[  214.333957] DR6: ffff0ff0 DR7: 00000400
[  214.333957] Process modprobe (pid: 3639, ti=cd766000 task=cf802e90 task.ti=cd766000)
[  214.333957] Stack:
[  214.333957]  00000292 cd767e74 c12c5e09 00000296 00000296 cdfb8360 cdfb9220 00000000
[  214.333957]  cd767e90 c104c4fd cdfb8360 cdfb9220 cd682800 cd767ea4 d0c10184 cd682800
[  214.333957]  cd767ea4 cba31064 cd767eb8 d0867908 cba31064 d087e09c cd96f034 cd767ec4
[  214.333957] Call Trace:
[  214.333957]  [<c12c5e09>] ? skb_dequeue+0x49/0x60
[  214.333957]  [<c104c4fd>] destroy_workqueue+0xd/0x150
[  214.333957]  [<d0c10184>] ieee80211_unregister_hw+0xc4/0x100 [mac80211]
[  214.333957]  [<d0867908>] b43legacy_remove+0x78/0x80 [b43legacy]
[  214.333957]  [<d083654d>] ssb_device_remove+0x1d/0x30 [ssb]
[  214.333957]  [<c126f15a>] __device_release_driver+0x5a/0xb0
[  214.333957]  [<c126fb07>] driver_detach+0x87/0x90
[  214.333957]  [<c126ef4c>] bus_remove_driver+0x6c/0xe0
[  214.333957]  [<c1270120>] driver_unregister+0x40/0x70
[  214.333957]  [<d083686b>] ssb_driver_unregister+0xb/0x10 [ssb]
[  214.333957]  [<d087c488>] b43legacy_exit+0xd/0xf [b43legacy]
[  214.333957]  [<c1089dde>] sys_delete_module+0x14e/0x2b0
[  214.333957]  [<c110a4a7>] ? vfs_write+0xf7/0x150
[  214.333957]  [<c1240050>] ? tty_write_lock+0x50/0x50
[  214.333957]  [<c110a6f8>] ? sys_write+0x38/0x70
[  214.333957]  [<c1397c55>] syscall_call+0x7/0xb
[  214.333957] Code: bc 27 00 00 00 00 a1 74 61 56 c1 55 89 e5 e8 a3 fc ff ff 5d c3 90 55 89 e5 57 56 89 c6 53 b8 40 ac 62 c1 83 ec 14 e8 bb b7 34 00 <8b> 46 4c 8d 50 01 85 c0 89 56 4c 75 03 83 0e 40 80 05 40 ac 62
[  214.333957] EIP: [<c104c395>] drain_workqueue+0x15/0x170 SS:ESP 0068:cd767e5c
[  214.333957] CR2: 000000000000004c
[  214.341110] ---[ end trace c7e90ec026d875a6 ]---Index: wireless-testing/drivers/net/wireless/b43legacy/main.c

The problem is fixed by making certain that the ucode pointer is not NULL
before deregistering the driver in mac80211.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@rebroad

This comment has been minimized.

Show comment
Hide comment
@rebroad

rebroad Dec 24, 2012

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

rebroad commented Dec 24, 2012

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

@Ferroin

This comment has been minimized.

Show comment
Hide comment
@Ferroin

Ferroin Dec 25, 2012

Contributor

@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.

Contributor

Ferroin commented Dec 25, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@maxnet

maxnet Dec 25, 2012

Contributor

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.

Contributor

maxnet commented Dec 25, 2012

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.

Olipro pushed a commit to Olipro/linux-RPi that referenced this issue Dec 26, 2012

b43legacy: Fix crash on unload when firmware not available
When b43legacy is loaded without the firmware being available, a following
unload generates a kernel NULL pointer dereference BUG as follows:

[  214.330789] BUG: unable to handle kernel NULL pointer dereference at 0000004c
[  214.330997] IP: [<c104c395>] drain_workqueue+0x15/0x170
[  214.331179] *pde = 00000000
[  214.331311] Oops: 0000 [#1] SMP
[  214.331471] Modules linked in: b43legacy(-) ssb pcmcia mac80211 cfg80211 af_packet mperf arc4 ppdev sr_mod cdrom sg shpchp yenta_socket pcmcia_rsrc pci_hotplug pcmcia_core battery parport_pc parport floppy container ac button edd autofs4 ohci_hcd ehci_hcd usbcore usb_common thermal processor scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh fan thermal_sys hwmon ata_generic pata_ali libata [last unloaded: cfg80211]
[  214.333421] Pid: 3639, comm: modprobe Not tainted 3.6.0-rc6-wl+ #163 Source Technology VIC 9921/ALI Based Notebook
[  214.333580] EIP: 0060:[<c104c395>] EFLAGS: 00010246 CPU: 0
[  214.333687] EIP is at drain_workqueue+0x15/0x170
[  214.333788] EAX: c162ac40 EBX: cdfb8360 ECX: 0000002a EDX: 00002a2a
[  214.333890] ESI: 00000000 EDI: 00000000 EBP: cd767e7c ESP: cd767e5c
[  214.333957]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  214.333957] CR0: 8005003b CR2: 0000004c CR3: 0c96a000 CR4: 00000090
[  214.333957] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[  214.333957] DR6: ffff0ff0 DR7: 00000400
[  214.333957] Process modprobe (pid: 3639, ti=cd766000 task=cf802e90 task.ti=cd766000)
[  214.333957] Stack:
[  214.333957]  00000292 cd767e74 c12c5e09 00000296 00000296 cdfb8360 cdfb9220 00000000
[  214.333957]  cd767e90 c104c4fd cdfb8360 cdfb9220 cd682800 cd767ea4 d0c10184 cd682800
[  214.333957]  cd767ea4 cba31064 cd767eb8 d0867908 cba31064 d087e09c cd96f034 cd767ec4
[  214.333957] Call Trace:
[  214.333957]  [<c12c5e09>] ? skb_dequeue+0x49/0x60
[  214.333957]  [<c104c4fd>] destroy_workqueue+0xd/0x150
[  214.333957]  [<d0c10184>] ieee80211_unregister_hw+0xc4/0x100 [mac80211]
[  214.333957]  [<d0867908>] b43legacy_remove+0x78/0x80 [b43legacy]
[  214.333957]  [<d083654d>] ssb_device_remove+0x1d/0x30 [ssb]
[  214.333957]  [<c126f15a>] __device_release_driver+0x5a/0xb0
[  214.333957]  [<c126fb07>] driver_detach+0x87/0x90
[  214.333957]  [<c126ef4c>] bus_remove_driver+0x6c/0xe0
[  214.333957]  [<c1270120>] driver_unregister+0x40/0x70
[  214.333957]  [<d083686b>] ssb_driver_unregister+0xb/0x10 [ssb]
[  214.333957]  [<d087c488>] b43legacy_exit+0xd/0xf [b43legacy]
[  214.333957]  [<c1089dde>] sys_delete_module+0x14e/0x2b0
[  214.333957]  [<c110a4a7>] ? vfs_write+0xf7/0x150
[  214.333957]  [<c1240050>] ? tty_write_lock+0x50/0x50
[  214.333957]  [<c110a6f8>] ? sys_write+0x38/0x70
[  214.333957]  [<c1397c55>] syscall_call+0x7/0xb
[  214.333957] Code: bc 27 00 00 00 00 a1 74 61 56 c1 55 89 e5 e8 a3 fc ff ff 5d c3 90 55 89 e5 57 56 89 c6 53 b8 40 ac 62 c1 83 ec 14 e8 bb b7 34 00 <8b> 46 4c 8d 50 01 85 c0 89 56 4c 75 03 83 0e 40 80 05 40 ac 62
[  214.333957] EIP: [<c104c395>] drain_workqueue+0x15/0x170 SS:ESP 0068:cd767e5c
[  214.333957] CR2: 000000000000004c
[  214.341110] ---[ end trace c7e90ec026d875a6 ]---Index: wireless-testing/drivers/net/wireless/b43legacy/main.c

The problem is fixed by making certain that the ucode pointer is not NULL
before deregistering the driver in mac80211.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>   [v 3.3.0+]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Dec 27, 2012

Collaborator

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?

Collaborator

popcornmix commented Dec 27, 2012

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

This comment has been minimized.

Show comment
Hide comment
@maxnet

maxnet Dec 27, 2012

Contributor

"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?

Contributor

maxnet commented Dec 27, 2012

"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

This comment has been minimized.

Show comment
Hide comment
@maxnet

maxnet Dec 27, 2012

Contributor

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.

Contributor

maxnet commented Dec 27, 2012

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

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Dec 27, 2012

Collaborator

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

Collaborator

popcornmix commented Dec 27, 2012

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

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Dec 27, 2012

Collaborator

Latest kernel should be quiet.

Collaborator

popcornmix commented Dec 27, 2012

Latest kernel should be quiet.

@maxnet

This comment has been minimized.

Show comment
Hide comment
@maxnet

maxnet Dec 27, 2012

Contributor

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.

Contributor

maxnet commented Dec 27, 2012

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

This comment has been minimized.

Show comment
Hide comment
@maxnet

maxnet Dec 28, 2012

Contributor

Fixed in last commit.
Thanks.

Contributor

maxnet commented Dec 28, 2012

Fixed in last commit.
Thanks.

@maxnet maxnet closed this Dec 28, 2012

@tobire42

This comment has been minimized.

Show comment
Hide comment
@tobire42

tobire42 Jan 10, 2014

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

tobire42 commented Jan 10, 2014

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

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Jan 10, 2014

Collaborator

@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.

Collaborator

popcornmix commented Jan 10, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@maxnet

maxnet Jan 10, 2014

Contributor

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?

Contributor

maxnet commented Jan 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Jan 10, 2014

Collaborator

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

Collaborator

popcornmix commented Jan 10, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@maxnet

maxnet Jan 10, 2014

Contributor

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.

Contributor

maxnet commented Jan 10, 2014

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.

popcornmix added a commit that referenced this issue Jan 10, 2014

popcornmix pushed a commit to raspberrypi/firmware that referenced this issue Jan 10, 2014

Dom Cobley
kernel: bump to 3.10.26
kernel: config: Remove CONFIG_RTC_HCTOSYS
See: raspberrypi/linux#163

firmware: New night node parameters
See: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=62364&start=175#p483816

firmware: vdec3: Fix for gray blocks near start of streams
See: http://forum.xbmc.org/showthread.php?tid=181677

popcornmix pushed a commit to Hexxeh/rpi-firmware that referenced this issue Jan 10, 2014

Dom Cobley
kernel: bump to 3.10.26
kernel: config: Remove CONFIG_RTC_HCTOSYS
See: raspberrypi/linux#163

firmware: New night node parameters
See: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=62364&start=175#p483816

firmware: vdec3: Fix for gray blocks near start of streams
See: http://forum.xbmc.org/showthread.php?tid=181677

popcornmix pushed a commit that referenced this issue Mar 31, 2014

at86rf230: fix lockdep splats
This patch fix a lockdep in the at86rf230 driver, otherwise we get:

[   30.206517] =================================
[   30.211078] [ INFO: inconsistent lock state ]
[   30.215647] 3.14.0-20140108-1-00994-g32e9426 #163 Not tainted
[   30.221660] ---------------------------------
[   30.226222] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[   30.232514] systemd-udevd/157 [HC1[1]:SC0[0]:HE0:SE1] takes:
[   30.238439]  (&(&lp->lock)->rlock){?.+...}, at: [<c03600f8>] at86rf230_isr+0x18/0x44
[   30.246621] {HARDIRQ-ON-W} state was registered at:
[   30.251728]   [<c0061ce4>] __lock_acquire+0x7a4/0x18d8
[   30.257135]   [<c0063500>] lock_acquire+0x68/0x7c
[   30.262071]   [<c0588820>] _raw_spin_lock+0x28/0x38
[   30.267203]   [<c0361240>] at86rf230_xmit+0x1c/0x144
[   30.272412]   [<c057ba6c>] mac802154_xmit_worker+0x88/0x148
[   30.278271]   [<c0047844>] process_one_work+0x274/0x404
[   30.283761]   [<c00484c0>] worker_thread+0x228/0x374
[   30.288971]   [<c004cfb8>] kthread+0xd0/0xe4
[   30.293455]   [<c000dac8>] ret_from_fork+0x14/0x2c
[   30.298493] irq event stamp: 8948
[   30.301963] hardirqs last  enabled at (8947): [<c00cb290>] __kmalloc+0xb4/0x110
[   30.309636] hardirqs last disabled at (8948): [<c00115d4>] __irq_svc+0x34/0x5c
[   30.317215] softirqs last  enabled at (8452): [<c0037324>] __do_softirq+0x1dc/0x264
[   30.325243] softirqs last disabled at (8439): [<c0037638>] irq_exit+0x80/0xf4

We use the lp->lock inside the isr of at86rf230, that's why we need the
irqsave spinlock calls.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
@rotx

This comment has been minimized.

Show comment
Hide comment
@rotx

rotx Feb 21, 2015

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

rotx commented Feb 21, 2015

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

@maxnet

This comment has been minimized.

Show comment
Hide comment
@maxnet

maxnet Feb 21, 2015

Contributor

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.

Contributor

maxnet commented Feb 21, 2015

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.

neuschaefer pushed a commit to neuschaefer/raspi-binary-firmware that referenced this issue Feb 27, 2017

Dom Cobley
kernel: bump to 3.10.26
kernel: config: Remove CONFIG_RTC_HCTOSYS
See: raspberrypi/linux#163

firmware: New night node parameters
See: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=62364&start=175#p483816

firmware: vdec3: Fix for gray blocks near start of streams
See: http://forum.xbmc.org/showthread.php?tid=181677
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment