[OE-core] Yocto Bug#10456 discuss

[dengke]

OK, thanks, I will send patch to revert it in Morty.

Dengke
在 02/24/2017 10:24 PM, Bruce Ashfield 写道:
> On 2017-02-24 5:33 AM, Dengke Du wrote:
>> Hi Jussi and bruce
>>
>> Yocto Bug#10456: X can not launch on qemumips64
>>
>> I find the kernel 4.4 is ok, and on the latest 4.9 is ok, but on kernel
>> 4.8 is failed.
>>
>> This is because this commit in linux-yocto-4.8:
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> commit d03516df837587368fc6e75591f6329c072b9eb5
>> Author: Matthew Leach <matthew.leach at codethink.co.uk>
>> Date:   Tue Jun 21 16:19:49 2016 +0100
>>
>>     tty: serial: 8250: add CON_CONSDEV to flags
>>
>>     When using the 8250 as a boot console and the main console 
>> results in
>>     messages being printed twice.  The console framework will only
>>     unregister boot consoles if a new console is registered with the
>>     CON_CONSDEV flag set.
>>
>>     Set this flag for the univ8250 console to prevent 
>> double-registration.
>>
>>     Signed-off-by: Matthew Leach <matthew.leach at codethink.co.uk>
>>     Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
>>
>> diff --git a/drivers/tty/serial/8250/8250_core.c
>> b/drivers/tty/serial/8250/8250_core.c
>> index fa823a5..dcf43f6 100644
>> --- a/drivers/tty/serial/8250/8250_core.c
>> +++ b/drivers/tty/serial/8250/8250_core.c
>> @@ -675,7 +675,7 @@ static struct console univ8250_console = {
>>         .device         = uart_console_device,
>>         .setup          = univ8250_console_setup,
>>         .match          = univ8250_console_match,
>> -       .flags          = CON_PRINTBUFFER | CON_ANYTIME,
>> +       .flags          = CON_PRINTBUFFER | CON_ANYTIME | CON_CONSDEV,
>>         .index          = -1,
>>         .data           = &serial8250_reg,
>>  };
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> The 4.9 has been reverted it, so backport that reverted patch can fix
>> this bug, but I don't know why this related to qemumips64?
>
> Looks like the console is interfering with X claiming a VT for
> startup.
>
> But I wouldn't worry about the root cause all that much, if you've
> bisected it, and it has been reverted already in newer kernels .. that
> should be enough evidence for anyone.
>
> Bruce
>
>>
>> Thanks
>>
>> Dengke
>>
>
>