Re: [PATCHv2] OMAP: Enable Magic SysRq on serial console ttyOx

From: Govindraj
Date: Sat Jan 22 2011 - 12:22:00 EST


On Sat, Jan 22, 2011 at 6:33 AM, Kevin Hilman <khilman@xxxxxx> wrote:
> "G, Manjunath Kondaiah" <manjugk@xxxxxx> writes:
>
>> On Fri, Jan 21, 2011 at 12:54:29PM +0530, Govindraj wrote:
>>> On Thu, Jan 20, 2011 at 5:49 PM, Anand Gadiyar <gadiyar@xxxxxx> wrote:
>>> >> > >>>> Magic SysRq key is not working for OMAP on new serial
>>> >> > >>>> console ttyOx because SUPPORT_SYSRQ is not defined
>>> >> > >>>> for omap-serial.
>>> >> > >>>>
>>> >> > >>>> This patch defines SUPPORT_SYSRQ in omap-serial and
>>> >> > >>>> enables handling of Magic SysRq character.
>>> >> > >>>>
>>> >> > >>>> Signed-off-by: Thomas Weber <weber@xxxxxxxxxxxxx>
>>> >> > >>>
>>> >> > >>> Looks fine to me.
>>> >> > >>>
>>> >> > >>> Acked-by: Govindraj.R <govindraj.raja@xxxxxx>
>>> >> > >> I tried to use SysRq key on minicom after applying this patch, it
>>> > looks
>>> >> > >> like it is not triggering sysrq event.
>>> >> > >>
>>> >> > >> Am I missing anything?
>>> >> > >>
>>> >> > >> -Manjunath
>>> >> > >> --
>>> >> > > Hello Manjunath,
>>> >> > >
>>> >> > > Do you have CONFIG_MAGIC_SYSRQ enabled?
>>> >> > > Magic SysRq key in Kernel Hacking
>>> >> > >
>>> >> > > I tested it on Devkit8000 (beagle board clone).
>>> >> > >
>>> >> >
>>> >> > re-setting lsr_break_flag to 0 in receive chars is causing issues
>>> >> > in getting sysrq key break sequence on omap-serial.c
>>> >> >
>>> >> > Manju,
>>> >> >
>>> >> > can you try this change on your environment.
>>> >> > With below change works for me on 3430SDP/4430SDP.
>>> >> > key sequence I checked.
>>> >> > [alt + b + t]  => shows trace of tasks running.
>>> >> > [alt + b + b] => system reboot.
>>> >>
>>> >> With below patch, it works fine on TeraTerm. However, I am not able to
>>> >> perform the same on minicom.
>>> >>
>>> >> Tested-by: Manjunath G Kondaiah <manjugk@xxxxxx>
>>> >>
>>> >> -Manjunath
>>> >>
>>> >
>>> > Not sure what you guys are trying out, but I am able to use sysrq
>>> > just fine in minicom (using only Thomas' original patch) - you need
>>> > to send a break sequence, and the way to do this in minicom is to
>>> > do Ctrl-A followed by F.
>>> >
>>> > Works for me, without the "resetting lsr_break_flag to 0" part.
>>> >
>>> > @Govind,
>>> >
>>> > What are the issues you see in getting sysrq key break sequence
>>> > without your change? And how is your change fixing this?
>>>
>>> Actually I was using teraterm on windows platform.
>>> using keyboard to send a break char [alt + b] sometimes
>>> i observed that first break char was getting lost and subsequent break
>>> chars where getting
>>> recognized. However using send break option from terterm menu seems to
>>> work most of times.
>>> my change can be dropped.
>> If it is fixing the issue of losing first break character, what is wrong in
>> having this patch?
>>
>> Do you see any other issues because of this change?
>
> Were you loosing the first break character because of PM?  i.e., if the
> OMAP is in retention or off while idle, we will always loose the first
> character.  The first character causes the wakeup, but does not make it
> to the UART.
>

No, even without PM i.e., even without setting sleep_while_idle and timeouts for
uart I observed on windows-teraterm sometimes first break char was getting lost.

--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/