serial port input corruption with 2.6.32?

serial port input corruption with 2.6.32?

[Steve Sakoman]

I'm seeing some strange behavior with my console serial port with 2.6.32.

Output seems fine -- no errors in the boot messages.

However it seems that quite often the first character typed in a
console session is garbled -- subsequent characters are OK:

root@omap3:~# �s -l
-sh: �s: not found

If commands are typed in rapid succession this issue doesn't show up,
but if several seconds pass since the last keystroke the first
character is garbled once again.

Anyone else seeing this?  A search of this list didn't turn anything
up, but perhaps my google mojo is just bad today.

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: serial port input corruption with 2.6.32?

[Robert Nelson]

On Wed, Dec 23, 2009 at 2:59 PM, Steve Sakoman <sakoman@gmail.com> wrote:
> I'm seeing some strange behavior with my console serial port with 2.6.32.
>
> Output seems fine -- no errors in the boot messages.
>
> However it seems that quite often the first character typed in a
> console session is garbled -- subsequent characters are OK:
>
> root@omap3:~# �s -l
> -sh: �s: not found
>
> If commands are typed in rapid succession this issue doesn't show up,
> but if several seconds pass since the last keystroke the first
> character is garbled once again.
>
> Anyone else seeing this?  A search of this list didn't turn anything
> up, but perhaps my google mojo is just bad today.
>
> Steve

Hey Steve,

I saw something similar while testing 2.6.32, by chance are you using
any power management patches?

I had to disable CONFIG_CPU_IDLE:

-CONFIG_CPU_IDLE=y
-CONFIG_CPU_IDLE_GOV_LADDER=y
-CONFIG_CPU_IDLE_GOV_MENU=y
+# CONFIG_CPU_IDLE is not set

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: serial port input corruption with 2.6.32?

[Steve Sakoman]

On Wed, Dec 23, 2009 at 1:06 PM, Robert Nelson <robertcnelson@gmail.com> wrote:
> On Wed, Dec 23, 2009 at 2:59 PM, Steve Sakoman <sakoman@gmail.com> wrote:
>> I'm seeing some strange behavior with my console serial port with 2.6.32.
>>
>> Output seems fine -- no errors in the boot messages.
>>
>> However it seems that quite often the first character typed in a
>> console session is garbled -- subsequent characters are OK:
>>
>> root@omap3:~# �s -l
>> -sh: �s: not found
>>
>> If commands are typed in rapid succession this issue doesn't show up,
>> but if several seconds pass since the last keystroke the first
>> character is garbled once again.
>>
>> Anyone else seeing this?  A search of this list didn't turn anything
>> up, but perhaps my google mojo is just bad today.
>>
>> Steve
>
> Hey Steve,
>
> I saw something similar while testing 2.6.32, by chance are you using
> any power management patches?
>
> I had to disable CONFIG_CPU_IDLE:
>
> -CONFIG_CPU_IDLE=y
> -CONFIG_CPU_IDLE_GOV_LADDER=y
> -CONFIG_CPU_IDLE_GOV_MENU=y
> +# CONFIG_CPU_IDLE is not set

Now power management patches, but CPU_IDLE is indeed enabled.   I'll
give it a try with CPU_IDLE disabled.

Does this just work around a bug that ought to be fixed, or is
enabling CPU_IDLE just a bad idea?

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: serial port input corruption with 2.6.32?

[Kevin Hilman]

Steve Sakoman <sakoman@gmail.com> writes:

> On Wed, Dec 23, 2009 at 1:06 PM, Robert Nelson <robertcnelson@gmail.com> wrote:
>> On Wed, Dec 23, 2009 at 2:59 PM, Steve Sakoman <sakoman@gmail.com> wrote:
>>> I'm seeing some strange behavior with my console serial port with 2.6.32.
>>>
>>> Output seems fine -- no errors in the boot messages.
>>>
>>> However it seems that quite often the first character typed in a
>>> console session is garbled -- subsequent characters are OK:
>>>
>>> root@omap3:~# �s -l
>>> -sh: �s: not found
>>>
>>> If commands are typed in rapid succession this issue doesn't show up,
>>> but if several seconds pass since the last keystroke the first
>>> character is garbled once again.
>>>
>>> Anyone else seeing this?  A search of this list didn't turn anything
>>> up, but perhaps my google mojo is just bad today.
>>>
>>> Steve
>>
>> Hey Steve,
>>
>> I saw something similar while testing 2.6.32, by chance are you using
>> any power management patches?
>>
>> I had to disable CONFIG_CPU_IDLE:
>>
>> -CONFIG_CPU_IDLE=y
>> -CONFIG_CPU_IDLE_GOV_LADDER=y
>> -CONFIG_CPU_IDLE_GOV_MENU=y
>> +# CONFIG_CPU_IDLE is not set
>
> Now power management patches, but CPU_IDLE is indeed enabled.   I'll
> give it a try with CPU_IDLE disabled.

As of 2.6.32, much of the PM patches are in mainline now, including
CPUidle.

> Does this just work around a bug that ought to be fixed, or is
> enabling CPU_IDLE just a bad idea?

CPUidle itself is just fine.

You've discovered a PM "feature."  ;)

I'm guessing you (or your userland) has enabled sleep-while-idle.
Check the value of <debugfs>/pm_debug/sleep_while_idle.  This
enables PM features during idle.

What you're seeing is a side-effect of allowing the UARTs to be idled
and un-clocked during idle.

The UARTs have a SW inactivity timer (default 5 secs) after which
their clocks will be cut during idle.  The UARTs themselves are also
configured as wakeup sources by default, so any UART input will
trigger a wakeup.  However, the first char serves as the wakeup but
the OMAP does not wakeup fast enough to actually latch the first
character, resulting in either garbage or a lost char.

The simplest way to avoid the problem (but implies increased power
consumption) is to simply disable the UART inactivity timer for your
console UART.  This way, that UART will never timeout and its clocks
will never be cut:

  # echo 0 > /sys/devices/platform/serial8250.N/sleep_timeout

(where N = [0, 1, 2], as in ttySN)

Another alternative (although not a very practical one) is to use
something else as a wakeup source (GPIO, twl4030 keypad) before typing
on the console.

Personally, after so much PM development, I've now develop the habit
of typing the first character of commands twice.  :)

Basically, there is currently no way of avoiding this problem if you
are using UARTs as the wakeup source and want power savings.  

This will also have obvious and serious PM implications for non
serial-console devices connected to UARTs (IrDA, bluetooth, modems,
etc.)

I've heard some ideas of muxing the UART into GPIO mode when idle and
having a bitbanging to get the first char so it is not lost, but
haven't seen any patches to do it.  

While it doesn't really solve your problem, I hope it at least helps
understand the reason for it.

Kevin


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: serial port input corruption with 2.6.32?

[Pandita, Vikram]

>-----Original Message-----
>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Kevin
>Hilman
>Sent: Wednesday, January 06, 2010 5:27 PM
>To: Steve Sakoman
>Cc: Robert Nelson; linux-omap@vger.kernel.org
>Subject: Re: serial port input corruption with 2.6.32?
>
>Steve Sakoman <sakoman@gmail.com> writes:
>
>> On Wed, Dec 23, 2009 at 1:06 PM, Robert Nelson <robertcnelson@gmail.com> wrote:
>>> On Wed, Dec 23, 2009 at 2:59 PM, Steve Sakoman <sakoman@gmail.com> wrote:
>>>> I'm seeing some strange behavior with my console serial port with 2.6.32.
>>>>
<snip>
>This will also have obvious and serious PM implications for non
>serial-console devices connected to UARTs (IrDA, bluetooth, modems,
>etc.)

OMAP uarts for BT etc use h/w flow control, which is another way of waking up omap before sending any chars and hence don’t loose data.

Console uses no flow control as you know.

>
>I've heard some ideas of muxing the UART into GPIO mode when idle and
>having a bitbanging to get the first char so it is not lost, but
>haven't seen any patches to do it.
>
>While it doesn't really solve your problem, I hope it at least helps
>understand the reason for it.

You could write a book on uart pm :)

>
>Kevin
>
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: serial port input corruption with 2.6.32?

[Kevin Hilman]

"Pandita, Vikram" <vikram.pandita@ti.com> writes:

>>Steve Sakoman <sakoman@gmail.com> writes:
>>
>>> On Wed, Dec 23, 2009 at 1:06 PM, Robert Nelson <robertcnelson@gmail.com> wrote:
>>>> On Wed, Dec 23, 2009 at 2:59 PM, Steve Sakoman <sakoman@gmail.com> wrote:
>>>>> I'm seeing some strange behavior with my console serial port with 2.6.32.
>>>>>
> <snip>
>>This will also have obvious and serious PM implications for non
>>serial-console devices connected to UARTs (IrDA, bluetooth, modems,
>>etc.)
>
> OMAP uarts for BT etc use h/w flow control, which is another way of
> waking up omap before sending any chars and hence don’t loose data.

Good point.  However, I haven't personally tested (or heard) that it
actually works as would be expected.  Can you confirm working BT over
a UART with idle/unclocking enabled?

Kevin


> Console uses no flow control as you know.
>
>>
>>I've heard some ideas of muxing the UART into GPIO mode when idle and
>>having a bitbanging to get the first char so it is not lost, but
>>haven't seen any patches to do it.
>>
>>While it doesn't really solve your problem, I hope it at least helps
>>understand the reason for it.
>
> You could write a book on uart pm :)
>
>>
>>Kevin
>>
>>
>>--
>>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html