Description of problem:
When a panic is detencted by the lab controller it sets the current watchdog to ten minutes from the current time to give the system a chance to kdump if configured.

The problem is if kdump default configuration is to reboot the system.  This means its possible that the system under test could push the watchdog out again and attempt to run the test and possibly panic again.

Version-Release number of selected component (if applicable):
20.2

How reproducible:
Sun, moon and stars need to align

Actual results:
We had a bad kernel go through beaker which ended up filling the netdump server disk and kept the systems busy until someone manually canceled the job.

Several things had to go wrong.
1. bad kernel that caused a panic
2. bug in kdump that kept the system from halting
3. fsck? rolled changes back in filesystem which made the harness think it was running for the first time (rebootcount==0)

Expected results:
Once initial 10 minute watchdog timeout is set because of a panic it should not be changeable.

Additional info:
There is some other code in the abort code which looks like it can modify the watchdog time as well if WATCHDOG_SCRIPT is defined. So this could be tricky.