Date: Fri, 27 Sep 2024 09:04:30 -0400 From: mike tancsa <mike@sentex.net> To: Chris6 via freebsd-hardware <freebsd-hardware@freebsd.org> Subject: Re: watchdog timer programming Message-ID: <c4343727-606c-409a-8618-9da732fc3059@sentex.net> In-Reply-To: <86h6a1egcs.fsf@cthulhu.stephaner.labo.int> References: <3065debc-8d4f-4487-abbb-c9408810cea6@sentex.net> <86plotbk5b.fsf@cthulhu.stephaner.labo.int> <9008b389-ab06-401d-9a95-84f849ca602a@sentex.net> <86plosdv48.fsf@cthulhu.stephaner.labo.int> <78e9461c-b93d-403f-b3a1-3568548b9283@sentex.net> <86h6a1egcs.fsf@cthulhu.stephaner.labo.int>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/27/2024 2:09 AM, Stephane Rochoy wrote:
>
> mike tancsa <mike@sentex.net> writes:
>
>> On 9/25/2024 3:13 AM, Stephane Rochoy wrote:
>>>>>>
>>>>>> Any idea how to get this hardware working ?
>>>>>
>>>>> Do you know if, at least, the pre-timeout is working?
>>>>
>>>> How do I check that ?
>>>
>>> Using --pretimeout and --pretimeout-action. See watchdogd(8) for
>>> more details.
>>>
>> Reverting to the code thats in the tree, I started it up with
>>
>> watchdogd --pretimeout 10 --pretimeout-action log -t 15
>>
>> Doesnt seem to work or at least it doesnt make sense to me. After I
>> start that up, I see in the logs about 25 seconds after it starts, but
>> not always.
>>
>> Sep 26 11:31:20 mpki2024 kernel: watchdog pre-timeout, WD_SOFT_LOG
>> Sep 26 11:31:20 mpki2024 kernel: Sep 26 11:31:20 pki2024 kernel:
>> watchdog pre-timeout, WD_SOFT_LOG
>>
>> and then doing a kill -9 does nothing :(
>
> AFAIK, the pre-timeout should trigger reliably. Weird.
I also started to play around with the non hardware based watchdog
timer. For some reason, I cant get the box to reboot. It just prints a
stack trace and continues
This is with no driver loaded.
0{t}# watchdogd --softtimeout-action panic -t 5
0{t}# ps -auxww | grep dog
root 1487 0.4 0.2 12820 12920 - S<s 09:03 0:00.01 watchdogd
--softtimeout-action panic -t 5
root 1489 0.0 0.0 12808 2636 u0 S+ 09:03 0:00.00
grep dog
0{t}# kill -9 1487
0{t}# KDB: stack backtrace:
#0 0xffffffff80b7fefd at kdb_backtrace+0x5d
#1 0xffffffff80abec93 at hardclock+0x103
#2 0xffffffff80abfe8b at handleevents+0xab
#3 0xffffffff80ac0b7c at timercb+0x24c
#4 0xffffffff810d0ebb at lapic_handle_timer+0xab
#5 0xffffffff80fd8a71 at Xtimerint+0xb1
#6 0xffffffff804b3685 at acpi_cpu_idle+0x2c5
#7 0xffffffff80fc48f6 at cpu_idle_acpi+0x46
#8 0xffffffff80fc49ad at cpu_idle+0x9d
#9 0xffffffff80b67bb6 at sched_idletd+0x576
#10 0xffffffff80aecf7f at fork_exit+0x7f
#11 0xffffffff80fd7dae at fork_trampoline+0xe
0{t}#
Should it not reboot at this point ?
---Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c4343727-606c-409a-8618-9da732fc3059>