1. 24 10月, 2011 6 次提交
    • C
      tfm_fc: use transport_handle_cdb_direct · 4ca495e0
      Christoph Hellwig 提交于
      ft_send_work is always called from workqueue context, which means we can
      handle the CDB directly instead of doing another context switch.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Cc: Kiran Patil <kiran.patil@intel.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      4ca495e0
    • N
      target: Prevent transport_send_task_abort when CHECK_CONDITION status · c252f003
      Nicholas Bellinger 提交于
      This patch fixes a bug where transport_send_task_abort() could be called
      during LUN_RESET to return SAM_STAT_TASK_ABORTED + tfo->queue_status(), when
      SCF_SENT_CHECK_CONDITION -> tfo->queue_status() has already been sent from
      within another context via transport_send_check_condition_and_sense().
      
      Cc: stable@kernel.org
      Signed-off-by: NNicholas Bellinger <nab@risingtidesystems.com>
      c252f003
    • N
      target: Fix transport_cmd_finish_abort queue removal bug · 77039d1e
      Nicholas Bellinger 提交于
      This patch fixes a bug in LUN_RESET operation with transport_cmd_finish_abort()
      where transport_remove_cmd_from_queue() was incorrectly being called, causing
      descriptors with t_state == TRANSPORT_FREE_CMD_INTR to be incorrectly removed
      from qobj->qobj_list during process context release.  This change ensures the
      descriptor is only removed via transport_remove_cmd_from_queue() when doing a
      direct release via transport_generic_remove().
      
      Cc: stable@kernel.org
      Signed-off-by: NNicholas Bellinger <nab@risingtidesystems.com>
      77039d1e
    • N
      target: Prevent TRANSPORT_FREE_CMD_INTR processing in core_tmr_drain_cmd_list · b0e062ae
      Nicholas Bellinger 提交于
      This patch contains a bugfix for TMR LUN_RESET related to TRANSPORT_FREE_CMD_INTR
      operation, where core_tmr_drain_cmd_list() will now skip processing for this
      case to prevent an ABORT_TASK status from being returned for descriptors that
      are already queued up to be released by processing thread context.
      
      Cc: Roland Dreier <roland@purestorage.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: stable@kernel.org
      Signed-off-by: NNicholas Bellinger <nab@risingtidesystems.com>
      b0e062ae
    • N
      target: Re-org of core_tmr_lun_reset · d050ffb9
      Nicholas Bellinger 提交于
      This patch is a re-orginzation of core_tmr_lun_reset() logic to properly
      scan the active tmr_list, dev->state_task_list and qobj->qobj_list w/ the
      relivent locks held, and performing a list_move_tail onto seperate local
      scope lists before performing the full drain.
      
      This involves breaking out the code into three seperate list specific
      functions: core_tmr_drain_tmr_list(), core_tmr_drain_task_list() and
      core_tmr_drain_cmd_list().
      
      (nab: Include target: Remove non-active tasks from execute list during
            LUN_RESET patch to address original breakage)
      Reported-by: NRoland Dreier <roland@purestorage.com>
      Cc: Roland Dreier <roland@purestorage.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: stable@kernel.org
      Signed-off-by: NNicholas Bellinger <nab@risingtidesystems.com>
      d050ffb9
    • R
      target: Prevent cmd->se_queue_node double add · 79a7fef2
      Roland Dreier 提交于
      This patch addresses a bug with the lio-core-2.6.git conversion of
      transport_add_cmd_to_queue() to use a single embedded list_head, instead
      of individual struct se_queue_req allocations allowing a single se_cmd to
      be added to the queue mulitple times.  This was changed in the following:
      
      commit 2a9e4d5ca5d99f4c600578d6285d45142e7e5208
      Author: Andy Grover <agrover@redhat.com>
      Date:   Tue Apr 26 17:45:51 2011 -0700
      
          target: Embed qr in struct se_cmd
      
      The problem is that some target code still assumes performing multiple
      adds is allowed via transport_add_cmd_to_queue(), which ends up causing
      list corruption in qobj->qobj_list code.  This patch addresses this
      by removing an existing struct se_cmd from the list before the add, and
      removes an unnecessary list walk in transport_remove_cmd_from_queue()
      
      It also changes cmd->t_transport_queue_active to use explict sets intead
      of increment/decrement to prevent confusion during exception path handling.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NNicholas Bellinger <nab@risingtidesystems.com>
      79a7fef2
  2. 11 10月, 2011 1 次提交
  3. 10 10月, 2011 6 次提交
  4. 09 10月, 2011 1 次提交
  5. 08 10月, 2011 1 次提交
  6. 07 10月, 2011 5 次提交
    • S
      ARM: mach-ux500: enable fix for ARM errata 754322 · 98e87d57
      srinidhi kasagar 提交于
      This applies ARM errata fix 754322 for all ux500 platforms.
      
      Cc: stable@kernel.org
      Signed-off-by: Nsrinidhi kasagar <srinidhi.kasagar@stericsson.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      98e87d57
    • L
      Merge git://github.com/davem330/net · 3ee72ca9
      Linus Torvalds 提交于
      * git://github.com/davem330/net:
        net: fix typos in Documentation/networking/scaling.txt
        bridge: leave carrier on for empty bridge
        netfilter: Use proper rwlock init function
        tcp: properly update lost_cnt_hint during shifting
        tcp: properly handle md5sig_pool references
        macvlan/macvtap: Fix unicast between macvtap interfaces in bridge mode
      3ee72ca9
    • P
      x86/PCI: use host bridge _CRS info on ASUS M2V-MX SE · 29cf7a30
      Paul Menzel 提交于
      In summary, this DMI quirk uses the _CRS info by default for the ASUS
      M2V-MX SE by turning on `pci=use_crs` and is similar to the quirk
      added by commit 2491762c ("x86/PCI: use host bridge _CRS info on
      ASRock ALiveSATA2-GLAN") whose commit message should be read for further
      information.
      
      Since commit 3e3da00c ("x86/pci: AMD one chain system to use pci
      read out res") Linux gives the following oops:
      
          parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
          HDA Intel 0000:20:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
          HDA Intel 0000:20:01.0: setting latency timer to 64
          BUG: unable to handle kernel paging request at ffffc90011c08000
          IP: [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
          PGD 13781a067 PUD 13781b067 PMD 1300ba067 PTE 800000fd00000173
          Oops: 0009 [#1] SMP
          last sysfs file: /sys/module/snd_pcm/initstate
          CPU 0
          Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event tpm_tis tpm snd_seq tpm_bios psmouse parport_pc snd_timer snd_seq_device parport processor evdev snd i2c_viapro thermal_sys amd64_edac_mod k8temp i2c_core soundcore shpchp pcspkr serio_raw asus_atk0110 pci_hotplug edac_core button snd_page_alloc edac_mce_amd ext3 jbd mbcache sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod raid1 md_mod usbhid hid sg sd_mod crc_t10dif sr_mod cdrom ata_generic uhci_hcd sata_via pata_via libata ehci_hcd usbcore scsi_mod via_rhine mii nls_base [last unloaded: scsi_wait_scan]
          Pid: 1153, comm: work_for_cpu Not tainted 2.6.37-1-amd64 #1 M2V-MX SE/System Product Name
          RIP: 0010:[<ffffffffa0578402>]  [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
          RSP: 0018:ffff88013153fe50  EFLAGS: 00010286
          RAX: ffffc90011c08000 RBX: ffff88013029ec00 RCX: 0000000000000006
          RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
          RBP: ffff88013341d000 R08: 0000000000000000 R09: 0000000000000040
          R10: 0000000000000286 R11: 0000000000003731 R12: ffff88013029c400
          R13: 0000000000000000 R14: 0000000000000000 R15: ffff88013341d090
          FS:  0000000000000000(0000) GS:ffff8800bfc00000(0000) knlGS:00000000f7610ab0
          CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
          CR2: ffffc90011c08000 CR3: 0000000132f57000 CR4: 00000000000006f0
          DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
          DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
          Process work_for_cpu (pid: 1153, threadinfo ffff88013153e000, task ffff8801303c86c0)
          Stack:
           0000000000000005 ffffffff8123ad65 00000000000136c0 ffff88013029c400
           ffff8801303c8998 ffff88013341d000 ffff88013341d090 ffff8801322d9dc8
           ffff88013341d208 0000000000000000 0000000000000000 ffffffff811ad232
          Call Trace:
           [<ffffffff8123ad65>] ? __pm_runtime_set_status+0x162/0x186
           [<ffffffff811ad232>] ? local_pci_probe+0x49/0x92
           [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b
           [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b
           [<ffffffff8105afd0>] ? do_work_for_cpu+0xb/0x1b
           [<ffffffff8105fd3f>] ? kthread+0x7a/0x82
           [<ffffffff8100a824>] ? kernel_thread_helper+0x4/0x10
           [<ffffffff8105fcc5>] ? kthread+0x0/0x82
           [<ffffffff8100a820>] ? kernel_thread_helper+0x0/0x10
          Code: f4 01 00 00 ef 31 f6 48 89 df e8 29 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 b4 39 c3 e0 8b 7b 40 e8 fc 9d b1 e0 48 8b 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be
          RIP  [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
           RSP <ffff88013153fe50>
          CR2: ffffc90011c08000
          ---[ end trace 8d1f3ebc136437fd ]---
      
      Trusting the ACPI _CRS information (`pci=use_crs`) fixes this problem.
      
          $ dmesg | grep -i crs # with the quirk
          PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
      
      The match has to be against the DMI board entries though since the vendor entries are not populated.
      
          DMI: System manufacturer System Product Name/M2V-MX SE, BIOS 0304    10/30/2007
      
      This quirk should be removed when `pci=use_crs` is enabled for machines
      from 2006 or earlier or some other solution is implemented.
      
      Using coreboot [1] with this board the problem does not exist but this
      quirk also does not affect it either. To be safe though the check is
      tightened to only take effect when the BIOS from American Megatrends is
      used.
      
              15:13 < ruik> but coreboot does not need that
              15:13 < ruik> because i have there only one root bus
              15:13 < ruik> the audio is behind a bridge
      
              $ sudo dmidecode
              BIOS Information
                      Vendor: American Megatrends Inc.
                      Version: 0304
                      Release Date: 10/30/2007
      
      [1] http://www.coreboot.org/
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=30552
      
      Cc: stable@kernel.org (2.6.34)
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: x86@kernel.org
      Signed-off-by: NPaul Menzel <paulepanter@users.sourceforge.net>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      29cf7a30
    • B
      net: fix typos in Documentation/networking/scaling.txt · 186c6bbc
      Benjamin Poirier 提交于
      The second hunk fixes rps_sock_flow_table but has to re-wrap the paragraph.
      Signed-off-by: NBenjamin Poirier <benjamin.poirier@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      186c6bbc
    • S
      bridge: leave carrier on for empty bridge · b64b73d7
      stephen hemminger 提交于
      This resolves a regression seen by some users of bridging.
      Some users use the bridge like a dummy device.
      They expect to be able to put an IPv6 address on the device
      with no ports attached. Although there are better ways of doing
      this, there is no reason to not allow it.
      
      Note: the bridge still will reflect the state of ports in the
      bridge if there are any added.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b64b73d7
  7. 06 10月, 2011 6 次提交
  8. 05 10月, 2011 14 次提交