All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 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: default avatarDirk Griesbach <>
      Signed-off-by: default avatarAaron Lu <>
      Acked-by: default avatarTejun Heo <>
      Cc: 3.6+ <>
      Signed-off-by: default avatarRafael J. Wysocki <>
  2. 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 <> on linux-ide:
      tj: minor formatting changes.
      Signed-off-by: default avatarVincent Pelletier <>
      Signed-off-by: default avatarTejun Heo <>
  3. 14 May, 2013 1 commit
  4. 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: default avatarDavid Woodhouse <>
      Signed-off-by: default avatarJeff Garzik <>
    • 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.
      Signed-off-by: default avatarShan Hai <>
      Signed-off-by: default avatarJeff Garzik <>
  5. 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: default avatarAaron Lu <>
      Signed-off-by: default avatarJeff Garzik <>
    • 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: default avatarAaron Lu <>
      Signed-off-by: default avatarJeff Garzik <>
    • Jeff Garzik's avatar
      Revert "libata: export host controller number thru /sys" · e175435e
      Jeff Garzik authored
      This reverts commit 1757d902.
      Discussion continues upstream.
  6. 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: default avatarAaron Lu <>
      Acked-by: default avatarTejun Heo <>
      Signed-off-by: default avatarJeff Garzik <>
    • 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: default avatarAaron Lu <>
      Acked-by: default avatarTejun Heo <>
      Signed-off-by: default avatarJeff Garzik <>
  7. 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: default avatarDavid Milburn <>
      Signed-off-by: default avatarJeff Garzik <>
    • 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 default avatarBorislav Petkov <>
      Signed-off-by: default avatarShane Huang <>
      Signed-off-by: default avatarJeff Garzik <>
  8. 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: default avatarJeff Garzik <>
  9. 03 Dec, 2012 4 commits
  10. 15 Nov, 2012 1 commit
  11. 12 Sep, 2012 4 commits
  12. 25 Aug, 2012 1 commit
  13. 24 Aug, 2012 3 commits
  14. 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: default avatarZheng Liu <>
      Signed-off-by: default avatarJeff Garzik <>
    • 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: default avatarMichael Eitelwein <>
      Signed-off-by: default avatarJeff Garzik <>
  15. 25 Jul, 2012 1 commit
  16. 20 Jul, 2012 1 commit
  17. 29 Jun, 2012 3 commits
  18. 22 May, 2012 1 commit
    • Prarit Bhargava's avatar
      [libata] Add " 2GB ATA Flash Disk"/"ADMA428M" to DMA blacklist · d70e551c
      Prarit Bhargava authored
      A user has several systems with a couple of models of flash disks with IDE
      connectors.  These disks work fine in 2.6.18-ish kernels but corrupt data on
      new kernels.
      The difference appears to be with the default I/O method used by the IDE
      controller driver between the kernels.  In the older kernels, the
      configuration is very conservative and the driver stays in PIO mode.  With
      new kernels, the ata driver (pata_serverworks) attempts to use UDMA/66
      which the drive claims to support.  This mode, however, does not appear to
      work in DMA mode.  The drive does work correctly and no corruption is
      seen if the kernel parameter "libata.force=5:pio0,6:pio0" is used to force
      the driver to use PIO instead of DMA mode.
      Blacklist these drives.  Unfortunately the model name of the drive is very
      generic, " 2GB ATA Flash Disk", but the revision is specific, "ADMA428M".
      Signed-off-by: default avatarPrarit Bhargava <>
      Signed-off-by: default avatarJeff Garzik <>
  19. 07 May, 2012 1 commit
  20. 03 May, 2012 1 commit
    • Tero Roponen's avatar
      libata: init ata_print_id to 0 · a78f57af
      Tero Roponen authored
      When comparing the dmesg between 3.4-rc3 and 3.4-rc4 I found the
      following differences:
       -ata1: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff100 irq 47
       -ata2: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff180 irq 47
       -ata3: DUMMY
       +ata2: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff100 irq 47
       +ata3: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff180 irq 47
        ata4: DUMMY
        ata5: DUMMY
       -ata6: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff380 irq 47
       +ata6: DUMMY
       +ata7: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff380 irq 47
      The change of numbering comes from commit 85d6725b ("libata:
      make ata_print_id atomic") that changed lines like
      	ap->print_id = ata_print_id++;
      	ap->print_id = atomic_inc_return(&ata_print_id);
      As the latter behaves like ++ata_print_id, we must initialize
      it to zero to start the numbering from one.
      Signed-off-by: default avatarTero Roponen <>
      Acked-by: default avatarDan Williams <>
      Signed-off-by: default avatarJeff Garzik <>
  21. 12 Apr, 2012 1 commit
  22. 29 Feb, 2012 1 commit
  23. 17 Jan, 2012 1 commit
  24. 08 Jan, 2012 1 commit