Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 3月, 2014 1 次提交
    • J
      ata: Fix CS55xx dependencies · 9236a76d
      由 Jean Delvare 提交于 
      As far as I know, the CS5520 and CS5530 chipsets were only used with
32-bit x86 Geode processors, so I think their drivers are only needed
on this architecture, except for build testing purpose.

While we're here, simplify the dependencies for the CS5535 driver.

The CS5536 was used with the Geode processors, but also on MIPS
Loongson/Lemote 2 systems, so let its driver be built for these two
architectures only, except for build testing purpose.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
      9236a76d
  3. 08 3月, 2014 1 次提交
    • D
      libata: end the r-word · 35bf8821
      由 Dan Williams 提交于 
      Prompted by the social effort in the US to discourage usage of the
adjective "retarded".

In this case we needlessly anthropomorphize hard drives.  The
implication is that due to design deficiencies in the device reset
recovery time is negatively impacted.  We can simply clearly state that
fact.  "Exceptional devices cause outliers in reset recovery time." This
steers clear of any unintended comparison of such devices to humans with
cognitive disabilities.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
      35bf8821
  5. 07 3月, 2014 1 次提交
  7. 24 2月, 2014 1 次提交
  9. 23 2月, 2014 14 次提交
  11. 20 2月, 2014 2 次提交
  13. 19 2月, 2014 3 次提交
  15. 14 2月, 2014 1 次提交
  17. 20 1月, 2014 1 次提交
  19. 19 1月, 2014 1 次提交
  21. 16 1月, 2014 1 次提交
    • T
      libata: disable LPM for some WD SATA-I devices · ecd75ad5
      由 Tejun Heo 提交于 
      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: NTejun Heo <tj@kernel.org>
Reported-and-tested-by: NNikos Barkas <levelwol@gmail.com>
Reported-and-tested-by: NIoannis Barkas <risc4all@yahoo.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=57211
Cc: stable@vger.kernel.org
      ecd75ad5
  23. 15 1月, 2014 2 次提交
  25. 12 1月, 2014 1 次提交
  27. 04 1月, 2014 1 次提交
  29. 02 1月, 2014 3 次提交
  31. 31 12月, 2013 2 次提交
  33. 20 12月, 2013 1 次提交
    • T
      libata, freezer: avoid block device removal while system is frozen · 85fbd722
      由 Tejun Heo 提交于 
      Freezable kthreads and workqueues are fundamentally problematic in
that they effectively introduce a big kernel lock widely used in the
kernel and have already been the culprit of several deadlock
scenarios.  This is the latest occurrence.

During resume, libata rescans all the ports and revalidates all
pre-existing devices.  If it determines that a device has gone
missing, the device is removed from the system which involves
invalidating block device and flushing bdi while holding driver core
layer locks.  Unfortunately, this can race with the rest of device
resume.  Because freezable kthreads and workqueues are thawed after
device resume is complete and block device removal depends on
freezable workqueues and kthreads (e.g. bdi_wq, jbd2) to make
progress, this can lead to deadlock - block device removal can't
proceed because kthreads are frozen and kthreads can't be thawed
because device resume is blocked behind block device removal.

839a8e86 ("writeback: replace custom worker pool implementation
with unbound workqueue") made this particular deadlock scenario more
visible but the underlying problem has always been there - the
original forker task and jbd2 are freezable too.  In fact, this is
highly likely just one of many possible deadlock scenarios given that
freezer behaves as a big kernel lock and we don't have any debug
mechanism around it.

I believe the right thing to do is getting rid of freezable kthreads
and workqueues.  This is something fundamentally broken.  For now,
implement a funny workaround in libata - just avoid doing block device
hot[un]plug while the system is frozen.  Kernel engineering at its
finest.  :(

v2: Add EXPORT_SYMBOL_GPL(pm_freezing) for cases where libata is built
    as a module.

v3: Comment updated and polling interval changed to 10ms as suggested
    by Rafael.

v4: Add #ifdef CONFIG_FREEZER around the hack as pm_freezing is not
    defined when FREEZER is not configured thus breaking build.
    Reported by kbuild test robot.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NTomaž Šolc <tomaz.solc@tablix.org>
Reviewed-by: N"Rafael J. Wysocki" <rjw@rjwysocki.net>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=62801
Link: http://lkml.kernel.org/r/20131213174932.GA27070@htj.dyndns.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: stable@vger.kernel.org
Cc: kbuild test robot <fengguang.wu@intel.com>
      85fbd722
  35. 17 12月, 2013 2 次提交
  37. 16 12月, 2013 1 次提交
    • P
      ahci: bail out on ICH6 before using AHCI BAR · 6fec8871
      由 Paul Bolle 提交于 
      The check for "combined mode" (which disables ahci support) on ICH6 is
done after the first use of AHCI BAR. But if ahci is not enabled AHCI
BAR is initialized to 0x00000000. (At least it is on the ICH6-M I tested
this on. If I understand the datasheet correctly it should also be on
ICH6R.) This apparently makes the call of
pcim_iomap_regions_request_all() return -EINVAL. And we end up with
    ahci: probe of 0000:00:1f.2 failed with error -22

(at warning level) in the logs.

So check for "combined mode" before calling
pcim_iomap_regions_request_all().
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NTejun Heo <tj@kernel.org>
      6fec8871