1. 30 12月, 2015 1 次提交
  2. 23 4月, 2015 1 次提交
  3. 15 8月, 2014 1 次提交
  4. 28 7月, 2014 1 次提交
  5. 21 2月, 2014 2 次提交
  6. 17 4月, 2013 2 次提交
  7. 16 1月, 2013 4 次提交
  8. 08 1月, 2013 2 次提交
    • H
      s390/3215: partially revert tty close handling fix · 6673cd0b
      Heiko Carstens 提交于
      Partially revert ae289dc1 "s390/3215: fix tty close handling", since this
      leads sometimes to hanging agetty processes and therefore systems that get
      stuck while starting.
      
      This was magically fixed (bisected) by a common code patch from Alan Cox:
      36b3c070 "tty: Move the handling of the tty release logic", however it was
      unrelated.
      
      Since the removed code worked for a decade, nobody knows anymore why it was
      in there in the first place and debugging the observed hang is non-trivial
      (at least for me :) ), let's just re-add the removed code before we see
      other side effects.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      6673cd0b
    • H
      s390/irq: remove split irq fields from /proc/stat · 420f42ec
      Heiko Carstens 提交于
      Now that irq sum accounting for /proc/stat's "intr" line works again we
      have the oddity that the sum field (first field) contains only the sum
      of the second (external irqs) and third field (I/O interrupts).
      The reason for that is that these two fields are already sums of all other
      fields. So if we would sum up everything we would count every interrupt
      twice.
      This is broken since the split interrupt accounting was merged two years
      ago: 052ff461 "[S390] irq: have detailed
      statistics for interrupt types".
      To fix this remove the split interrupt fields from /proc/stat's "intr"
      line again and only have them in /proc/interrupts.
      
      This restores the old behaviour, seems to be the only sane fix and mimics
      a behaviour from other architectures where /proc/interrupts also contains
      more than /proc/stat's "intr" line does.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      420f42ec
  9. 16 11月, 2012 1 次提交
    • J
      TTY: call tty_port_destroy in the rest of drivers · 191c5f10
      Jiri Slaby 提交于
      After commit "TTY: move tty buffers to tty_port", the tty buffers are
      not freed in some drivers. This is because tty_port_destructor is not
      called whenever a tty_port is freed. This was an assumption I counted
      with but was unfortunately untrue. So fix the drivers to fulfil this
      assumption.
      
      To be sure, the TTY buffers (and later some stuff) are gone along with
      the tty_port, we have to call tty_port_destroy at tear-down places.
      This is mostly where the structure containing a tty_port is freed.
      This patch does exactly that -- put tty_port_destroy at those places.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      191c5f10
  10. 15 11月, 2012 1 次提交
    • H
      s390/3215: fix tty close handling · ae289dc1
      Heiko Carstens 提交于
      The 3215 console always has the RAW3215_FIXED flag set, which causes
      raw3215_shutdown() not to wait for outstanding I/O requests if an attached
      tty gets closed.
      The flag however can be simply removed, so we can guarantee that all requests
      belonging to the tty have been processed when the tty is closed.
      
      However the tasklet that belongs to the 3215 device may be scheduled even if
      there is no tty attached anymore, since we have a race between console and tty
      processing.
      Thefore unconditional tty_wakekup() in raw3215_wakeup() can cause the following
      NULL pointer dereference:
      
      3.465368 Unable to handle kernel pointer dereference at virtual kernel address (null)
      3.465448 Oops: 0004 #1 SMP
      3.465454 Modules linked in:
      3.465459 CPU: 1 Not tainted 3.6.0 #1
      3.465462 Process swapper/1 (pid: 0, task: 000000003ffa4428, ksp: 000000003ffb7ce0)
      3.465466 Krnl PSW : 0404100180000000 0000000000162f86 (__wake_up+0x46/0xb8)
      3.465480            R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
               Krnl GPRS: fffffffffffffffe 0000000000000000 0000000000000160 0000000000000001
      3.465492            0000000000000001 0000000000000004 0000000000000004 000000000096b490
      3.465499            0000000000000001 0000000000000100 0000000000000001 0000000000000001
      3.465506            070000003fc87d60 0000000000000160 000000003fc87d68 000000003fc87d00
      3.465526 Krnl Code: 0000000000162f76: e3c0f0a80004      lg      %r12,168(%r15)
                          0000000000162f7c: 58000370          l       %r0,880
                         #0000000000162f80: c007ffffffff00    xilf    %r0,4294967295
                         >0000000000162f86: ba102000          cs      %r1,%r0,0(%r2)
                          0000000000162f8a: 1211              ltr     %r1,%r1
                          0000000000162f8c: a774002f          brc     7,162fea
                          0000000000162f90: b904002d          lgr     %r2,%r13
                          0000000000162f94: b904003a          lgr     %r3,%r10
      3.465597 Call Trace:
      3.465599 (<0400000000000000> 0x400000000000000)
      3.465602  <000000000048c77e> raw3215_wakeup+0x2e/0x40
      3.465607  <0000000000134d66> tasklet_action+0x96/0x168
      3.465612  <000000000013423c> __do_softirq+0xd8/0x21c
      3.465615  <0000000000134678> irq_exit+0xa8/0xac
      3.465617  <000000000046c232> do_IRQ+0x182/0x248
      3.465621  <00000000005c8296> io_return+0x0/0x8
      3.465625  <00000000005c7cac> vtime_stop_cpu+0x4c/0xb8
      3.465629 (<0000000000194e06> tick_nohz_idle_enter+0x4e/0x74)
      3.465633  <0000000000104760> cpu_idle+0x170/0x184
      3.465636  <00000000005b5182> smp_start_secondary+0xd6/0xe0
      3.465641  <00000000005c86be> restart_int_handler+0x56/0x6c
      3.465643  <0000000000000000> 0x0
      3.465645 Last Breaking-Event-Address:
      3.465647  <0000000000403136> tty_wakeup+0x46/0x98
      3.465652
      3.465654 Kernel panic - not syncing: Fatal exception in interrupt
      01: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 0010F63C
      
      The easiest solution is simply to check if tty is NULL in the tasklet.
      If it is NULL nothing is to do (no tty attached), otherwise tty_wakeup()
      can be called, since we hold a reference to the tty.
      This is not nice... but it is a small patch and it works.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      ae289dc1
  11. 14 8月, 2012 2 次提交
  12. 18 4月, 2012 1 次提交
  13. 14 4月, 2012 2 次提交
  14. 10 4月, 2012 1 次提交
    • J
      TTY: con3215, centralize allocation · fe2fc9ca
      Jiri Slaby 提交于
      There are two copies of allocations of device information. One of them
      is totally broken. See:
      raw->cdev = cdev;
      raw->inbuf = (char *) raw + sizeof(struct raw3215_info);
      memset(raw, 0, sizeof(struct raw3215_info));
      
      It suggests that this path was never executed. The code uses both
      raw->cdev and raw->inbuf all over. And it is NULL due to the memset
      here, so it would panic immediately. I believe nobody used that driver
      without being a system console.
      
      Either way, let us fix it by moving the allocations (and
      initializations) to a single place. This will save us some double
      initializations later too.
      
      And while at it, initialize the timer properly -- once, at the
      allocation.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux390@de.ibm.com
      Cc: linux-s390@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe2fc9ca
  15. 09 3月, 2012 2 次提交
  16. 17 2月, 2012 1 次提交
  17. 30 10月, 2011 1 次提交
    • P
      [S390] fix mismatch in summation of I/O IRQ statistics · de400d6b
      Peter Oberparleiter 提交于
      Current IRQ statistics support does not show detail counts for I/O
      interrupts which are processed internally only. The result is a
      summation count which is way off such as this one:
      
                 CPU0       CPU1       CPU2
      I/O:       1331        710        442
      [...]
      QAI:         15         16         16   [I/O] QDIO Adapter Interrupt
      QDI:          1          0          0   [I/O] QDIO Interrupt
      DAS:        706        645        381   [I/O] DASD
      C15:         26         10          0   [I/O] 3215
      C70:          0          0          0   [I/O] 3270
      TAP:          0          0          0   [I/O] Tape
      VMR:          0          0          0   [I/O] Unit Record Devices
      LCS:          0          0          0   [I/O] LCS
      CLW:          0          0          0   [I/O] CLAW
      CTC:          0          0          0   [I/O] CTC
      APB:          0          0          0   [I/O] AP Bus
      
      Fix this by moving I/O interrupt accounting into the common I/O layer.
      Signed-off-by: NPeter Oberparleiter <peter.oberparleiter@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      de400d6b
  18. 23 3月, 2011 1 次提交
  19. 05 1月, 2011 1 次提交
  20. 14 1月, 2010 1 次提交
  21. 07 12月, 2009 1 次提交
  22. 22 6月, 2009 2 次提交
  23. 16 6月, 2009 2 次提交
    • M
      [S390] pm: con3215 power management callbacks · 77812a27
      Martin Schwidefsky 提交于
      Introduce the power management callbacks to the 3215 console. On suspend
      the console buffer is flushed to the 3215 device to have an empty console
      buffer. Printks done while the 3215 device is suspended are buffered in
      the 64K buffer of the 3215 device. If the buffer is full new messages will
      push out the oldest messages to make room for the most recent message.
      On resume the buffered messages are printed. If the system panics before
      the 3215 device is resumed ccw_device_force_console is used to get the
      console working again.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      77812a27
    • G
      s390: remove driver_data direct access of struct device · dff59b64
      Greg Kroah-Hartman 提交于
      In the near future, the driver core is going to not allow direct access
      to the driver_data pointer in struct device.  Instead, the functions
      dev_get_drvdata() and dev_set_drvdata() should be used.  These functions
      have been around since the beginning, so are backwards compatible with
      all older kernel versions.
      
      Thanks to Sebastian Ott <sebott@linux.vnet.ibm.com> for fixing a few
      typos in my original version of this patch.
      
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
      Cc: linux-s390@vger.kernel.org
      Cc: linux390@de.ibm.com
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      dff59b64
  24. 11 10月, 2008 2 次提交
    • H
      [S390] 3215: Remove tasklet. · 408aec3c
      Heiko Carstens 提交于
      The 3215 console irq handler used to schedule a tasklet. However the
      console irq handler also gets called from the infamous cio_tpi()
      function. Which in turn does something like
      
      local_bh_disable()
      [call console irq handler]
      _local_bh_enable()
      
      _local_bh_enable() prevents execution of softirqs, which is intended
      within cio_tpi(). However there might be a new softirq pending because
      irq handler scheduled a tasklet.
      In order to prevent this behaviour we just get rid of the tasklet.
      It's not doing much anyway.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      408aec3c
    • H
      [S390] console flush on panic / reboot · 2332ce1a
      Holger Smolinski 提交于
      The s390 console drivers use the unblank callback of the console
      structure to flush the console buffer. In case of a panic or a
      reboot the CPU doing the callback can block on the console i/o.
      The other CPUs in the system continue to work. For panic this is
      not a good idea.
      
      Replace the unblank callback with proper panic/reboot notifier.
      These get called after all but one CPU have been stopped.
      Signed-off-by: NHolger Smolinski <Holger.Smolinski@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      2332ce1a
  25. 14 7月, 2008 3 次提交
  26. 30 4月, 2008 1 次提交