Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Rongqing Li <rongqing.li@windriver.com>
To: "Burton, Ross" <ross.burton@intel.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] systemd-serialgetty: fix a typo
Date: Tue, 16 Feb 2016 14:04:22 +0800	[thread overview]
Message-ID: <56C2BBE6.20209@windriver.com> (raw)
In-Reply-To: <56C282AA.9010707@windriver.com>



On 2016年02月16日 10:00, Rongqing Li wrote:
>
>
> On 2016年02月15日 18:30, Burton, Ross wrote:
>>
>> On 15 February 2016 at 07:47, <rongqing.li@windriver.com
>> <mailto:rongqing.li@windriver.com>> wrote:
>>
>>     -SERIAL_CONSOLE ?= "115200 ttyS0"
>>     +SERIAL_CONSOLES ?= "115200 ttyS0"
>>
>>
>> bitbake.conf says:
>>
>> SERIAL_CONSOLES ??= "${@d.getVar('SERIAL_CONSOLE', True).replace(' ',
>> ';')}"
>>
>> And the relevant commit introducing _CONSOLES says:
>>
>>      Just define additional serial consoles like so:
>>      SERIAL_CONSOLES="115200;ttyS0 115200;ttyS1 ... 115200;ttySN"
>>
>> So moving from CONSOLE to CONSOLES is more than just adding an S.
>
> sorry, I am wrong
>
>>
>> Anyway, surely the machine should be setting this if required?  Why does
>> systemd-serialgetty think that ttyS0 should be a serial console if the
>> machine doesn't say so?
>>
>
> This is a issue, like qemux86, ttyS0 and ttyS1 will be used as console,
> but ttyS1 is not a true device when execute "runqemu qemux86", and lead
> to the blow error.

this is not issue, since it is fixed by

commit 6f2047a0e278d29876451b5af8b8de156db33ed0
Author: Randy Witt <randy.e.witt@linux.intel.com>
Date:   Mon Sep 28 15:38:23 2015 -0700

     runqemu-internal: Make sure two serial ports always exist

     Since inittab for qemu images now always tries to start getty on a
     second serial device, make sure that device exists.

     Otherwise the following message will be spammed:
         INIT: Id "S1" respawning too fast: disabled for 5 minutes

     [YOCTO #8374]

     (From OE-Core rev: 988369afed85281f3ed9b2f3eeb30f5408498bb9)

     Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
     Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>


-Roy

>
>
> root@qemu0:~# systemctl status serial-getty@ttyS1
> ● serial-getty@ttyS1.service - Serial Getty on ttyS1
>     Loaded: loaded (/lib/systemd/system/serial-getty@.service; enabled;
> vendor preset: enabled)
>     Active: active (running) since Sat 2016-02-06 03:33:26 UTC; 1s ago
>       Docs: man:agetty(8)
>             man:systemd-getty-generator(8)
>             http://0pointer.de/blog/projects/serial-console.html
>   Main PID: 902 (agetty)
>     CGroup:
> /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyS1.service
>             └─902 /sbin/agetty -8 -L --keep-baud ttyS1 115200 xterm
>
> Feb 06 03:33:26 qemu0 systemd[1]: Started Serial Getty on ttyS1.
> Feb 06 03:33:26 qemu0 agetty[902]: /dev/ttyS1: not a tty
>
>
>
>
> the below commit sets ttyS1 as console, but runqemu has only ttyS0 device.
>
>
> commit 2da3fee6b6d9f4dd4c4cb529f4ba393c20aa0f13
> Author: Randy Witt <randy.e.witt@linux.intel.com>
> Date:   Thu Aug 20 13:01:25 2015 -0700
>
>      qemurunner: Use two serial ports and log console with a thread
>
>      qemu can freeze and stop responding if the socket buffer connected
> to a tcp
>      serial connection fills up. This happens of course when the reader of
>      the serial data doesn't actually read it.
>
>      This happened in the qemurunner code, because after checking for the
>      "login:" sentinel, data was never again read from the serial
> connection.
>
>      This patch solves the potential freeze by adding a thread to
> continuously
>      read the data from the console and log it. So it also will give a
> full log
>      of the console, rather than just up to the login prompt.
>
>      To simplify this patch, another serial port was also added to use
> for the
>      sole purpose of watching for the sentinel as well as being the
> interactive
>      serial port. This will also prevent the possibility of lots of debug
>      data on the console preventing the sentinel value from being seen
> due to
>      interleaved text.
>
>      Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
>      Signed-off-by: Ross Burton <ross.burton@intel.com>
>
>
>
>
>
>
> -Roy
>
>
>
>
>> Ross

-- 
Best Reagrds,
Roy | RongQing Li


      reply	other threads:[~2016-02-16  6:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-15  7:47 [PATCH] systemd-serialgetty: fix a typo rongqing.li
2016-02-15 10:30 ` Burton, Ross
2016-02-16  2:00   ` Rongqing Li
2016-02-16  6:04     ` Rongqing Li [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56C2BBE6.20209@windriver.com \
    --to=rongqing.li@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=ross.burton@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox