Hello Paul, On Thu, Dec 2, 2010 at 8:23 AM, Paul Walmsley <paul@xxxxxxxxx> wrote: > Hello Jean > > On Thu, 25 Nov 2010, Jean Pihet wrote: > >> On Thu, Nov 25, 2010 at 6:35 PM, Paul Walmsley <paul@xxxxxxxxx> wrote: >> > On Thu, 25 Nov 2010, Jean Pihet wrote: >> >> On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley <paul@xxxxxxxxx> wrote: >> >> > >> >> > The console semaphore must be held while the OMAP UART devices are >> >> > disabled, lest a console write cause an ARM abort (and a kernel crash) >> >> > when the underlying console device is inaccessible. These crashes >> >> > only occur when the console is on one of the OMAP internal serial >> >> > ports. >> >> This does not fix the issue for me on Beagle (console on ttyO2). >> >> >> >> Doing: >> >> / # echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout >> >> / # echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout >> >> / # echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout >> >> and waiting 5 seconds hangs the console. >> > >> > By the way, you write that the above situation "hangs the console." Is it >> > just the case that the console dies and the rest of the system is still >> > alive, or does the whole system crash? >> The console hangs, the rest of the system still runs. > > Just out of curiosity, if you send a few breaks to the OMAP over serial, > does that cause the console to pay attention again? CTRL-A F in minicom. Yes it helps. In most cases sending 2-3 breaks resumes the UART console. > > - Paul Jean -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
