On Wed, Jul 29, 2020 at 09:03:11PM +1000, Stephen Rothwell wrote:
>
> After merging the printk tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
Hi Stephen:
This loop was introduced recently by the powerpc tree with
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc
Hi Sergey,
On Tue, 28 Jul 2020 10:54:08 +0900 Sergey Senozhatsky
wrote:
>
>> Sorry about that. This will be fixed for tomorrow's build. The problems
> is that we have commit dependency between printk and locking tree. So I
> pulled the
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.gi
Hi Herbert,
On Tue, 28 Jul 2020 11:51:19 +1000 Herbert Xu
wrote:
>
> This patch depends on two patches in the tips tree. I presume
> this build test was done without the tips tree, right?
Of course it was ...
Each tree merged into linux-next should really be standalone (in case
e.g. Linus doe
On (20/07/28 11:49), Stephen Rothwell wrote:
[..]
> Caused by commit
>
> b4a461e72bcb ("printk: Make linux/printk.h self-contained")
>
> This *may* be interacting with other include file changes in linux-next.
>
> I have reverted that commit for today.
Hi Stephen,
Sorry about that. This will
On Tue, Jul 28, 2020 at 11:49:27AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the printk tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/printk.h:10,
> from include/linux/kernel.h:15,
>
On Tue 2020-06-23 17:17:38, Peter Zijlstra wrote:
> On Tue, Jun 23, 2020 at 04:28:58PM +0200, Petr Mladek wrote:
>
> > PS: And yes, it makes sense to push both patches via a single tree to
> > make sure that the lockdep.h split is done first.
>
> That's what I got you tip/locking/header for, pull
On Wed, Jun 24, 2020 at 10:19:29AM +0200, Petr Mladek wrote:
> On Wed 2020-06-24 10:20:58, Herbert Xu wrote:
> > On Tue, Jun 23, 2020 at 04:28:58PM +0200, Petr Mladek wrote:
> > >
> > > It is similar cycle:
> > >
> > > spinlock_types.h -> lockdep.h -> printk.h -> ratelimit.h ->
> > > spinlock_typ
On Wed 2020-06-24 10:20:58, Herbert Xu wrote:
> On Tue, Jun 23, 2020 at 04:28:58PM +0200, Petr Mladek wrote:
> >
> > It is similar cycle:
> >
> > spinlock_types.h -> lockdep.h -> printk.h -> ratelimit.h -> spinlock_types.h
> >
> > But this time it happens via list.h -> kernel.h ->printk.h.
> > Wh
On Tue, Jun 23, 2020 at 04:28:58PM +0200, Petr Mladek wrote:
>
> It is similar cycle:
>
> spinlock_types.h -> lockdep.h -> printk.h -> ratelimit.h -> spinlock_types.h
>
> But this time it happens via list.h -> kernel.h ->printk.h.
> Where list.h needs READ_ONCE() stuff from compiler.h.
But this
On Tue, Jun 23, 2020 at 04:28:58PM +0200, Petr Mladek wrote:
> PS: And yes, it makes sense to push both patches via a single tree to
> make sure that the lockdep.h split is done first.
That's what I got you tip/locking/header for, pull that topic branch
into your tree.
On Tue 2020-06-23 22:19:37, Herbert Xu wrote:
> On Tue, Jun 23, 2020 at 02:16:38PM +0200, Petr Mladek wrote:
> >
> > I have removed the problematic commit for now. It tried to remove
> > some cyclic dependencies from heavily used include files. It clearly
> > needs more love.
>
> Hmm, the cyclic d
On Tue, Jun 23, 2020 at 02:16:38PM +0200, Petr Mladek wrote:
>
> I have removed the problematic commit for now. It tried to remove
> some cyclic dependencies from heavily used include files. It clearly
> needs more love.
Hmm, the cyclic dependencies are there because you didn't pull in
the lockdep
On Tue 2020-06-23 10:26:55, Stephen Rothwell wrote:
> Hi Stephen,
>
> On Sun, 21 Jun 2020 13:15:54 +1000 Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > After merging the printk tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from include/l
Hi Stephen,
On Sun, 21 Jun 2020 13:15:54 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the printk tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/printk.h:10,
> from include/linux/kernel.h:15,
>
On Sun, Jun 21, 2020 at 01:15:54PM +1000, Stephen Rothwell wrote:
>
> Caused by commit
>
> 494c8512c90e ("printk: Make linux/printk.h self-contained")
>
> changing include files is hadrer than it loooks :-(
That's because this patch depends on the lockdep_types patch which
is in the x86 tree.
On Sat 2018-03-03 23:47:39, Sergey Senozhatsky wrote:
> Cc-ing Tejun
>
> On (03/02/18 16:54), Petr Mladek wrote:
> [..]
> > > (Though it is not immediately obvious why.)
> >
> > It is a mistery to me. The error appears when I move any of
> > dump_stack_print_info() or show_regs_print_info() funct
On (03/05/18 13:27), Greentime Hu wrote:
[..]
> >> Opinions? Will this work?
> >
> > I would think b) is better, thanks for the fix!
> >
> Hi,
>
> b works in nds32.
> Thanks for the fix :)
Greentime, Dave, thanks!
I'll send out a patch then.
Petr, once the patch has enough Ack/etc do you want t
2018-03-05 11:20 GMT+08:00 Dave Young :
> On 03/03/18 at 11:47pm, Sergey Senozhatsky wrote:
>> Cc-ing Tejun
>>
>> On (03/02/18 16:54), Petr Mladek wrote:
>> [..]
>> > > (Though it is not immediately obvious why.)
>> >
>> > It is a mistery to me. The error appears when I move any of
>> > dump_stack_
On 03/03/18 at 11:47pm, Sergey Senozhatsky wrote:
> Cc-ing Tejun
>
> On (03/02/18 16:54), Petr Mladek wrote:
> [..]
> > > (Though it is not immediately obvious why.)
> >
> > It is a mistery to me. The error appears when I move any of
> > dump_stack_print_info() or show_regs_print_info() function
Cc-ing Tejun
On (03/02/18 16:54), Petr Mladek wrote:
[..]
> > (Though it is not immediately obvious why.)
>
> It is a mistery to me. The error appears when I move any of
> dump_stack_print_info() or show_regs_print_info() function
> definitions from kernel/printk/printk.c to lib/dump_stack.c.
> A
Hi Petr,
On Fri, 2 Mar 2018 16:54:54 +0100 Petr Mladek wrote:
>
> It is a mistery to me. The error appears when I move any of
> dump_stack_print_info() or show_regs_print_info() function
> definitions from kernel/printk/printk.c to lib/dump_stack.c.
> All the other changes seems unrelated.
Presu
On Fri 2018-03-02 16:07:32, Stephen Rothwell wrote:
> Hi Petr,
>
> After merging the printk tree, today's linux-next build (bfin
> BF518F-EZBRD_defconfig) failed like this:
>
> lib/dump_stack.o: In function `dump_stack':
> lib/dump_stack.c:122: multiple definition of `dump_stack'
> arch/blackfin/
On Thu 2017-12-07 10:26:31, Sergey Senozhatsky wrote:
> On (12/07/17 11:37), Stephen Rothwell wrote:
> [..]
> > include/linux/kallsyms.h: In function 'dereference_symbol_descriptor':
> > include/linux/kallsyms.h:63:8: error: implicit declaration of function
> > '__module_address' [-Werror=implicit
On (12/07/17 11:37), Stephen Rothwell wrote:
[..]
> include/linux/kallsyms.h: In function 'dereference_symbol_descriptor':
> include/linux/kallsyms.h:63:8: error: implicit declaration of function
> '__module_address' [-Werror=implicit-function-declaration]
> mod = __module_address((unsigned long
On (12/06/17 11:17), Petr Mladek wrote:
> On Wed 2017-12-06 14:23:00, Stephen Rothwell wrote:
> > Hi Petr,
> >
> > After merging the printk tree, today's linux-next build (x86_64
> > allnoconfig) failed like this:
> >
> > lib/vsprintf.o: In function `pointer':
> > vsprintf.c:(.text+0x2260): undef
On (12/06/17 11:17), Petr Mladek wrote:
> On Wed 2017-12-06 14:23:00, Stephen Rothwell wrote:
> > Hi Petr,
> >
> > After merging the printk tree, today's linux-next build (x86_64
> > allnoconfig) failed like this:
> >
> > lib/vsprintf.o: In function `pointer':
> > vsprintf.c:(.text+0x2260): undef
On Wed 2017-12-06 14:23:00, Stephen Rothwell wrote:
> Hi Petr,
>
> After merging the printk tree, today's linux-next build (x86_64
> allnoconfig) failed like this:
>
> lib/vsprintf.o: In function `pointer':
> vsprintf.c:(.text+0x2260): undefined reference to
> `dereference_symbol_descriptor'
>
Hello,
On (12/06/17 14:23), Stephen Rothwell wrote:
> Hi Petr,
>
> After merging the printk tree, today's linux-next build (x86_64
> allnoconfig) failed like this:
>
> lib/vsprintf.o: In function `pointer':
> vsprintf.c:(.text+0x2260): undefined reference to
> `dereference_symbol_descriptor'
>
28 matches
Mail list logo
