From: Chuck K. <ck...@fi...> - 2008-05-01 00:03:27
|
Hi all, For those of you that use the sa1100_wdt.ko I have a question. Occasionally when the wdt times out it fails to reset the board. It just hangs. Has anyone else experienced this? The board does not load U-BOOT and all services appear to stop. Chuck |
From: BMcLean <bry...@ir...> - 2008-12-12 19:57:25
|
Chuck, We are experiencing the exact same thing. Has anybody figured this out? Bryce Chuck Kamas wrote: > > Hi all, > > For those of you that use the sa1100_wdt.ko I have a question. > Occasionally when the wdt times out it fails to reset the board. It just > hangs. Has anyone else experienced this? The board does not load > U-BOOT and all services appear to stop. > > Chuck > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/Watch-Dog-not-resetting-the-board-tp16994355p20982595.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Francois H. T. <fra...@ra...> - 2008-12-15 06:45:59
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <tt>I have started using it last week. I soon noticed that using large timeouts tends to break things. Have a look at the kernel module source code. There is a multiply operation in there with the 'margin' variable/parameter and OSCR or something which tends to be quite large and can then overflow the signed int range.<br> <br> I haven't really tried too hard to determine the true maximum for the compiled kernel (all those "generic" headers which magically include some other headers based on some unlocatable #define), but it looks like 500 is a conservative bet. I've been testing heavily with 300 seconds and it works well - kicking every 60 seconds. By heavily I mean letting it timeout every 5 minutes and starting it up immediately, a nice harsh reset cycle.<br> <br> But is you are using the default module timeout value, it is 60 seconds and should work fine.<br> We are on kernel 2.6.20.<br> <br> Chuck: Might I ask what "occasionally" means? The watchdog has become rather important to us and I would like to see if there is anything that can cause the same behaviour here.<br> <br> Francois<br> <br> </tt><br> BMcLean wrote: <blockquote cite="mid:209...@ta..." type="cite"> <pre wrap="">Chuck, We are experiencing the exact same thing. Has anybody figured this out? Bryce Chuck Kamas wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi all, For those of you that use the sa1100_wdt.ko I have a question. Occasionally when the wdt times out it fails to reset the board. It just hangs. Has anyone else experienced this? The board does not load U-BOOT and all services appear to stop. Chuck ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. <a class="moz-txt-link-freetext" href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a> _______________________________________________ gumstix-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:gum...@li...">gum...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/gumstix-users">https://lists.sourceforge.net/lists/listinfo/gumstix-users</a> </pre> </blockquote> <pre wrap=""><!----> </pre> </blockquote> </body> </html> |
From: Francois H. T. <fra...@ra...> - 2009-06-30 10:32:34
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <tt>The PXA255 watchdog is broken, as far as I can conclude. <br> <br> First off, on the PXA255, reboot == watchdog == sometimes hang...<br> If anyone else has seen reboots lock up or watchdog restarts fail, I would very much<br> like to hear more, even just how people are using the watchdog in different ways.<br> <br> If you are interested in more on this, read on.<br> <br> If you trace the reboot sys_call all through the kernel platform morphing calls, you end up here:<br> /*<br> * linux/include/asm-arm/arch-pxa/system.h<br> *<br> * Author: Nicolas Pitre<br> * Created: Jun 15, 2001<br> * Copyright: MontaVista Software Inc.<br> *<br> * This program is free software; you can redistribute it and/or modify<br> * it under the terms of the GNU General Public License version 2 as<br> * published by the Free Software Foundation.<br> */<br> <br> #include <asm/proc-fns.h><br> #include "hardware.h"<br> #include "pxa-regs.h"<br> <br> static inline void arch_idle(void)<br> {<br> cpu_do_idle();<br> }<br> <br> <br> static inline void arch_reset(char mode)<br> {<br> if (mode == 's') {<br> /* Jump into ROM at address 0 */<br> cpu_reset(0);<br> } else {<br> /* Initialize the watchdog and let it fire */<br> OWER = OWER_WME;<br> OSSR = OSSR_M3;<br> OSMR3 = OSCR + 368640; /* ... in 100 ms */<br> }<br> }<br> <br> The parameter to this function is never 's', no matter what you do from user space.<br> I suppose you could recompile the kernel with boot flags such as 'reboot=soft', but I<br> couldn't really find out if this would make a difference. Setting it from uboot<br> does not make a difference, this I tested. Regardless, recompiling the kernel<br> simply for this is ridiculous.<br> <br> I recently noticed that a few units simply do not really start up<br> when you let the watchdog time out. We have also noticed a reboot issue long ago,<br> where units simply never start up again. The above code explains that - watchdog<br> and reboot are the same. The PXA255 has no other means of resetting the CPU, and<br> the PXA255 datasheet specifies some events, such as assertion of N_RESET pin,<br> which never happens. I have concluded that the PXA255 watchdog does not work<br> reliably and consequently that no PXA255 can be safely rebooted without user <br> intervention. This is ridiculous and I hope someone can prove otherwise.<br> Since this chip is now severely discontinued, no references remain on either<br> Intel's or Marvell's site.<br> <br> <br> <br> There is a solution for rebooting:<br> linux/arch/arm/mm/proc-xscale.S (cpu_xscale_reset)<br> This is what would be called from the top code when mode == 's'.<br> You can do this from a module via:<br> arm_pm_restart('s');<br> which does some cleanup and then simply jumps to Address 0.<br> Note that whenever you do something like this, you must call<br> `sync` from userspace - I didn't, right after some large file transfers, <br> and had to reflash due to a corrupt file system.<br> <br> <br> Has anyone else seen reboot or watchdog lock-ups and done anything else about it?<br> <br> Francois<br> <br> <br> </tt><br> Francois H. Theron wrote: <blockquote cite="mid:494...@ra..." type="cite"> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <tt>I have started using it last week. I soon noticed that using large timeouts tends to break things. Have a look at the kernel module source code. There is a multiply operation in there with the 'margin' variable/parameter and OSCR or something which tends to be quite large and can then overflow the signed int range.<br> <br> I haven't really tried too hard to determine the true maximum for the compiled kernel (all those "generic" headers which magically include some other headers based on some unlocatable #define), but it looks like 500 is a conservative bet. I've been testing heavily with 300 seconds and it works well - kicking every 60 seconds. By heavily I mean letting it timeout every 5 minutes and starting it up immediately, a nice harsh reset cycle.<br> <br> But is you are using the default module timeout value, it is 60 seconds and should work fine.<br> We are on kernel 2.6.20.<br> <br> Chuck: Might I ask what "occasionally" means? The watchdog has become rather important to us and I would like to see if there is anything that can cause the same behaviour here.<br> <br> Francois<br> <br> </tt><br> BMcLean wrote: <blockquote cite="mid:209...@ta..." type="cite"> <pre wrap="">Chuck, We are experiencing the exact same thing. Has anybody figured this out? Bryce Chuck Kamas wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi all, For those of you that use the sa1100_wdt.ko I have a question. Occasionally when the wdt times out it fails to reset the board. It just hangs. Has anyone else experienced this? The board does not load U-BOOT and all services appear to stop. Chuck ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone">http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone</a> _______________________________________________ gumstix-users mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gum...@li...">gum...@li...</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/gumstix-users">https://lists.sourceforge.net/lists/listinfo/gumstix-users</a> </pre> </blockquote> <pre wrap=""><!----> </pre> </blockquote> <pre wrap=""> <hr size="4" width="90%"> ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at <a class="moz-txt-link-freetext" href="http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/">http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/</a></pre> <pre wrap=""> <hr size="4" width="90%"> _______________________________________________ gumstix-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:gum...@li...">gum...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/gumstix-users">https://lists.sourceforge.net/lists/listinfo/gumstix-users</a> </pre> </blockquote> </body> </html> |