|To:||Andreas Barth <email@example.com>|
|Subject:||Re: movidis x16 hard lockup using 2.6.33|
|From:||David Daney <firstname.lastname@example.org>|
|Date:||Mon, 29 Mar 2010 09:54:02 -0700|
|Cc:||Peter 'p2' De Schrijver <email@example.com>, firstname.lastname@example.org|
|References:||<20100326184132.GU2437@apfelkorn> <4BAD03A5.email@example.com> <20100327230744.GG27216@mails.so.argh.org>|
|User-agent:||Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3|
On 03/27/2010 04:07 PM, Andreas Barth wrote:
* David Daney (firstname.lastname@example.org) [100326 19:57]:Also you could try running with the attached patch. It is not the best watchdog, but it will print the register state for each core when things get stuck. Occasionally that is enough to see where the problem is.Thanks. As our logging has only limited buffer size, I'd be happy about an variant of the patch which doesn't reboot but just let the machine hang after the third occurence. Any chances for it?
You could just sit in a loop kicking the watchdog timer after you get to the NMI handler. That should prevent a reset, but still print the machine state.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH v3 2/3] Loongson-2F: Enable fixups of binutils 2.20.1, zhangfx|
|Next by Date:||Re: movidis x16 hard lockup using 2.6.33, Andreas Barth|
|Previous by Thread:||Re: movidis x16 hard lockup using 2.6.33, Andreas Barth|
|Next by Thread:||Re: movidis x16 hard lockup using 2.6.33, Andreas Barth|
|Indexes:||[Date] [Thread] [Top] [All Lists]|