[#4758] Exception dumping starves watchdog
Submitted By: Jie Zhang
Open Fixed In Release:
Found In Release:
ALL Silicon Revision:
Is this bug repeatable?:
Uboot version or rev.:
Toolchain version or rev.:
App binary format:
Summary: Exception dumping starves watchdog
This bug is a reduced test case for toolchain bug
[#4748] gdb testing on hardware fdpic doesn't finish now
Compile test.c with
bfin-uclinux-gcc -o test test.c -elf2flt
bfin-linux-uclibc-gcc -o test test.c
Then copy test and loop.sh to the board. The linux image is built with the default configuration of bf537-stamp (with watchdogd).
After several seconds, the board will be restarted.
--- Mike Frysinger 2008-12-29 07:02:58
this is by design ... you have no way of knowing if the dumping itself goes into
an infinite loop and thus needs to be reset by the watchdog
if you're dumping so much info that the watchdog cant be pet, then disable it
--- Jie Zhang 2008-12-29 09:37:54
But the dumping in my test case does not go into an infinite loop. It just
dumping once. It use a shell script to repeat the dumping. I think watchdogd
should have a chance to keep alive between some two calls of ./test .
--- Mike Frysinger 2008-12-29 15:24:19
it really isnt possible to discern the difference, nor do we want to add
driver-specific workarounds to our common Blackfin code
--- Jie Zhang 2008-12-29 19:46:00
Why? I think there is difference. If the application causes infinite loop of
dumping, watchdogd would have no chance to run. In my test case, one dumping
will only last about 1s. So the watchdog should have a chance to run.
--- Mike Frysinger 2008-12-29 21:03:21
our kernel isnt preemptible, and exception / serial driver have higher priority
over userspace. if you're constantly crashing the kernel (triggering exceptions
and filling the uart), i dont think it's unreasonable to delay a sleeping
application by ~10 seconds.
--- Jie Zhang 2008-12-29 21:47:02
The delay is about 1 seconds, not 10.
--- Robin Getz 2008-12-30 10:54:23
When I run into this - I normally just set the dmesg to a value that will not
print out the KERN_WARN messages - no more problems.
--- Mike Frysinger 2008-12-30 15:41:57
the delay for one crash is 1 second, but you said you're constantly crashing
--- Jie Zhang 2008-12-30 20:29:14
But there are gaps between the crashes. When it's crashing, there is no chance
for scheduling. But in the gaps, schedule is possible.
--- Jie Zhang 2008-12-30 20:31:27
Currently, I just unselect the watchdogd. I think we can add a kernel option to
turn off the crash dumping, or the option is already there?
--- Robin Getz 2008-12-30 23:11:44
It should already be there.
- at compile time - unselect "DEBUG_VERBOSE" (kernel hacking).
- at run time - just change dmesg
--- Jie Zhang 2008-12-30 23:50:39
--- Mike Frysinger 2008-12-31 03:03:56
i havent looked into exactly where the scheduling is going, so that may be
something worth looking at
--- Robin Getz 2009-06-26 08:28:44
Mike - isn't this "fixed" by your recent changes to watchdogd?
(setting the priority higher?)
"have watchdogd set its scheduling to SCHED_RR so it is more aggressively
--- Mike Frysinger 2009-06-26 10:30:07
it seems to last longer, but still not forever
i.e. running traps_test in an infinite loop with dmesg sent to serial console
File Name File Type File Size Posted By
loop.sh text/x-sh 86 Jie Zhang
test.c text/x-csrc 58 Jie Zhang