lkml.org 
[lkml]   [2015]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v10 3/3] x86/earlyprintk: setup earlyprintk as early as possible
From
2015-06-08 15:33 GMT+06:00 Borislav Petkov <bp@suse.de>:
> On Sun, Jun 07, 2015 at 08:14:37PM +0600, Alexander Kuleshov wrote:
>> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
>> index 1e5f064..769d411 100644
>> --- a/arch/x86/kernel/head64.c
>> +++ b/arch/x86/kernel/head64.c
>> @@ -174,7 +174,12 @@ asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
>>
>> setup_builtin_cmdline();
>>
>> + lockdep_init();
>
> So you've added that lockdep_init() call here and above on the 32-bit
> path and haven't removed the one in start_kernel().
>

Hello Borislav,

Yes, I've left the lockdep_init in the start_kernel because there are a
couple architectures (arm,arm64 and etc...) who have support of the lockdep,
but have do not call lockdep_init in their architecture-specific code from the
arch/*.

> * Then, your patches don't apply. Something garbles them insanely so that
> not even fuzzy, ignore-context patch --merge works. Please fix your
> setup. For that, send your patches to yourself and try applying them.
> Send them out only if they apply cleanly.
>
> And do them against tip/master or latest Linus rc, alternatively.

Yes, sorry, will fix it.

> * To that patchset: I did the diff below ontop of yours to check whether
> that early printk actually works.
>
> And it doesn't on my test box here.
>
> The beginning of my dmesg contains:
>
> [ 0.000000] bootconsole [earlyser0] enabled
> [ 0.000000] Initializing cgroup subsys cpuset
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Initializing cgroup subsys cpuacct
> [ 0.000000] Linux version 4.1.0-rc6+ (root@gondor) (gcc version 4.9.1 (Debian 4.9.1-19) ) #2 SMP PREEMPT Mon Jun 8 11:10:00 CEST 2015
> [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.0-rc6+ root=/dev/sda7 ro earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0 root=/dev/sda7 log_buf_len=10M resume=/dev/sda5 no_console_suspend ignore_loglevel
> [ 0.000000] KERNEL supported cpus:
> [ 0.000000] Intel GenuineIntel
> [ 0.000000] AMD AuthenticAMD
> [ 0.000000] Centaur CentaurHauls
> [ 0.000000] x86/fpu: xstate_offset[2]: 0240, xstate_sizes[2]: 0100
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
> [ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 0x340 bytes, using 'standard' format.
> [ 0.000000] x86/fpu: Using 'eager' FPU context switches.
> [ 0.000000] e820: BIOS-provided physical RAM map:
> ...
>
> and I have CONFIG_EARLY_PRINTK=y. So provided I'm not missing anything,
> I'd say you'd need to do more staring.
>

I've tested this and does not see early_printk output too on the hardware, but
only with qemu when I setup serial connection... The problem here that the
early_printk function does not use the log_buf to store its messages
as it printk does.

How to be with this? Is early_printk must to store its messages in the log_buf?

Thank you.


\
 
 \ /
  Last update: 2015-06-09 12:01    [W:0.133 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site