[GITLAB] - UPGRADE TO v12 on Wednesday the 18th of December at 11.30AM

  1. 06 Jun, 2015 2 commits
  2. 31 Jul, 2014 2 commits
    • 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
        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>
    • 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>
  3. 07 Jun, 2014 1 commit
  4. 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:
      	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>
  5. 24 Mar, 2014 1 commit
  6. 06 Feb, 2014 1 commit
    • 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>
  7. 09 Jan, 2014 3 commits
  8. 04 Dec, 2013 1 commit
    • 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>
  9. 24 Jun, 2013 1 commit
    • Aaron Lu's avatar
      libata-acpi: add back ACPI based hotplug functionality · 44521527
      Aaron Lu authored
      Commit 30dcf76a "libata: migrate ACPI code over to new bindings"
      mistakenly dropped the code to register hotplug notificaion handler
      for ATA port/devices, causing regression for people using ATA bay,
      as kernel bug #59871 shows.
      Fix this by adding back the hotplug notification handler registration
      code.  Since this code has to be run once and notification needs to
      be installed on every ATA port/devices handle no matter if there is
      actual device attached, we can't do this in binding time for ATA
      device ACPI handle, as the binding only occurs when a SCSI device is
      created, i.e. there is device attached.  So introduce the
      ata_acpi_hotplug_init() function to loop scan all ATA ACPI handles
      and if it is available, install the notificaion handler for it during
      ATA init time.
      With the ATA ACPI handle binding to SCSI device tree, it is possible
      now that when the SCSI hotplug work removes the SCSI device, the ACPI
      unbind function will find that the corresponding ACPI device has
      already been deleted by dock driver, causing a scaring message like:
      [  128.263966] scsi 4:0:0:0: Oops, 'acpi_handle' corrupt
      Fix this by waiting for SCSI hotplug task finish in our notificaion
      handler, so that the removal of ACPI device done in ACPI unbind
      function triggered by the removal of SCSI device is run earlier when
      ACPI device is still available.
      [rjw: Rebased]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=59871Reported-bisected-and-tested-by: 's avatarDirk Griesbach <spamthis@freenet.de>
      Signed-off-by: 's avatarAaron Lu <aaron.lu@intel.com>
      Acked-by: 's avatarTejun Heo <tj@kernel.org>
      Cc: 3.6+ <stable@vger.kernel.org>
      Signed-off-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  10. 21 May, 2013 1 commit
    • Vincent Pelletier's avatar
      libata: make ata_exec_internal_sg honor DMADIR · e771451c
      Vincent Pelletier authored
      libata honors DMADIR for regular commands, but not for internal commands
      used (among other) during device initialisation.
      This makes SATA-host-to-PATA-device bridges based on Silicon Image SiL3611
      (such as "Abit Serillel 2") end up disabled when used with an ATAPI device
      after a few tries.
      Log output of the bridge being hot-plugged with an ATAPI drive:
        [ 9631.212901] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen
        [ 9631.212913] ata1: irq_stat 0x00000040, connection status changed
        [ 9631.212923] ata1: SError: { CommWake 10B8B DevExch }
        [ 9631.212939] ata1: hard resetting link
        [ 9632.104962] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
        [ 9632.106393] ata1.00: ATAPI: PIONEER DVD-RW  DVR-115, 1.06, max UDMA/33
        [ 9632.106407] ata1.00: applying bridge limits
        [ 9632.108151] ata1.00: configured for UDMA/33
        [ 9637.105303] ata1.00: qc timeout (cmd 0xa0)
        [ 9637.105324] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
        [ 9637.105335] ata1: hard resetting link
        [ 9638.044599] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
        [ 9638.047878] ata1.00: configured for UDMA/33
        [ 9643.044933] ata1.00: qc timeout (cmd 0xa0)
        [ 9643.044953] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
        [ 9643.044963] ata1: limiting SATA link speed to 1.5 Gbps
        [ 9643.044971] ata1.00: limiting speed to UDMA/33:PIO3
        [ 9643.044979] ata1: hard resetting link
        [ 9643.984225] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
        [ 9643.987471] ata1.00: configured for UDMA/33
        [ 9648.984591] ata1.00: qc timeout (cmd 0xa0)
        [ 9648.984612] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
        [ 9648.984619] ata1.00: disabled
        [ 9649.000593] ata1: hard resetting link
        [ 9649.939902] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
        [ 9649.955864] ata1: EH complete
      With this patch, the drive enumerates correctly when libata is loaded with
        [ 9891.810863] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen
        [ 9891.810874] ata1: irq_stat 0x00000040, connection status changed
        [ 9891.810884] ata1: SError: { CommWake 10B8B DevExch }
        [ 9891.810900] ata1: hard resetting link
        [ 9892.762105] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
        [ 9892.763544] ata1.00: ATAPI: PIONEER DVD-RW  DVR-115, 1.06, max UDMA/33, DMADIR
        [ 9892.763558] ata1.00: applying bridge limits
        [ 9892.765393] ata1.00: configured for UDMA/33
        [ 9892.786063] ata1: EH complete
        [ 9892.792062] scsi 0:0:0:0: CD-ROM            PIONEER  DVD-RW  DVR-115  1.06 PQ: 0 ANSI: 5
        [ 9892.798455] sr2: scsi3-mmc drive: 12x/12x writer dvd-ram cd/rw xa/form2 cdda tray
        [ 9892.798837] sr 0:0:0:0: Attached scsi CD-ROM sr2
        [ 9892.799109] sr 0:0:0:0: Attached scsi generic sg6 type 5
      Based on a patch by Csaba Halász <csaba.halasz@gmail.com> on linux-ide:
      tj: minor formatting changes.
      Signed-off-by: 's avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org
  11. 14 May, 2013 1 commit
  12. 03 Apr, 2013 2 commits
    • David Woodhouse's avatar
      libata: fix DMA to stack in reading devslp_timing parameters · 8e725c7f
      David Woodhouse authored
      Commit 803739d2 ("[libata] replace
      sata_settings with devslp_timing"), which was also Cc: stable, used a
      stack buffer to receive data from ata_read_log_page(), which triggers
      the following warning:
       ahci 0000:00:1f.2: DMA-API: device driver maps memory fromstack [addr=ffff880140469948]
      Fix this by using ap->sector_buf instead of a stack buffer.
      Signed-off-by: 's avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
    • Shan Hai's avatar
      libata: Set max sector to 65535 for Slimtype DVD A DS8A8SH drive · a32450e1
      Shan Hai authored
      The Slimtype DVD A  DS8A8SH drive locks up when max sector is smaller than
      65535, and the blow backtrace is observed on locking up:
      INFO: task flush-8:32:1130 blocked for more than 120 seconds.
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      flush-8:32      D ffffffff8180cf60     0  1130      2 0x00000000
       ffff880273aef618 0000000000000046 0000000000000005 ffff880273aee000
       ffff880273aee000 ffff880273aeffd8 ffff880273aee010 ffff880273aee000
       ffff880273aeffd8 ffff880273aee000 ffff88026e842ea0 ffff880274a10000
      Call Trace:
       [<ffffffff8168fc2d>] schedule+0x5d/0x70
       [<ffffffff8168fccc>] io_schedule+0x8c/0xd0
       [<ffffffff81324461>] get_request+0x731/0x7d0
       [<ffffffff8133dc60>] ? cfq_allow_merge+0x50/0x90
       [<ffffffff81083aa0>] ? wake_up_bit+0x40/0x40
       [<ffffffff81320443>] ? bio_attempt_back_merge+0x33/0x110
       [<ffffffff813248ea>] blk_queue_bio+0x23a/0x3f0
       [<ffffffff81322176>] generic_make_request+0xc6/0x120
       [<ffffffff81322308>] submit_bio+0x138/0x160
       [<ffffffff811d7596>] ? bio_alloc_bioset+0x96/0x120
       [<ffffffff811d1f61>] submit_bh+0x1f1/0x220
       [<ffffffff811d48b8>] __block_write_full_page+0x228/0x340
       [<ffffffff811d3650>] ? attach_nobh_buffers+0xc0/0xc0
       [<ffffffff811d8960>] ? I_BDEV+0x10/0x10
       [<ffffffff811d8960>] ? I_BDEV+0x10/0x10
       [<ffffffff811d4ab6>] block_write_full_page_endio+0xe6/0x100
       [<ffffffff811d4ae5>] block_write_full_page+0x15/0x20
       [<ffffffff811d9268>] blkdev_writepage+0x18/0x20
       [<ffffffff81142527>] __writepage+0x17/0x40
       [<ffffffff811438ba>] write_cache_pages+0x34a/0x4a0
       [<ffffffff81142510>] ? set_page_dirty+0x70/0x70
       [<ffffffff81143a61>] generic_writepages+0x51/0x80
       [<ffffffff81143ab0>] do_writepages+0x20/0x50
       [<ffffffff811c9ed6>] __writeback_single_inode+0xa6/0x2b0
       [<ffffffff811ca861>] writeback_sb_inodes+0x311/0x4d0
       [<ffffffff811caaa6>] __writeback_inodes_wb+0x86/0xd0
       [<ffffffff811cad43>] wb_writeback+0x1a3/0x330
       [<ffffffff816916cf>] ? _raw_spin_lock_irqsave+0x3f/0x50
       [<ffffffff811b8362>] ? get_nr_inodes+0x52/0x70
       [<ffffffff811cb0ac>] wb_do_writeback+0x1dc/0x260
       [<ffffffff8168dd34>] ? schedule_timeout+0x204/0x240
       [<ffffffff811cb232>] bdi_writeback_thread+0x102/0x2b0
       [<ffffffff811cb130>] ? wb_do_writeback+0x260/0x260
       [<ffffffff81083550>] kthread+0xc0/0xd0
       [<ffffffff81083490>] ? kthread_worker_fn+0x1b0/0x1b0
       [<ffffffff8169a3ec>] ret_from_fork+0x7c/0xb0
       [<ffffffff81083490>] ? kthread_worker_fn+0x1b0/0x1b0
       The above trace was triggered by
         "dd if=/dev/zero of=/dev/sr0 bs=2048 count=32768"
       It was previously working by accident, since another bug introduced
       by 4dce8ba9 (libata: Use 'bool' return value for ata_id_XXX) caused
       all drives to use maxsect=65535.
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarShan Hai <shan.hai@windriver.com>
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
  13. 25 Jan, 2013 3 commits
    • Aaron Lu's avatar
      [libata] PM code cleanup for ata port · f5e6d0d0
      Aaron Lu authored
      For system freeze, if the port is already runtime suspended, leave it
      alone and just return. The port will be resumed on thaw before it will
      be used.
      And since we will call get_noresume for every device during prepare
      phase, and the port is resumed during thaw phase, it can't be in runtime
      suspended state during the poweroff phase. So remove the
      runtime_suspended check in poweroff callback.
      And for all suspend(freeze/suspend/poweroff/etc.), there is no need to
      touch the device, so set no_autopsy and no_recovery for them all.
      Signed-off-by: 's avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
    • Aaron Lu's avatar
      [libata] pm: differentiate system and runtime pm for ata port · a7ff60db
      Aaron Lu authored
      We need to do different things for system PM and runtime PM, e.g. we do
      not need to enable runtime wake for ZPODD when we are doing system
      suspend, etc.
      Currently, we use PMSG_SUSPEND for both system suspend and runtime
      suspend and PMSG_ON for both system resume and runtime resume. Change
      this by using PMSG_AUTO_SUSPEND for runtime suspend and PMSG_AUTO_RESUME
      for runtime resume. And since PMSG_ON means no transition, it is changed
      to PMSG_RESUME for ata port's system resume.
      The ata_acpi_set_state is modified accordingly, and the sata case and
      pata case is seperated for easy reading.
      Signed-off-by: 's avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
    • Jeff Garzik's avatar
      Revert "libata: export host controller number thru /sys" · e175435e
      Jeff Garzik authored
      This reverts commit 1757d902.
      Discussion continues upstream.
  14. 21 Jan, 2013 2 commits
    • Aaron Lu's avatar
      libata: do not suspend port if normal ODD is attached · 7e15e9be
      Aaron Lu authored
      For ODDs, the upper layer will poll for media change every few
      seconds, which will make it enter and leave suspend state very
      often. And as each suspend will also cause a hard/soft reset,
      the gain of runtime suspend is very little while the ODD may
      malfunction after constantly being reset. So the idle callback
      here will not proceed to suspend if a non-ZPODD capable ODD is
      attached to the port.
      Signed-off-by: 's avatarAaron Lu <aaron.lu@intel.com>
      Acked-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
    • Aaron Lu's avatar
      libata: identify and init ZPODD devices · afe75951
      Aaron Lu authored
      The ODD can be enabled for ZPODD if the following three conditions are
      1 The ODD supports device attention;
      2 The platform can runtime power off the ODD through ACPI;
      3 The ODD is either slot type or drawer type.
      For such ODDs, zpodd_init is called and a new structure is allocated for
      it to store ZPODD related stuffs.
      And the zpodd_dev_enabled function is used to test if ZPODD is currently
      enabled for this ODD.
      A new config CONFIG_SATA_ZPODD is added to selectively build ZPODD code.
      Signed-off-by: 's avatarAaron Lu <aaron.lu@intel.com>
      Acked-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
  15. 14 Jan, 2013 2 commits
    • David Milburn's avatar
      libata: export host controller number thru /sys · 1757d902
      David Milburn authored
      As low-level drivers register their host controller(s), keep track
      of the number of controllers and export thru /sys in a <host.port>
      format so that udev can better match up port numbers with a
      specific controller.
      # pwd
      # find . -name 'ata*' -print
      (2nd controller with port multiplier attached)
      (1st controller)
      Signed-off-by: 's avatarDavid Milburn <dmilburn@redhat.com>
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
    • Shane Huang's avatar
      [libata] replace sata_settings with devslp_timing · 803739d2
      Shane Huang authored
      NCQ capability was used to check availability of SATA Settings page
      from Identify Device Data Log, which contains DevSlp timing variables.
      It does not work on some HDDs and leads to error messages.
      IDENTIFY word 78 bit 5(Hardware Feature Control) can't work either
      because it is only the sufficient condition of Identify Device data
      log, not the necessary condition.
      This patch replaced ata_device->sata_settings with ->devslp_timing
      to only save DevSlp timing variables(8 bytes), instead of the whole
      SATA Settings page(512 bytes).
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=51881Reported-by: 's avatarBorislav Petkov <bp@alien8.de>
      Signed-off-by: 's avatarShane Huang <shane.huang@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
  16. 14 Dec, 2012 1 commit
    • Jeff Garzik's avatar
      Revert "libata: check SATA_SETTINGS log with HW Feature Ctrl" · 8349e5ae
      Jeff Garzik authored
      This reverts commit de90cd71.
      Shane Huang writes:
        Please suspend this patch because I just received two new
        DevSlp drives but found word 78 bit 5 is _not_ set.
        I'm checking with the drive vendor whether he gave me
        the wrong information. If bit 5 is not the necessary and
        sufficient condition, I will implement another patch to
        replace ata_device->sata_settings into ->devslp_timing.
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
  17. 03 Dec, 2012 4 commits
  18. 16 Nov, 2012 1 commit
  19. 13 Sep, 2012 4 commits
  20. 25 Aug, 2012 1 commit
  21. 24 Aug, 2012 3 commits
  22. 17 Aug, 2012 2 commits
    • Zheng Liu's avatar
      libata: enable SATA disk fua detection on default · 91895b78
      Zheng Liu authored
      Currently, SATA disk fua detection is disabled on default because most of
      devices don't support this feature at that time.  With the development of
      technology, more and more SATA disks support this feature.  So now we can enable
      this detection on default.
      Although fua detection is defined as a kernel module parameter, it is too hard
      to set its value because it must be loaded and set before system starts up.
      That needs to modify initrd file.  So it is inconvenient for administrator who
      needs to manage a huge number of servers.
      Signed-off-by: 's avatarZheng Liu <wenqing.lz@taobao.com>
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>
    • Jeff Garzik's avatar
      [libata] new quirk, lift bridge limits for Buffalo DriveStation Quattro · 04d0f1b8
      Jeff Garzik authored
      Michael Eitelwein writes:
      I have an external SATA drive that was slowed down by bridge limits. I
      found a solution in a thread on this list posted in 2008: It introduces
      whitelist entries in libata-core.c for devices with well working bridges
      (e.g. email on Fri, 31 Oct 2008 01:45:27 -0400).
      I added my device to this whitelist in a custom built kernel and it
      works fine for weeks now. How can I have this device added on the
      whitelist within the official kernel? Is this whitelist mechanism still
      supported or is there a smarter way to achieve whitelisting?
      I added the following whitelist entry for my Buffalo DriveStation
      Quattro "BUFFALO HD-QSU2/R5":
              /* Devices that do not need bridging limits applied */
              { "MTRON MSP-SATA*",            NULL,   ATA_HORKAGE_BRIDGE_OK, },
              { "BUFFALO HD-QSU2/R5",         NULL,   ATA_HORKAGE_BRIDGE_OK, },
      Reported-by: 's avatarMichael Eitelwein <michael@eitelwein.net>
      Signed-off-by: 's avatarJeff Garzik <jgarzik@redhat.com>