1. 18 12月, 2015 1 次提交
  2. 16 11月, 2015 1 次提交
  3. 09 11月, 2015 1 次提交
    • S
      s390/head: fix error message on unsupported hardware · c6eafbf9
      Sascha Silbe 提交于
      startup calls the C function _sclp_print_early() if the machine we're
      running on is not supported by the kernel. sclp.c is getting built
      with -m64, so _sclp_print_early() expects the zSeries ELF ABI to be
      used.
      
      We previously called _sclp_print_early() using the S/390 ELF ABI, with
      a stack frame size of 96 bytes and while being in 31-bit address
      mode. This caused _sclp_wait_int() (called indirectly from
      _sclp_print_early()) to jump to an undefined address. While
      _sclp_wait_int() contained some code to deal with being called in
      31-bit addressing mode, it didn't quite work. While fixing this is
      possible, the code would still only work by chance and could break any
      time.
      
      Ensure compliance with the zSeries ELF ABI by switching to 64-bit
      addressing mode early and using a minimum stack frame size of 160
      bytes.
      Signed-off-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
      Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c6eafbf9
  4. 19 8月, 2015 1 次提交
  5. 29 7月, 2015 1 次提交
  6. 25 3月, 2015 1 次提交
    • H
      s390: remove 31 bit support · 5a79859a
      Heiko Carstens 提交于
      Remove the 31 bit support in order to reduce maintenance cost and
      effectively remove dead code. Since a couple of years there is no
      distribution left that comes with a 31 bit kernel.
      
      The 31 bit kernel also has been broken since more than a year before
      anybody noticed. In addition I added a removal warning to the kernel
      shown at ipl for 5 minutes: a960062e ("s390: add 31 bit warning
      message") which let everybody know about the plan to remove 31 bit
      code. We didn't get any response.
      
      Given that the last 31 bit only machine was introduced in 1999 let's
      remove the code.
      Anybody with 31 bit user space code can still use the compat mode.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      5a79859a
  7. 22 1月, 2015 1 次提交
  8. 25 9月, 2014 1 次提交
  9. 16 7月, 2014 1 次提交
  10. 28 5月, 2014 1 次提交
  11. 27 5月, 2014 1 次提交
  12. 24 10月, 2013 1 次提交
    • H
      s390/bitops: optimize set_bit() for constant values · 4ae80325
      Heiko Carstens 提交于
      Since zEC12 we have the interlocked-access facility 2 which allows to
      use the instructions ni/oi/xi to update a single byte in storage with
      compare-and-swap semantics.
      So change set_bit(), clear_bit() and change_bit() to generate such code
      instead of a compare-and-swap loop (or using the load-and-* instruction
      family), if possible.
      This reduces the text segment by yet another 8KB (defconfig).
      
      Alternatively the long displacement variants niy/oiy/xiy could have
      been used, but the extended displacement field is usually not needed
      and therefore would only increase the size of the text segment again.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      4ae80325
  13. 23 11月, 2012 1 次提交
    • H
      s390: add zEC12 code generation support · 991c1505
      Heiko Carstens 提交于
      Allow to generate code that only runs on zEC12 machines.
      
      Also add a check which prevents the kernel to run on machines which
      do not have any of the following new facilities installed:
      
      - (48) decimal-floating-point zoned-conversion
      - (49) execution-hint
      - (49) load-and-trap
      - (49) miscellaneous-instruction-extensions
      - (49) processor-assist
      - (50) constrained transactional-execution
      - (73) transactional-execution
      
      48, 49, 50 and 73 are the bit numbers of the facility indications for
      each of the required facilities.
      
      Note that we assume that user-space gets compiled with the same
      compiler options, therefore we also test for a dfp facility even
      if the kernel doesn't make use of it.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      991c1505
  14. 09 10月, 2012 1 次提交
  15. 20 7月, 2012 1 次提交
    • H
      s390/comments: unify copyright messages and remove file names · a53c8fab
      Heiko Carstens 提交于
      Remove the file name from the comment at top of many files. In most
      cases the file name was wrong anyway, so it's rather pointless.
      
      Also unify the IBM copyright statement. We did have a lot of sightly
      different statements and wanted to change them one after another
      whenever a file gets touched. However that never happened. Instead
      people start to take the old/"wrong" statements to use as a template
      for new files.
      So unify all of them in one go.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      a53c8fab
  16. 16 5月, 2012 1 次提交
  17. 11 4月, 2012 1 次提交
    • M
      [S390] Fix stfle() lowcore protection problem · 37e37c20
      Michael Holzheu 提交于
      The stfle() function writes into lowcore memory when stfl_fac_list
      is initialized with "S390_lowcore.stfl_fac_list = 0". For older
      compilers this triggers a lowcore exception. With newer compilers
      and "-OXX" compile option the bug does not show up because
      the "S390_lowcore.stfl_fac_list" initialization is removed by the
      compiler. The reason for thatis the incorrect "=m"
      (S390_lowcore.stfl_fac_list) constraint in the stfl inline assembly.
      
      The following shows the disassembly of the stfle() optimized code
      that is inlined in the lgr_info_get() function:
      
      000000000011325c <lgr_info_get>:
        11325c:       eb 9f f0 60 00 24       stmg    %r9,%r15,96(%r15)
        113262:       c0 d0 00 29 0e 47       larl    %r13,634ef0 <servi..>
        113268:       a7 f1 3f c0             tml     %r15,16320
        11326c:       b9 04 00 ef             lgr     %r14,%r15
        113270:       a7 84 00 01             je      113272 <lgr_info_g..>
        113274:       a7 fb ff c0             aghi    %r15,-64
        113278:       b9 04 00 c2             lgr     %r12,%r2
        11327c:       a7 29 00 01             lghi    %r2,1
        113280:       e3 e0 f0 98 00 24       stg     %r14,152(%r15)
        113286:       d7 97 c0 00 c0 00       xc      0(152,%r12),0(%r12)
        11328c:       c0 e5 00 28 db 4c       brasl   %r14,62e924 <add_e..>
        113292:       b2 b1 00 00             stfl    0
      
      To fix the problem we now clear the S390_lowcore.stfl_fac_list at
      startup in "head.S" for all machine types before lowcore protection
      is enabled.
      
      In addition to that the "=m" constraint is replaced by "+m".
      Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      37e37c20
  18. 27 12月, 2011 1 次提交
  19. 30 10月, 2011 1 次提交
  20. 24 7月, 2011 1 次提交
  21. 04 4月, 2011 1 次提交
  22. 25 10月, 2010 1 次提交
  23. 10 8月, 2010 1 次提交
  24. 17 5月, 2010 1 次提交
  25. 24 3月, 2010 1 次提交
  26. 27 2月, 2010 3 次提交
  27. 11 9月, 2009 1 次提交
  28. 13 6月, 2009 1 次提交
  29. 12 6月, 2009 2 次提交
  30. 27 4月, 2009 1 次提交
  31. 14 4月, 2009 2 次提交
  32. 26 3月, 2009 1 次提交
  33. 25 12月, 2008 1 次提交
  34. 27 7月, 2007 1 次提交
  35. 04 12月, 2006 1 次提交
  36. 28 9月, 2006 1 次提交