mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-08 21:22:09 -04:00
No description
- C 98.2%
- Assembly 1%
- Makefile 0.3%
- Shell 0.2%
- Python 0.1%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
54d74e6b9d
In some cases, like while performing extensive expander reset or phy reset, user may observe that drives are not visible in OS. Driver's firmware-worker thread is blocked for more than 120 seconds resulting in a call trace. 1. Received target add event for Device A and hence driver has registered this device to SML by calling sas_rphy_add(). SML has half added this device and returned the control to the driver by quitting from sas_rphy_add() API, and started some background scanning on this device A. 2. While background scanning is going on device A, driver has received SAS DEVICE STATUS CHANGE EVENT with RC code "Internal device reset" event and hence driver has set tm_busy flag for this Device A from FW worker thread context. When tm_busy flag is set then driver return scsi commands with device busy status asking the kernel to retry the command after some time. So background scanning for device A will be waiting for this tm_busy to be cleared. 3. Meanwhile driver has received a target add event for Device B and hence driver called sas_rphy_add() API to register this device with SML. But since background scanning for Device A is still pending and SML is not quitting from sas_rphy_add(), the driver’s firmware worker thread got blocked. 4. Now driver has received SAS DEVICE STATUS CHANGE EVENT with RC code "Internal device reset complete" event. But as driver’s firmware worker thread got blocked in Step3, it can’t process this event and it was not clearing the tm_busy flag and deadlock occurred (where SML was waiting for tm_busy flag to be cleared and our FW worker thread is waiting for SML to quit from sas_device_rphy_add() API). Same deadlock will be observed even if device B is getting removed in step3. So to limit these types of deadlocks driver will process the SAS DEVICE STATUS CHANGE EVENT events from ISR context instead of processing this event from worker thread context. This improvement avoids above deadlock. Signed-off-by: Suganath Prabu <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> |
||
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.