[#4758] Exception dumping starves watchdog

Document created by Aaronwu Employee on Aug 30, 2013
Version 1Show Document
  • View in full screen mode

[#4758] Exception dumping starves watchdog

Submitted By: Jie Zhang

Open Date

2008-12-29 02:30:05    

Priority:

Medium     Assignee:

Nobody

Status:

Open     Fixed In Release:

N/A

Found In Release:

2008R1.5-RC3     Release:

Category:

N/A     Board:

N/A

Processor:

ALL     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Rejected

Uboot version or rev.:

    Toolchain version or rev.:

any

App binary format:

N/A     

Summary: Exception dumping starves watchdog

Details:

 

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

 

or

 

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

 

Then run

 

./loop.sh 30

 

 

After several seconds, the board will be restarted.

 

Follow-ups

 

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

 

-Robin

 

--- Mike Frysinger                                           2008-12-30 15:41:57

the delay for one crash is 1 second, but you said you're constantly crashing

things

 

--- Jie Zhang                                                2008-12-30 20:29:14

To Mike,

 

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

To Robin,

 

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

Jie:

 

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

Robin, Thanks!

 

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

run"

 

?

 

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

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

loop.sh    text/x-sh    86    Jie Zhang

test.c    text/x-csrc    58    Jie Zhang

Attachments

Outcomes