1. 03 2月, 2012 1 次提交
  2. 27 12月, 2011 1 次提交
  3. 21 12月, 2011 5 次提交
    • E
      qeth: recovery through asynchronous delivery · 72861ae7
      Einar Lueck 提交于
      If recovery is triggered in presence of pending asynchronous
      deliveries of storage blocks we do a forced cleanup after
      the corresponding tasklets are completely stopped and trigger
      appropriate notifications for the correspondingerror state.
      Signed-off-by: NEinar Lueck <elelueck@de.ibm.com>
      Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
      Signed-off-by: NFrank Blaschka <frank.blaschka@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72861ae7
    • F
      qeth: improve recovery during resource shortage · 3f36b890
      Frank Blaschka 提交于
      In case there are no system resources to run a recovery we have to clear
      recovery bitmasks so a further automatic or manual driven recovery can
      fix up the device.
      Signed-off-by: NFrank Blaschka <frank.blaschka@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f36b890
    • U
      netiucv: allow multiple interfaces to same peer · 08e3356c
      Ursula Braun 提交于
      The NETIUCV device driver allows to connect a Linux guest on z/VM to
      another z/VM guest based on the z/VM communication facility IUCV.
      Multiple output paths to different guests are possible, as well as
      multiple input paths from different guests.
      With this feature, you can configure multiple point-to-point NETIUCV
      interfaces between your Linux on System z instance and another z/VM
      guest.
      Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
      Signed-off-by: NFrank Blaschka <frank.blaschka@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08e3356c
    • U
      qeth: forbid recovery during shutdown · f78ac2bb
      Ursula Braun 提交于
      A recovery does not make sense during shutdown and may even cause an
      error like this:
      
      qeth 0.0.f503: A recovery process has been started for the device
      Badness at drivers/s390/cio/qdio_main.c:1156
      Modules linked in: autofs4 sunrpc dm_multipath scsi_dh scsi_mod qeth_l3 ipv6 vmu
      r qeth qdio ccwgroup ext3 jbd mbcache dasd_eckd_mod dasd_mod dm_mirror dm_region
      _hash dm_log dm_mod [last unloaded: scsi_wait_scan]
      CPU: 3 Not tainted 2.6.32-202.el6.s390x #1
      Process qeth_recover (pid: 1498, task: 000000003efe2040, ksp: 000000003d5e3b80)
      Krnl PSW : 0404200180000000 000003c000be6da8 (qdio_int_handler+0x88/0x43c [qdio]
      )
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
      Krnl GPRS: ffffffffffff3bac 0000000000000005 0000000000000000 fffffffffffffff4
                 0000000000000000 000000000000000c 0000000000000000 000000003ca97000
                 0000000000000380 fffffffffffffff4 000000003f22d800 000000003f22c478
                 000003c000bdf000 000003c000bea270 000000003f447e10 000000003f447db0
      Krnl Code: 000003c000be6d9a: c21f00000004       clfi    %r1,4
                 000003c000be6da0: a7c40021           brc     12,3c000be6de2
                 000003c000be6da4: a7f40001           brc     15,3c000be6da6
                >000003c000be6da8: e320a0080004       lg      %r2,8(%r10)
                 000003c000be6dae: a7390003           lghi    %r3,3
                 000003c000be6db2: a72b0178           aghi    %r2,376
                 000003c000be6db6: a7490001           lghi    %r4,1
                 000003c000be6dba: a7590000           lghi    %r5,0
      Call Trace:
      ([<000000000080ee80>] __per_cpu_offset+0x0/0x200)
      [<00000000003d90e8>] ccw_device_call_handler+0x70/0xcc
      [<00000000003d83a2>] ccw_device_irq+0x82/0x180
      [<00000000003cc6a8>] do_IRQ+0x16c/0x1ec
      [<0000000000118abe>] io_return+0x0/0x8
      [<000003c000d04c74>] qeth_determine_capabilities+0x208/0x5cc [qeth]
      ([<000003c000d04c4a>] qeth_determine_capabilities+0x1de/0x5cc [qeth])
      [<000003c000d0a6e0>] qeth_core_hardsetup_card+0x160/0x1258 [qeth]
      [<000003c000f49f56>] __qeth_l3_set_online+0x132/0xb14 [qeth_l3]
      [<000003c000f4ac70>] qeth_l3_recover+0x168/0x224 [qeth_l3]
      [<000000000016e210>] kthread+0xa4/0xac
      [<0000000000109c6e>] kernel_thread_starter+0x6/0xc
      [<0000000000109c68>] kernel_thread_starter+0x0/0xc
      
      The patch forbids start of a recovery once qeth shutdown is running.
      Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
      Signed-off-by: NFrank Blaschka <frank.blaschka@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f78ac2bb
    • U
      qeth: suspicious rcu_dereference_check in recovery · 4763b0a0
      Ursula Braun 提交于
      qeth layer3 recovery invokes its set_multicast_list function, which
      invokes function __vlan_find_dev_deep requiring rcu_read_lock or
      rtnl lock. This causes kernel messages:
      
      kernel: [ INFO: suspicious rcu_dereference_check() usage. ]
      kernel: ---------------------------------------------------
      kernel: net/8021q/vlan_core.c:70 invoked rcu_dereference_check() without protection!
      
      kernel: stack backtrace:
      kernel: CPU: 0 Not tainted 3.1.0 #9
      kernel: Process qeth_recover (pid: 2078, task: 000000007e584680, ksp: 000000007e3e3930)
      kernel: 000000007e3e3d08 000000007e3e3c88 0000000000000002 0000000000000000
      kernel:       000000007e3e3d28 000000007e3e3ca0 000000007e3e3ca0 00000000005e77ce
      kernel:       0000000000000000 0000000000000001 ffffffffffffffff 0000000000000001
      kernel:       000000000000000d 000000000000000c 000000007e3e3cf0 0000000000000000
      kernel:       0000000000000000 0000000000100a18 000000007e3e3c88 000000007e3e3cc8
      kernel: Call Trace:
      kernel: ([<0000000000100926>] show_trace+0xee/0x144)
      kernel: [<00000000005d395c>] __vlan_find_dev_deep+0xb0/0x108
      kernel: [<00000000004acd3a>] qeth_l3_set_multicast_list+0x976/0xe38
      kernel: [<00000000004ae0f4>] __qeth_l3_set_online+0x75c/0x1498
      kernel: [<00000000004aefec>] qeth_l3_recover+0xc4/0x1d0
      kernel: [<0000000000185372>] kthread+0xa6/0xb0
      kernel: [<00000000005ed4c6>] kernel_thread_starter+0x6/0xc
      kernel: [<00000000005ed4c0>] kernel_thread_starter+0x0/0xc
      
      The patch makes sure the rtnl lock is held once qeth recovery invokes
      its set_multicast_list function.
      Signed-off-by: NUrsula Braun <ursula.braun@de.ibm.com>
      Signed-off-by: NFrank Blaschka <frank.blaschka@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4763b0a0
  4. 09 12月, 2011 1 次提交
  5. 06 12月, 2011 1 次提交
  6. 17 11月, 2011 6 次提交
  7. 10 11月, 2011 1 次提交
  8. 30 10月, 2011 2 次提交
  9. 16 9月, 2011 1 次提交
  10. 18 8月, 2011 1 次提交
  11. 13 8月, 2011 6 次提交
  12. 27 7月, 2011 1 次提交
  13. 22 7月, 2011 1 次提交
  14. 18 7月, 2011 1 次提交
  15. 07 6月, 2011 1 次提交
  16. 06 6月, 2011 1 次提交
  17. 19 5月, 2011 1 次提交
  18. 14 5月, 2011 6 次提交
  19. 06 5月, 2011 1 次提交
  20. 20 4月, 2011 1 次提交