I can confirm this on rcn-ee jessie debian 8.0 image with kernel
3.19.0-rc4-bone2 #1 Mon Jan 12 17:10:24 UTC 2015 armv7l GNU/Linux
my syslog shows this:
Jan 19 21:12:10 osbo2 kernel: Modules linked in: binfmt_misc ctr ccm
usb_f_acm u_serial g_serial libcomposite arc4 ath9k_htc ath9k_common
ath9k_hw ath mac80211 cfg80211 omap_sham omap_aes
Jan 19 21:12:10 osbo2 kernel: CPU: 0 PID: 9958 Comm: kworker/0:5 Tainted: G
L 3.19.0-rc4-bone2 #1
Jan 19 21:12:10 osbo2 kernel: Hardware name: Generic AM33XX (Flattened
Device Tree)
Jan 19 21:12:10 osbo2 kernel: Workqueue: events od_dbs_timer
Jan 19 21:12:10 osbo2 kernel: task: dd1ff980 ti: de2da000 task.ti: de2da000
Jan 19 21:12:10 osbo2 kernel: PC is at run_timer_softirq+0x126/0x19c
Jan 19 21:12:10 osbo2 kernel: LR is at internal_add_timer+0x25/0x50
Jan 19 21:12:10 osbo2 kernel: pc : [<c00633fe>] lr : [<c0062359>] psr:
600f0133\x0asp : de2dbc78 ip : 00000000 fp : de5823a0
Jan 19 21:12:10 osbo2 kernel: r10: 00000000 r9 : 00000000 r8 : de2dbc90
Jan 19 21:12:10 osbo2 kernel: r7 : bf8cbf65 r6 : 00000002 r5 : dd52dc84
r4 : c0af8400
Jan 19 21:12:10 osbo2 kernel: r3 : 00000019 r2 : 00200200 r1 : dd52dc84
r0 : dd52dc84
Jan 19 21:12:10 osbo2 kernel: Flags: nZCv IRQs on FIQs on Mode SVC_32
ISA Thumb Segment kernel
Jan 19 21:12:10 osbo2 kernel: Control: 50c5387d Table: 9d218019 DAC:
00000015
Jan 19 21:12:10 osbo2 kernel: CPU: 0 PID: 9958 Comm: kworker/0:5 Tainted: G
L 3.19.0-rc4-bone2 #1
Jan 19 21:12:10 osbo2 kernel: Hardware name: Generic AM33XX (Flattened
Device Tree)
Jan 19 21:12:10 osbo2 kernel: Workqueue: events od_dbs_timer
Jan 19 21:12:10 osbo2 kernel: [<c0012441>] (unwind_backtrace) from [<
c00101dd>] (show_stack+0x11/0x14)
Jan 19 21:12:10 osbo2 kernel: [<c00101dd>] (show_stack) from [<c009025d>] (
watchdog_timer_fn+0x105/0x12c)
Jan 19 21:12:10 osbo2 kernel: [<c009025d>] (watchdog_timer_fn) from [<
c0064005>] (__run_hrtimer+0x45/0x11c)
Jan 19 21:12:10 osbo2 kernel: [<c0064005>] (__run_hrtimer) from [<c0064551>]
(hrtimer_interrupt+0xc1/0x20c)
Jan 19 21:12:10 osbo2 kernel: [<c0064551>] (hrtimer_interrupt) from [<
c0020103>] (omap2_gp_timer_interrupt+0x23/0x28)
Jan 19 21:12:10 osbo2 kernel: [<c0020103>] (omap2_gp_timer_interrupt) from
[<c005c7ff>] (handle_irq_event_percpu+0x67/0x12c)
Jan 19 21:12:10 osbo2 kernel: [<c005c7ff>] (handle_irq_event_percpu) from [<
c005c8e5>] (handle_irq_event+0x21/0x2c)
Jan 19 21:12:10 osbo2 kernel: [<c005c8e5>] (handle_irq_event) from [<
c005e1c1>] (handle_level_irq+0x55/0x90)
Jan 19 21:12:10 osbo2 kernel: [<c005e1c1>] (handle_level_irq) from [<
c005c1ef>] (generic_handle_irq+0x23/0x2c)
Jan 19 21:12:10 osbo2 kernel: [<c005c1ef>] (generic_handle_irq) from [<
c005c383>] (__handle_domain_irq+0x3b/0x80)
Jan 19 21:12:10 osbo2 kernel: [<c005c383>] (__handle_domain_irq) from [<
c000847d>] (omap_intc_handle_irq+0x85/0x8c)
Jan 19 21:12:10 osbo2 kernel: [<c000847d>] (omap_intc_handle_irq) from [<
c05e729b>] (__irq_svc+0x3b/0x5c)
Jan 19 21:12:10 osbo2 kernel: Exception stack(0xde2dbc30 to 0xde2dbc78)
Jan 19 21:12:10 osbo2 kernel: bc20:
dd52dc84 dd52dc84 00200200 00000019
Jan 19 21:12:10 osbo2 kernel: bc40: c0af8400 dd52dc84 00000002 bf8cbf65
de2dbc90 00000000 00000000 de5823a0
Jan 19 21:12:10 osbo2 kernel: bc60: 00000000 de2dbc78 c0062359 c00633fe
600f0133 ffffffff
Jan 19 21:12:10 osbo2 kernel: [<c05e729b>] (__irq_svc) from [<c00633fe>] (
run_timer_softirq+0x126/0x19c)
Jan 19 21:12:10 osbo2 kernel: [<c00633fe>] (run_timer_softirq) from [<
c0032a09>] (__do_softirq+0xb1/0x1c0)
Jan 19 21:12:10 osbo2 kernel: [<c0032a09>] (__do_softirq) from [<c0032ce1>]
(irq_exit+0x79/0xb0)
Jan 19 21:12:10 osbo2 kernel: [<c0032ce1>] (irq_exit) from [<c005c387>] (
__handle_domain_irq+0x3f/0x80)
Jan 19 21:12:10 osbo2 kernel: [<c005c387>] (__handle_domain_irq) from [<
c000847d>] (omap_intc_handle_irq+0x85/0x8c)
Jan 19 21:12:10 osbo2 kernel: [<c000847d>] (omap_intc_handle_irq) from [<
c05e729b>] (__irq_svc+0x3b/0x5c)
Jan 19 21:12:10 osbo2 kernel: Exception stack(0xde2dbd40 to 0xde2dbd88)
Jan 19 21:12:10 osbo2 kernel: bd40: de0360c0 00000000 ffffffff 00000000
de016880 00000000 de034980 00000000
Jan 19 21:12:10 osbo2 kernel: bd60: de016880 c0a5da5c 000f4240 11e1a300
00000000 de2dbd88 c002a721 c002a740
Jan 19 21:12:10 osbo2 kernel: bd80: 400f0033 ffffffff
Jan 19 21:12:10 osbo2 kernel: [<c05e729b>] (__irq_svc) from [<c002a740>] (
_omap3_wait_dpll_status+0x38/0xe4)
Jan 19 21:12:10 osbo2 kernel: [<c002a740>] (_omap3_wait_dpll_status) from [<
c002a91b>] (_omap3_noncore_dpll_bypass+0x3b/0x70)
Jan 19 21:12:10 osbo2 kernel: [<c002a91b>] (_omap3_noncore_dpll_bypass) from
[<c002ab23>] (omap3_noncore_dpll_set_rate+0x63/0x3b4)
Jan 19 21:12:10 osbo2 kernel: [<c002ab23>] (omap3_noncore_dpll_set_rate)
from [<c04fc295>] (clk_change_rate+0xa9/0xe4)
Jan 19 21:12:10 osbo2 kernel: [<c04fc295>] (clk_change_rate) from [<c04fc361
>] (clk_set_rate+0x91/0x98)
Jan 19 21:12:10 osbo2 kernel: [<c04fc361>] (clk_set_rate) from [<c04c4469>]
(set_target+0xf5/0x2b8)
Jan 19 21:12:10 osbo2 kernel: [<c04c4469>] (set_target) from [<c04c065b>] (
__cpufreq_driver_target+0x133/0x25c)
Jan 19 21:12:10 osbo2 kernel: [<c04c065b>] (__cpufreq_driver_target) from [<
c04c3d1f>] (dbs_check_cpu+0xaf/0xfc)
Jan 19 21:12:10 osbo2 kernel: [<c04c3d1f>] (dbs_check_cpu) from [<c04c2f53>]
(od_dbs_timer+0x53/0xb4)
Jan 19 21:12:10 osbo2 kernel: [<c04c2f53>] (od_dbs_timer) from [<c003e9a1>]
(process_one_work+0xb9/0x278)
Jan 19 21:12:10 osbo2 kernel: [<c003e9a1>] (process_one_work) from [<
c003f27b>] (worker_thread+0xdb/0x37c)
Jan 19 21:12:10 osbo2 kernel: [<c003f27b>] (worker_thread) from [<c0041ed3>]
(kthread+0x9b/0xb0)
Jan 19 21:12:10 osbo2 kernel: [<c0041ed3>] (kthread) from [<c000d739>] (
ret_from_fork+0x11/0x38)
every 28 sec !
On Saturday, December 13, 2014 at 6:54:41 PM UTC+2, david turvene wrote:
>
> On Saturday, December 13, 2014 10:47:01 AM UTC-5, Chris Morgan wrote:
>>
>>
>> Wouldn't it make sense to raise the priority of the timer or whatever
>> code was hitting the WDT? It seems like a bug if usb or other
>> interrupts could cause the watchdog to fail to be serviced given that
>> the system is still working properly.
>>
>> How is the wdt serviced by the kernel? Is it easy to raise its priority?
>>
>
> There's a lot of information about the WDT under the kernel Documentation
> directory. I think it's a software interrupt, probably difficult to raise
> it over hardware interrupts. If you don't want the WDT, disable it via
> procfs or as a boot cmdline argument.
>
> BUT, recognize if the WDT isn't serviced then something bad is going to
> happen somewhere else. My guess is the kernel will panic with an ENOMEM or
> maybe it will silently stop. Certainly no user-space application is going
> to run if the CPU is saturated processing interrupts.
>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
