Well, the thing is, I'm the developer of the original driver :) You're right, the hw wdt timeout is too short to be of any practical use in this scenario. So it has to be "extended" with a software timer. However, your assumptions about the way it works are wrong. It will actually re-arm the hw wdt on every tick of the software timer (it is, therefore, essential that the software timer period is shorter than the hw wdt timeout). So, if your userspace suddenly dies and stops kicking the watchdog, the software timer will eventually count down to zero, stop re-arming the hw wdt and trigger a reset. If your kernel goes as well, your software timer will be gone with it, no hw wdt reset will be performed any longer, so it will expire and reset the board almost instantly.
Regards, Aleksandar On 09/25/2010 07:06 PM, Alexey Loukianov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 25.09.2010 21:38, Aleksandar Radovanovic wrote: > >> Re the patch, I agree - applying that patch will effectively turn the >> driver into a softdog. >> > To be honest: bcrm47xx_wdt driver isn't a hardware watchdog either. I had > spent > some time inspecting the module source and googling around and it seems that > the > fire time for the ssb hardware watchdog being set in "tick" (cycles qty) units > maxing at 0xFFFFFFF. This means that fire time would be ~2.5 seconds on 100MHz > systems, and ~2 seconds on 133MHz systems. I don't know the implementation > details for broadcom boards so I can't tell for sure if any plls are used to > make CPU run at 240Mhz. If the watchdog timer will be clocked at CPU freq then > it would lower fire time to ~1 second. > > Looks like that such a low fire time is inappropriate for the non-realtime > kernel and the developer of the driver "extended" hardware watchdog timer > with a > software one. Thus the current driver acts like this: wait till software timer > fires -> warn user that the watchdog will fire soon -> arm hardware watchdog > to > fire after 0xFFFFFFF cycles -> do nothing waiting till hardware timer fires > and > reboots the device. > > It is obvious that in case some huge kernel disaster happen this watchdog > wouldn't be able to reboot the device making driver almost the same as > softdog. > For now I had modified my working copy of openwrt sources to exclude > bcrm47xx_wdt driver from build (it makes possible to use softdog instead). > > Still it would be great to figure out why does the bcrm47xx_wdt driver work > with > your Asus WL-500gP v1 and don't work with my D-Link DIR-320. > > - -- > Best regards, > Alexey Loukianov mailto:[email protected] > System Engineer, Mob.:+7(926)218-1320 > *nix Specialist > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJMnjo9AAoJEPB9BOdTkBUL+jMH/RXszDXm09l/kJTyT9xdNhu5 > 67lwSnVMYabLRM0fVjGSItk0nGj5eqUWZyb7vVtROHSZc0CPGle0Ys7r8ATYI07M > +IIELDuqhFeyJnvcS9uL0TO2mUJAPsSxcctPxj3ovXfrgnJKhmgsagPADFI3yx3R > GgqFE/9hqy5fZHW9Q8eMx4Vs4ac/vbZhVrGUDGlba6vv6ve7qsqOWfnYGak8nojt > gdPEGI4cySNSRGEcyTmmUwqwGR0c9tcIbe0fZ/QxdRflImxkxiZDQkQD8iQRXfUE > jxzYPMD8ZDmxvWqNnV/INcZZWoN5gC+5jE1T9c2DbptO9iFjTSfOk7xDEZ0xEag= > =slKu > -----END PGP SIGNATURE----- > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
