1. 05 Oct, 2014 2 commits
  2. 31 Jul, 2014 3 commits
    • Romain Degez's avatar
      ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode) · d35acb6e
      Romain Degez authored
      commit b32bfc06aefab61acc872dec3222624e6cd867ed upstream.
      
      Add support of the Promise FastTrak TX8660 SATA HBA in ahci mode by
      registering the board in the ahci_pci_tbl[].
      
      Note: this HBA also provide a hardware RAID mode when activated in
      BIOS but specific drivers from the manufacturer are required in this
      case.
      Signed-off-by: 's avatarRomain Degez <romain.degez@gmail.com>
      Tested-by: 's avatarRomain Degez <romain.degez@gmail.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d35acb6e
    • Tejun Heo's avatar
      libata: introduce ata_host->n_tags to avoid oops on SAS controllers · 03cccb9c
      Tejun Heo authored
      commit 1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6 upstream.
      
      1871ee134b73 ("libata: support the ata host which implements a queue
      depth less than 32") directly used ata_port->scsi_host->can_queue from
      ata_qc_new() to determine the number of tags supported by the host;
      unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
      leading to the following oops.
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
       IP: [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
       PGD 0
       Oops: 0002 [#1] SMP
       Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
       CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ #62
       Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
       task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
       RIP: 0010:[<ffffffff814e0618>]  [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
       RSP: 0018:ffff88061a003ae8  EFLAGS: 00010012
       RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
       RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
       RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
       R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
       R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
       FS:  00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
       Stack:
        ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
        ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
        ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
       Call Trace:
        [<ffffffff814e96e1>] ata_sas_queuecmd+0xa1/0x430
        [<ffffffffa0056ce1>] sas_queuecommand+0x191/0x220 [libsas]
        [<ffffffff8149afee>] scsi_dispatch_cmd+0x10e/0x300 [<ffffffff814a3bc5>] scsi_request_fn+0x2f5/0x550
        [<ffffffff81317613>] __blk_run_queue+0x33/0x40
        [<ffffffff8131781a>] queue_unplugged+0x2a/0x90
        [<ffffffff8131ceb4>] blk_flush_plug_list+0x1b4/0x210
        [<ffffffff8131d274>] blk_finish_plug+0x14/0x50
        [<ffffffff8117eaa8>] __do_page_cache_readahead+0x198/0x1f0
        [<ffffffff8117ee21>] force_page_cache_readahead+0x31/0x50
        [<ffffffff8117ee7e>] page_cache_sync_readahead+0x3e/0x50
        [<ffffffff81172ac6>] generic_file_read_iter+0x496/0x5a0
        [<ffffffff81219897>] blkdev_read_iter+0x37/0x40
        [<ffffffff811e307e>] new_sync_read+0x7e/0xb0
        [<ffffffff811e3734>] vfs_read+0x94/0x170
        [<ffffffff811e43c6>] SyS_read+0x46/0xb0
        [<ffffffff811e33d1>] ? SyS_lseek+0x91/0xb0
        [<ffffffff8171ee29>] system_call_fastpath+0x16/0x1b
       Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 <89> 14 25 58 00 00 00
      
      Fix it by introducing ata_host->n_tags which is initialized to
      ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
      scsi_host_template->can_queue in ata_host_register() for !SAS ones.
      As SAS hosts are never registered, this will give them the same
      ATA_MAX_QUEUE - 1 as before.  Note that we can't use
      scsi_host->can_queue directly for SAS hosts anyway as they can go
      higher than the libata maximum.
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Reported-by: 's avatarMike Qiu <qiudayu@linux.vnet.ibm.com>
      Reported-by: 's avatarJesse Brandeburg <jesse.brandeburg@gmail.com>
      Reported-by: 's avatarPeter Hurley <peter@hurleysoftware.com>
      Reported-by: 's avatarPeter Zijlstra <peterz@infradead.org>
      Tested-by: 's avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Fixes: 1871ee134b73 ("libata: support the ata host which implements a queue depth less than 32")
      Cc: Kevin Hao <haokexin@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03cccb9c
    • Kevin Hao's avatar
      libata: support the ata host which implements a queue depth less than 32 · 97a23070
      Kevin Hao authored
      commit 1871ee134b73fb4cadab75752a7152ed2813c751 upstream.
      
      The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2d6
      ("libata/ahci: accommodate tag ordered controllers"). The reason is
      that the ata controller on this SoC only implement a queue depth of
      16. When issuing the commands in tag order, all the commands in tag
      16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
      malfunction. It makes no senses to use a 32 queue in software while
      the hardware has less queue depth. So consider the queue depth
      implemented by the hardware when requesting a command tag.
      
      Fixes: 8a4aeec8d2d6 ("libata/ahci: accommodate tag ordered controllers")
      Signed-off-by: 's avatarKevin Hao <haokexin@gmail.com>
      Acked-by: 's avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97a23070
  3. 16 Jun, 2014 2 commits
  4. 07 Jun, 2014 2 commits
  5. 13 May, 2014 1 commit
    • Dan Williams's avatar
      libata/ahci: accommodate tag ordered controllers · cfd192c9
      Dan Williams authored
      commit 8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd upstream.
      
      The AHCI spec allows implementations to issue commands in tag order
      rather than FIFO order:
      
      	5.3.2.12 P:SelectCmd
      	HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1)
      	or HBA selects the command to issue that has had the
      	PxCI bit set to '1' longer than any other command
      	pending to be issued.
      
      The result is that commands posted sequentially (time-wise) may play out
      of sequence when issued by hardware.
      
      This behavior has likely been hidden by drives that arrange for commands
      to complete in issue order.  However, it appears recent drives (two from
      different vendors that we have found so far) inflict out-of-order
      completions as a matter of course.  So, we need to take care to maintain
      ordered submission, otherwise we risk triggering a drive to fall out of
      sequential-io automation and back to random-io processing, which incurs
      large latency and degrades throughput.
      
      This issue was found in simple benchmarks where QD=2 seq-write
      performance was 30-50% *greater* than QD=32 seq-write performance.
      
      Tagging for -stable and making the change globally since it has a low
      risk-to-reward ratio.  Also, word is that recent versions of an unnamed
      OS also does it this way now.  So, drives in the field are already
      experienced with this tag ordering scheme.
      
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Ed Ciechanowski <ed.ciechanowski@intel.com>
      Reviewed-by: 's avatarMatthew Wilcox <matthew.r.wilcox@intel.com>
      Signed-off-by: 's avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cfd192c9
  6. 24 Mar, 2014 1 commit
  7. 07 Mar, 2014 3 commits
  8. 06 Feb, 2014 3 commits
    • Tejun Heo's avatar
      libata: disable LPM for some WD SATA-I devices · f07b772d
      Tejun Heo authored
      commit ecd75ad514d73efc1bbcc5f10a13566c3ace5f53 upstream.
      
      For some reason, some early WD drives spin up and down drives
      erratically when the link is put into slumber mode which can reduce
      the life expectancy of the device significantly.  Unfortunately, we
      don't have full list of devices and given the nature of the issue it'd
      be better to err on the side of false positives than the other way
      around.  Let's disable LPM on all WD devices which match one of the
      known problematic model prefixes and are SATA-I.
      
      As horkage list doesn't support matching SATA capabilities, this is
      implemented as two horkages - WD_BROKEN_LPM and NOLPM.  The former is
      set for the known prefixes and sets the latter if the matched device
      is SATA-I.
      
      Note that this isn't optimal as this disables all LPM operations and
      partial link power state reportedly works fine on these; however, the
      way LPM is implemented in libata makes it difficult to precisely map
      libata LPM setting to specific link power state.  Well, these devices
      are already fairly outdated.  Let's just disable whole LPM for now.
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Reported-and-tested-by: 's avatarNikos Barkas <levelwol@gmail.com>
      Reported-and-tested-by: 's avatarIoannis Barkas <risc4all@yahoo.com>
      References: https://bugzilla.kernel.org/show_bug.cgi?id=57211Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f07b772d
    • Lior Amsalem's avatar
      ata: sata_mv: fix disk hotplug for Armada 370/XP SoCs · 6314611a
      Lior Amsalem authored
      commit 9013d64e661fc2a37a1742670202171c27fef4b5 upstream.
      
      On Armada 370/XP SoCs, once a disk is removed from a SATA port, then the
      re-plug events are not detected by the sata_mv driver. This patch fixes
      the issue by updating the PHY speed in the LP_PHY_CTL register (0x58)
      according to the SControl speed.
      
      Note that this fix is only applied if the compatible string
      "marvell,armada-370-sata" is found in the SATA DT node.
      
      Fixes: 9ae6f740 ("arm: mach-mvebu: add support for Armada 370 and Armada XP with DT")
      Signed-off-by: 's avatarLior Amsalem <alior@marvell.com>
      Signed-off-by: 's avatarNadav Haklai <nadavh@marvell.com>
      Signed-off-by: 's avatarSimon Guinot <simon.guinot@sequanux.org>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Gregory Clement <gregory.clement@free-electrons.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Acked-by: 's avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6314611a
    • Simon Guinot's avatar
      ata: sata_mv: introduce compatible string "marvell, armada-370-sata" · 509e5695
      Simon Guinot authored
      commit b1f5c73bd5a4752efb7d7af019034044b08aafe9 upstream.
      
      The sata_mv driver supports the SATA IP found in several Marvell SoCs.
      As some new SATA registers have been introduced with the Armada 370/XP
      SoCs, a way to identify them is needed.
      
      This patch introduces a new compatible string for the SATA IP found in
      Armada 370/XP SoCs.
      Signed-off-by: 's avatarSimon Guinot <simon.guinot@sequanux.org>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Gregory Clement <gregory.clement@free-electrons.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Lior Amsalem <alior@marvell.com>
      Acked-by: 's avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      509e5695
  9. 15 Jan, 2014 1 commit
  10. 09 Jan, 2014 4 commits
  11. 12 Dec, 2013 1 commit
  12. 04 Dec, 2013 5 commits
    • Samir Benmendil's avatar
      ahci: add Marvell 9230 to the AHCI PCI device list · 61688ba3
      Samir Benmendil authored
      commit 6d5278a68a75891db1df5ae1ecf83d288fc58c65 upstream.
      
      Tested with a DAWICONTROL DC-624e on 3.10.10
      Signed-off-by: 's avatarSamir Benmendil <samir.benmendil@gmail.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Reviewed-by: 's avatarLevente Kurusa <levex@linux.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61688ba3
    • xiangliang yu's avatar
      ahci: disabled FBS prior to issuing software reset · 420df0f5
      xiangliang yu authored
      commit 89dafa20f3daab5b3e0c13d0068a28e8e64e2102 upstream.
      
      Tested with Marvell 88se9125, attached with one port mulitplier(5 ports)
      and one disk, we will get following boot log messages if using current
      code:
      
        ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
        ata8.15: Port Multiplier 1.2, 0x1b4b:0x9715 r160, 5 ports, feat 0x1/0x1f
        ahci 0000:03:00.0: FBS is enabled
        ata8.00: hard resetting link
        ata8.00: SATA link down (SStatus 0 SControl 330)
        ata8.01: hard resetting link
        ata8.01: SATA link down (SStatus 0 SControl 330)
        ata8.02: hard resetting link
        ata8.02: SATA link down (SStatus 0 SControl 330)
        ata8.03: hard resetting link
        ata8.03: SATA link up 6.0 Gbps (SStatus 133 SControl 133)
        ata8.04: hard resetting link
        ata8.04: failed to resume link (SControl 133)
        ata8.04: failed to read SCR 0 (Emask=0x40)
        ata8.04: failed to read SCR 0 (Emask=0x40)
        ata8.04: failed to read SCR 1 (Emask=0x40)
        ata8.04: failed to read SCR 0 (Emask=0x40)
        ata8.03: native sectors (2) is smaller than sectors (976773168)
        ata8.03: ATA-8: ST3500413AS, JC4B, max UDMA/133
        ata8.03: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
        ata8.03: configured for UDMA/133
        ata8.04: failed to IDENTIFY (I/O error, err_mask=0x100)
        ata8.15: hard resetting link
        ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
        ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
        ata8.15: PMP revalidation failed (errno=-19)
        ata8.15: hard resetting link
        ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
        ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
        ata8.15: PMP revalidation failed (errno=-19)
        ata8.15: limiting SATA link speed to 3.0 Gbps
        ata8.15: hard resetting link
        ata8.15: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
        ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
        ata8.15: PMP revalidation failed (errno=-19)
        ata8.15: failed to recover PMP after 5 tries, giving up
        ata8.15: Port Multiplier detaching
        ata8.03: disabled
        ata8.00: disabled
        ata8: EH complete
      
      The reason is that current detection code doesn't follow AHCI spec:
      
      First,the port multiplier detection process look like this:
      
      	ahci_hardreset(link, class, deadline)
      	if (class == ATA_DEV_PMP) {
      		sata_pmp_attach(dev)	/* will enable FBS */
      		sata_pmp_init_links(ap, nr_ports);
      		ata_for_each_link(link, ap, EDGE) {
      			sata_std_hardreset(link, class, deadline);
      			if (link_is_online)	/* do soft reset */
      				ahci_softreset(link, class, deadline);
      		}
      	}
      But, according to chapter 9.3.9 in AHCI spec: Prior to issuing software
      reset, software shall clear PxCMD.ST to '0' and then clear PxFBS.EN to
      '0'.
      
      The patch test ok with kernel 3.11.1.
      
      tj: Patch white space contaminated, applied manually with trivial
          updates.
      Signed-off-by: 's avatarXiangliang Yu <yuxiangl@marvell.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      420df0f5
    • James Ralston's avatar
      ahci: Add Device IDs for Intel Wildcat Point-LP · 296cfdec
      James Ralston authored
      commit 9f961a5f6efc87a79571d7166257b36af28ffcfe upstream.
      
      This patch adds the AHCI-mode SATA Device IDs for the Intel Wildcat Point-LP PCH.
      Signed-off-by: 's avatarJames Ralston <james.d.ralston@intel.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      296cfdec
    • Shan Hai's avatar
      drivers/libata: Set max sector to 65535 for Slimtype DVD A DS8A9SH drive · 922b22ff
      Shan Hai authored
      commit 0523f037f65dba10191b0fa9c51266f90ba64630 upstream.
      
      The "Slimtype DVD A  DS8A9SH" drive locks up with following backtrace when
      the max sector is smaller than 65535 bytes, fix it by adding a quirk to set
      the max sector to 65535 bytes.
      
      INFO: task flush-11:0:663 blocked for more than 120 seconds.
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      flush-11:0    D 00000000ffff5ceb     0   663      2 0x00000000
       ffff88026d3b1710 0000000000000046 0000000000000001 0000000000000000
       ffff88026f2530c0 ffff88026d365860 ffff88026d3b16e0 ffffffff812ffd52
       ffff88026d4fd3d0 0000000100000001 ffff88026d3b16f0 ffff88026d3b1fd8
      Call Trace:
       [<ffffffff812ffd52>] ? cfq_may_queue+0x52/0xf0
       [<ffffffff81604338>] schedule+0x18/0x30
       [<ffffffff81604392>] io_schedule+0x42/0x60
       [<ffffffff812f22bb>] get_request_wait+0xeb/0x1f0
       [<ffffffff81065660>] ? autoremove_wake_function+0x0/0x40
       [<ffffffff812eb382>] ? elv_merge+0x42/0x210
       [<ffffffff812f26ae>] __make_request+0x8e/0x4e0
       [<ffffffff812f068e>] generic_make_request+0x21e/0x5e0
       [<ffffffff812f0aad>] submit_bio+0x5d/0xd0
       [<ffffffff81141422>] submit_bh+0xf2/0x130
       [<ffffffff8114474c>] __block_write_full_page+0x1dc/0x3a0
       [<ffffffff81143f60>] ? end_buffer_async_write+0x0/0x120
       [<ffffffff811474e0>] ? blkdev_get_block+0x0/0x70
       [<ffffffff811474e0>] ? blkdev_get_block+0x0/0x70
       [<ffffffff81143f60>] ? end_buffer_async_write+0x0/0x120
       [<ffffffff811449ee>] block_write_full_page_endio+0xde/0x100
       [<ffffffff81144a20>] block_write_full_page+0x10/0x20
       [<ffffffff81148703>] blkdev_writepage+0x13/0x20
       [<ffffffff810d7525>] __writepage+0x15/0x40
       [<ffffffff810d7c0f>] write_cache_pages+0x1cf/0x3e0
       [<ffffffff810d7510>] ? __writepage+0x0/0x40
       [<ffffffff810d7e42>] generic_writepages+0x22/0x30
       [<ffffffff810d7e6f>] do_writepages+0x1f/0x40
       [<ffffffff8113ae67>] writeback_single_inode+0xe7/0x3b0
       [<ffffffff8113b574>] writeback_sb_inodes+0x184/0x280
       [<ffffffff8113bedb>] writeback_inodes_wb+0x6b/0x1a0
       [<ffffffff8113c24b>] wb_writeback+0x23b/0x2a0
       [<ffffffff8113c42d>] wb_do_writeback+0x17d/0x190
       [<ffffffff8113c48b>] bdi_writeback_task+0x4b/0xe0
       [<ffffffff810e82a0>] ? bdi_start_fn+0x0/0x100
       [<ffffffff810e8321>] bdi_start_fn+0x81/0x100
       [<ffffffff810e82a0>] ? bdi_start_fn+0x0/0x100
       [<ffffffff8106522e>] kthread+0x8e/0xa0
       [<ffffffff81039274>] ? finish_task_switch+0x54/0xc0
       [<ffffffff81003334>] kernel_thread_helper+0x4/0x10
       [<ffffffff810651a0>] ? kthread+0x0/0xa0
       [<ffffffff81003330>] ? kernel_thread_helper+0x0/0x10
      
       The above trace was triggered by
         "dd if=/dev/zero of=/dev/sr0 bs=2048 count=32768"
      Signed-off-by: 's avatarShan Hai <shan.hai@windriver.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      922b22ff
    • Gwendal Grignou's avatar
      libata: Fix display of sata speed · 929742b8
      Gwendal Grignou authored
      commit 3e85c3ecbc520751324a191d23bb94873ed01b10 upstream.
      
      6.0 Gbps link speed was not decoded properly:
      speed was reported at 3.0 Gbps only.
      
      Tested: On a machine where libata reports 6.0 Gbps in
              /var/log/messages:
          ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
      
          Before:
          	cat /sys/class/ata_link/link1/sata_spd
          	3.0 Gbps
          After:
          	cat /sys/class/ata_link/link1/sata_spd
          	6.0 Gbps
      Signed-off-by: 's avatarGwendal Grignou <gwendal@google.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      929742b8
  13. 13 Nov, 2013 1 commit
  14. 29 Aug, 2013 2 commits
    • Terry Suereth's avatar
      libata: apply behavioral quirks to sil3826 PMP · 323d5a7b
      Terry Suereth authored
      commit 8ffff94d20b7eb446e848e0046107d51b17a20a8 upstream.
      
      Fixing support for the Silicon Image 3826 port multiplier, by applying
      to it the same quirks applied to the Silicon Image 3726.  Specifically
      fixes the repeated timeout/reset process which previously afflicted
      the 3726, as described from line 290.  Slightly based on notes from:
      
      https://bugzilla.redhat.com/show_bug.cgi?id=890237Signed-off-by: 's avatarTerry Suereth <terry.suereth@gmail.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      323d5a7b
    • Anthony Foiani's avatar
      sata_fsl: save irqs while coalescing · 2650a684
      Anthony Foiani authored
      commit 99bbdfa6bdcb4bdf5be914a48e9b46941bf30819 upstream.
      
      Before this patch, I was seeing the following lockdep splat on my
      MPC8315 (PPC32) target:
      
        [    9.086051] =================================
        [    9.090393] [ INFO: inconsistent lock state ]
        [    9.094744] 3.9.7-ajf-gc39503d #1 Not tainted
        [    9.099087] ---------------------------------
        [    9.103432] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
        [    9.109431] scsi_eh_1/39 [HC1[1]:SC0[0]:HE0:SE1] takes:
        [    9.114642]  (&(&host->lock)->rlock){?.+...}, at: [<c02f4168>] sata_fsl_interrupt+0x50/0x250
        [    9.123137] {HARDIRQ-ON-W} state was registered at:
        [    9.128004]   [<c006cdb8>] lock_acquire+0x90/0xf4
        [    9.132737]   [<c043ef04>] _raw_spin_lock+0x34/0x4c
        [    9.137645]   [<c02f3560>] fsl_sata_set_irq_coalescing+0x68/0x100
        [    9.143750]   [<c02f36a0>] sata_fsl_init_controller+0xa8/0xc0
        [    9.149505]   [<c02f3f10>] sata_fsl_probe+0x17c/0x2e8
        [    9.154568]   [<c02acc90>] driver_probe_device+0x90/0x248
        [    9.159987]   [<c02acf0c>] __driver_attach+0xc4/0xc8
        [    9.164964]   [<c02aae74>] bus_for_each_dev+0x5c/0xa8
        [    9.170028]   [<c02ac218>] bus_add_driver+0x100/0x26c
        [    9.175091]   [<c02ad638>] driver_register+0x88/0x198
        [    9.180155]   [<c0003a24>] do_one_initcall+0x58/0x1b4
        [    9.185226]   [<c05aeeac>] kernel_init_freeable+0x118/0x1c0
        [    9.190823]   [<c0004110>] kernel_init+0x18/0x108
        [    9.195542]   [<c000f6b8>] ret_from_kernel_thread+0x64/0x6c
        [    9.201142] irq event stamp: 160
        [    9.204366] hardirqs last  enabled at (159): [<c043f778>] _raw_spin_unlock_irq+0x30/0x50
        [    9.212469] hardirqs last disabled at (160): [<c000f414>] reenable_mmu+0x30/0x88
        [    9.219867] softirqs last  enabled at (144): [<c002ae5c>] __do_softirq+0x168/0x218
        [    9.227435] softirqs last disabled at (137): [<c002b0d4>] irq_exit+0xa8/0xb4
        [    9.234481]
        [    9.234481] other info that might help us debug this:
        [    9.240995]  Possible unsafe locking scenario:
        [    9.240995]
        [    9.246898]        CPU0
        [    9.249337]        ----
        [    9.251776]   lock(&(&host->lock)->rlock);
        [    9.255878]   <Interrupt>
        [    9.258492]     lock(&(&host->lock)->rlock);
        [    9.262765]
        [    9.262765]  *** DEADLOCK ***
        [    9.262765]
        [    9.268684] no locks held by scsi_eh_1/39.
        [    9.272767]
        [    9.272767] stack backtrace:
        [    9.277117] Call Trace:
        [    9.279589] [cfff9da0] [c0008504] show_stack+0x48/0x150 (unreliable)
        [    9.285972] [cfff9de0] [c0447d5c] print_usage_bug.part.35+0x268/0x27c
        [    9.292425] [cfff9e10] [c006ace4] mark_lock+0x2ac/0x658
        [    9.297660] [cfff9e40] [c006b7e4] __lock_acquire+0x754/0x1840
        [    9.303414] [cfff9ee0] [c006cdb8] lock_acquire+0x90/0xf4
        [    9.308745] [cfff9f20] [c043ef04] _raw_spin_lock+0x34/0x4c
        [    9.314250] [cfff9f30] [c02f4168] sata_fsl_interrupt+0x50/0x250
        [    9.320187] [cfff9f70] [c0079ff0] handle_irq_event_percpu+0x90/0x254
        [    9.326547] [cfff9fc0] [c007a1fc] handle_irq_event+0x48/0x78
        [    9.332220] [cfff9fe0] [c007c95c] handle_level_irq+0x9c/0x104
        [    9.337981] [cfff9ff0] [c000d978] call_handle_irq+0x18/0x28
        [    9.343568] [cc7139f0] [c000608c] do_IRQ+0xf0/0x1a8
        [    9.348464] [cc713a20] [c000fc8c] ret_from_except+0x0/0x14
        [    9.353983] --- Exception: 501 at _raw_spin_unlock_irq+0x40/0x50
        [    9.353983]     LR = _raw_spin_unlock_irq+0x30/0x50
        [    9.364839] [cc713af0] [c043db10] wait_for_common+0xac/0x188
        [    9.370513] [cc713b30] [c02ddee4] ata_exec_internal_sg+0x2b0/0x4f0
        [    9.376699] [cc713be0] [c02de18c] ata_exec_internal+0x68/0xa8
        [    9.382454] [cc713c20] [c02de4b8] ata_dev_read_id+0x158/0x594
        [    9.388205] [cc713ca0] [c02ec244] ata_eh_recover+0xd88/0x13d0
        [    9.393962] [cc713d20] [c02f2520] sata_pmp_error_handler+0xc0/0x8ac
        [    9.400234] [cc713dd0] [c02ecdc8] ata_scsi_port_error_handler+0x464/0x5e8
        [    9.407023] [cc713e10] [c02ecfd0] ata_scsi_error+0x84/0xb8
        [    9.412528] [cc713e40] [c02c4974] scsi_error_handler+0xd8/0x47c
        [    9.418457] [cc713eb0] [c004737c] kthread+0xa8/0xac
        [    9.423355] [cc713f40] [c000f6b8] ret_from_kernel_thread+0x64/0x6c
      
      This fix was suggested by Bhushan Bharat <R65777@freescale.com>, and
      was discussed in email at:
      
        http://linuxppc.10917.n7.nabble.com/MPC8315-reboot-failure-lockdep-splat-possibly-related-tp75162.html
      
      Same patch successfully tested with 3.9.7.  linux-next compiled but
      not tested on hardware.
      
      This patch is based off linux-next tag next-20130819
      (which is commit 66a01bae29d11916c09f9f5a937cafe7d402e4a5 )
      Signed-off-by: 's avatarAnthony Foiani <anthony.foiani@gmail.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2650a684
  15. 04 Aug, 2013 2 commits
  16. 25 Jul, 2013 4 commits
  17. 22 Jul, 2013 3 commits