All of lore.kernel.org
 help / color / mirror / Atom feed
* [next] new fail in linux-next s390 smp
@ 2015-06-26 17:49 Paul Gortmaker
  2015-06-29  9:09 ` Martin Schwidefsky
  0 siblings, 1 reply; 2+ messages in thread
From: Paul Gortmaker @ 2015-06-26 17:49 UTC (permalink / raw)
  To: Michael Holzheu; +Cc: linux-next, schwidefsky

Seen in allnoconfig:

http://kisskb.ellerman.id.au/kisskb/buildresult/12450623/

arch/s390/kernel/setup.c: In function 'setup_arch':
arch/s390/kernel/setup.c:875:2: error: implicit declaration of function
'smp_save_dump_cpus'
make[2]: *** [arch/s390/kernel/setup.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [arch/s390/kernel] Error 2
make: *** [arch/s390] Error 2
make: *** Waiting for unfinished jobs....
1592a8e456436024b6c662f423ce672e672169bb is the first bad commit
commit 1592a8e456436024b6c662f423ce672e672169bb
Author: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Date:   Tue May 26 19:05:23 2015 +0200

    s390/kdump: fix nosmt kernel parameter
    
    It turned out that SIGP set-multi-threading can only be done once.
    Therefore switching to a different MT level after switching to
    sclp.mtid_prev in the dump case fails.
    
    As a symptom specifying the "nosmt" parameter currently fails for
    the kdump kernel and the kernel starts with multi-threading enabled.
    
    So fix this and issue diag 308 subcode 1 call after collecting the
    CPU states for the dump. Also enhance the diag308_reset() function
to
    be usable also with enabled lowcore protection and prefix register
!= 0.
    After the reset it is possible to switch the MT level again. We have
    to do the reset very early in order not to kill the already
initialized
    console. Therefore instead of kmalloc() the corresponding memblock
    functions have to be used. To avoid copying the sclp cpu code into
    sclp_early, we now use the simple sigp loop method for CPU
detection.
    
    Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

:040000 040000 5430eab17daadf67943ab0b5d1979e88c9417e7b
4610519e89468a4c09080f463c31e51fbc2fb4f4 M      arch
:040000 040000 46b9da2c2a089589353ad9a55358803989cd9eb7
100d2243c38ece214cffc72f296a8860cff1a0e5 M      drivers
bisect run success

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [next] new fail in linux-next s390 smp
  2015-06-26 17:49 [next] new fail in linux-next s390 smp Paul Gortmaker
@ 2015-06-29  9:09 ` Martin Schwidefsky
  0 siblings, 0 replies; 2+ messages in thread
From: Martin Schwidefsky @ 2015-06-29  9:09 UTC (permalink / raw)
  To: Paul Gortmaker; +Cc: Michael Holzheu, linux-next

On Fri, 26 Jun 2015 13:49:01 -0400
Paul Gortmaker <paul.gortmaker@windriver.com> wrote:

> Seen in allnoconfig:
> 
> http://kisskb.ellerman.id.au/kisskb/buildresult/12450623/
> 
> arch/s390/kernel/setup.c: In function 'setup_arch':
> arch/s390/kernel/setup.c:875:2: error: implicit declaration of function
> 'smp_save_dump_cpus'
> make[2]: *** [arch/s390/kernel/setup.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [arch/s390/kernel] Error 2
> make: *** [arch/s390] Error 2
> make: *** Waiting for unfinished jobs....

I have added a patch from Heiko to the s390 tree. Should be fixed
with tomorrows -next tree.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-06-29  9:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-26 17:49 [next] new fail in linux-next s390 smp Paul Gortmaker
2015-06-29  9:09 ` Martin Schwidefsky

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.