1. 14 2月, 2013 4 次提交
  2. 16 1月, 2013 1 次提交
  3. 08 1月, 2013 3 次提交
    • 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
    • H
      s390/irq: enable irq sum accounting for /proc/stat again · add9bde2
      Heiko Carstens 提交于
      For more than two years, since f2c66cd8
      "/proc/stat: scalability of irq num per cpu" the output of /proc/stat is
      broken.
      The first field in the "intr" line should contain the sum of all interrupts,
      however since the above mentioned change it is always zero.
      
      The reason for that is that a per cpu irq sum variable had been introduced
      which got incremented when calling kstat_incr_irqs_this_cpu(). However
      on s390 we directly incremented only the per cpu per irq counter by accessing
      the array element via kstat_cpu(smp_processor_id()).irqs[...].
      So fix this and use the kstat_incr_irqs_this_cpu() wrapper which increments
      both: the per cpu per irq counter and the per cpu irq sum counter.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      add9bde2
  4. 11 12月, 2012 1 次提交
  5. 03 12月, 2012 1 次提交
    • S
      s390/cio: fix pgid reserved check · d99e79ec
      Sebastian Ott 提交于
      The check to whom a device is reserved is done by checking the path
      state of the affected channel paths. If it turns out that one path is
      flagged as reserved by someone else the whole device is marked as such.
      
      However the meaning of the RESVD_ELSE bit is that the addressed device
      is reserved to a different pathgroup (and not reserved to a different
      LPAR). If we do this test on a path which is currently not a member of
      the pathgroup we could erroneously mark the device as reserved to
      someone else.
      
      To fix this collect the reserved state for all potential members of the
      pathgroup and only mark the device as reserved if all of those potential
      members have the RESVD_ELSE bit set.
      
      Cc: stable@vger.kernel.org
      Acked-by: NPeter Oberparleiter <peter.oberparleiter@de.ibm.com>
      Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      d99e79ec
  6. 01 12月, 2012 2 次提交
  7. 30 11月, 2012 2 次提交
  8. 23 11月, 2012 8 次提交
  9. 20 11月, 2012 6 次提交
  10. 19 11月, 2012 1 次提交
  11. 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
  12. 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
  13. 14 11月, 2012 2 次提交
  14. 07 11月, 2012 2 次提交
  15. 26 10月, 2012 1 次提交
  16. 18 10月, 2012 2 次提交
  17. 17 10月, 2012 2 次提交