Re: Very imprecise watchdogd(8) timeout
on 16/09/2011 23:59 Arnaud Lacombe said the following: in which case the current notifier-based architecture is broken. You may want to have a soft-watchdog triggering after 5s, and a fallback hardware watchdog triggering after 60s. So let's start with the real problem, FreeBSD watchdog infrastructure doesn't expose an API to do what you described above. I think that it would be a rather small part to change the representation of timeouts from current form to, say, value + unit encoding. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Very imprecise watchdogd(8) timeout
Hi, On Sat, Sep 17, 2011 at 2:17 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cacqu3mvf5mwqec+s9vkk4mljenmos9q_bjwkbyefzabfjo6...@mail.gmail.com , Arnaud Lacombe writes: I do not really care actually, but the manpage is wrong, and the code needlessly complicated. As I said: Feel free to improve. How can I expect anything to get through, when I cannot even get an obvious use-after-free in the ipfw code fixed after months ? Or when I've been waiting to play with Warner's external compiler support patch for months ? Or when I can not get a build fix for 7-STABLE to get committed ? [and the list goes on...] ? Thanks, - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Very imprecise watchdogd(8) timeout
In message cacqu3mv7mld1qrsd3c0ck2hjfferhbqtvbqxhhq62r6-pn8...@mail.gmail.com , Arnaud Lacombe writes: I do not really care actually, but the manpage is wrong, and the code needlessly complicated. As I said: Feel free to improve. How can I expect anything to get through, when I cannot even get an obvious use-after-free in the ipfw code fixed after months ? Or when I've been waiting to play with Warner's external compiler support patch for months ? Or when I can not get a build fix for 7-STABLE to get committed ? [and the list goes on...] The oracle says: Try next answer. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Very imprecise watchdogd(8) timeout
.. just a note: people who in your situation keep filing PRs, fixing bugs and hounding committers with tested, correct fixes - end up getting commit bits. :-) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Very imprecise watchdogd(8) timeout
On 18 Sep 2011 20:31, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Sat, Sep 17, 2011 at 2:17 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cacqu3mvf5mwqec+s9vkk4mljenmos9q_bjwkbyefzabfjo6...@mail.gmail.com , Arnaud Lacombe writes: I do not really care actually, but the manpage is wrong, and the code needlessly complicated. As I said: Feel free to improve. How can I expect anything to get through, when I cannot even get an obvious use-after-free in the ipfw code fixed after months ? Or when I've been waiting to play with Warner's external compiler support patch for months ? Or when I can not get a build fix for 7-STABLE to get committed ? [and the list goes on...] ? Hey Arnaud, I'm sorry to hear you're having trouble getting your fixes included. If you provide some PR numbers I'll gladly try to get them in as quickly as possible. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Very imprecise watchdogd(8) timeout
In message cacqu3mvf5mwqec+s9vkk4mljenmos9q_bjwkbyefzabfjo6...@mail.gmail.com , Arnaud Lacombe writes: I do not really care actually, but the manpage is wrong, and the code needlessly complicated. As I said: Feel free to improve. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Very imprecise watchdogd(8) timeout
Hi, I just had a look to the way the timeout specified to watchdogd is passed to the kernel. watchdogd(8) says: The -t timeout specifies the desired timeout period in seconds. The default timeout is 16 seconds. So as a dumb user, I would expect `-t 30' to set the timeout to 30s. You can imagine my surprise when the watchdog ends up being set to 34s, result of the convoluted conversion from double to integer from the log base 2 of the timeout converted to nanosecond. That's more than 10% of error on this timeout to what the manual page says it would, and at the end, you can only set the watchdog to 62 different value. Folks, I'm definitively not impressed... - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Very imprecise watchdogd(8) timeout
In message cacqu3mws0hhnzchowmwwg8u9vd2pbdkaqf6pdw5zs_xo_s6...@mail.gmail.com , Arnaud Lacombe writes: I just had a look to the way the timeout specified to watchdogd is passed to the kernel. watchdogd(8) says: The API was designed for simplicity, not precision. Watchdog hardware often have weird and strange limitations on the actual values you can set. A very typical, the most typical in my experience, is some frequency, a binary prescaler, possibly with a counter. It is also not uncommon to have more than one watchdog mechanism in the same system. It would be overkill to design and implement a complex API to communicate these limitations to userland. So the API was designed around the power-of-two scale to give it a wide range, and with the semantics no shorter than, to make it easy to use, and for multiple watchdogs to be engaged to the best of their ability. If this is not precise enough for you, come up with something better. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Very imprecise watchdogd(8) timeout
Hi, On Fri, Sep 16, 2011 at 4:03 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cacqu3mws0hhnzchowmwwg8u9vd2pbdkaqf6pdw5zs_xo_s6...@mail.gmail.com , Arnaud Lacombe writes: I just had a look to the way the timeout specified to watchdogd is passed to the kernel. watchdogd(8) says: The API was designed for simplicity, not precision. Watchdog hardware often have weird and strange limitations on the actual values you can set. yes. A very typical, the most typical in my experience, is some frequency, a binary prescaler, possibly with a counter. It is also not uncommon to have more than one watchdog mechanism in the same system. in which case the current notifier-based architecture is broken. You may want to have a soft-watchdog triggering after 5s, and a fallback hardware watchdog triggering after 60s. It would be overkill to design and implement a complex API to communicate these limitations to userland. Linux is going this way, at least for a min/max seconds timeount info, did not check the rest. So the API was designed around the power-of-two scale to give it a wide range, and with the semantics no shorter than, to make it easy to use, and for multiple watchdogs to be engaged to the best of their ability. wide range ? 50% of the possibility are unusable (every value below 29) and the rest is limited by what the device support anyway. Take the geodewdt, a max timeout of 2h26, so with the actual sparse range, you will only be able to set timeout to 1s, 2s, 4s, 8s, 17s, 34s, 68s, 274s, 549s, 1099s, 2199s, 4398s. That's 20% of the original range... If this is not precise enough for you, come up with something better. I do not really care actually, but the manpage is wrong, and the code needlessly complicated. You can just rip all the double-to-int-log-of-nanosecond-timeout mambo-jumbo, and advertise in watchdogd(8) that only power of two timeout are supported, or have an option to directly specify the shift, that'll be simpler and correct. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
