# Debug UFS issues

## UFS device issue

When a UFS device issue occurs, `cmd pending in the device` or `no response from device` will be recorded in the kernel log. Check with the UFS vendor for more information if this issue occurs.

Example 1:

[ 82.928056][01-01 00:02:05] ufshcd-qcom 1d84000.ufshc: ufshcd_abort: Device abort task at tag 1
    [ 82.928059][01-01 00:02:05] sd 0:0:0:4: [sde] tag#1 CDB: Read(10) 28 00 00 00 44 49 00 00 20 00
    [ 82.936477][01-01 00:02:05] ufshcd-qcom 1d84000.ufshc: UPIU[1] - issue time 50955434 us
    [ 82.936479][01-01 00:02:05] ufshcd-qcom 1d84000.ufshc: UPIU[1] - complete time 0 us
    [ 82.936567][01-01 00:02:05] ufshcd-qcom 1d84000.ufshc: ufshcd_abort: cmd pending in the device. tag = 1
    Copy to clipboard

Example 2 :

[ 1036.008147] [1230_22:00:49]@0 ufshcd-qcom 1d84000.ufshc: ufshcd_abort: Device abort task at tag 2
    [ 1036.008510] [1230_22:00:49]@0 sd 0:0:0:0: tag#2 CDB: opcode=0xfa (vendor) fa 02 01 48 07 79 ae 03 50 00
    [ 1036.120287] [1230_22:00:50]@1 ufshcd-qcom 1d84000.ufshc: ufshcd_abort: no response from device. tag = 2, err -110.
    Copy to clipboard

## Physical adaptor/data link error

In the kernel log, when we see <cite>pa_err_cnt_total</cite> and <cite>dl_err_cnt_total</cite> as non-zero, then we can consider these as a physical adaptor/Data link (PA/DL) error issue.
This issue indicates that the signal quality between the AP and the UFS device is not strong. This type of issue generally requires hardware, software, and the UFS vendor to solve.

Use the debugfs path `/sys/kernel/debug/ufshcd/1d84000.ufs/stats` to see the PA/DL error count.

debugfs should be mounted using the following command. This command will make the debugfs filesystem accessible for debug nodes.

mount -t debugfs none /sys/kernel/debug
    Copy to clipboard

Example:

[31709.438001] ufshcd-qcom 1d84000.ufshc: pa_err_cnt_total=5086, pa_lane_0_err_cnt=3250, pa_lane_1_err_cnt=1405, pa_line_reset_err_cnt=431
    [31709.438008] ufshcd-qcom 1d84000.ufshc: dl_err_cnt_total=4488, dl_nac_received_err_cnt=289, dl_tcx_replay_timer_expired_err_cnt=258
    [31709.438015] ufshcd-qcom 1d84000.ufshc: dl_afcx_request_timer_expired_err_cnt=0, dl_fcx_protection_timer_expired_err_cnt=0, dl_crc_err_cnt=18
    Copy to clipboard

## UFS power consumptions issue

Excess power consumption could be due to active/sleep power states.

- **Active state**

    Use the following steps to debug UFS high power consumption during active state.

    1. Check how often the issue occurs. Use the following ssh command to check current clock frequency:

# cat /sys/devices/platform/soc@0/1d84000.ufs/devfreq/1d84000.ufs/cur_freq
            Copy to clipboard

        If the frequency is maximum, skip to Step 3.
    2. Check whether any UFS-related feature (such as WriteBooster) has been enabled.
    3. Check whether clock scale is disabled.

#cat /sys/devices/platform/soc@0/1d84000.ufs/clkscale_enable
            Copy to clipboard
    4. Monitor the UFS clocks frequency and UFS rails.

        The issue may occur due to the initial setting or due to an unexpected devfreq event.
- **Sleep state**

    During sleep state, if UFS power consumption is high, use the following steps to debug UFS suspend-related issues.

    1. Check the power management state using sysfs nodes `link_state`, `curr_freq`, and `runtime_status` and PM level (`PM_LVL` 3 has higher power consumption than 5).
    2. Check the UFS state using sysfs node `dev_pm` to determine whether UFS is in sleep mode.
    3. Check whether the HPB and write booster features are enabled because they cause high power consumption.
    4. Check the UFS VCC/VCCQ/VCCQ2 timing from the hardware side if an issue occurs.

## Disable UFS SMMU

System Memory Management Unit (SMMU) is a memory management unit (MMU) that connects a direct-memory-access–capable (DMA-capable) I/O bus to the physical memory.

Each device is assigned a unique stream ID (SID). UFS controller SID is 0x80 on this platform.

If there is an unhandled SMMU fault from UFS SMMU as shown in the log below, then UFS SMMU can be disabled.

arm-smmu 15000000.apps-smmu: Unhandled arm-smmu context fault from 1d84000.ufshc!
    Copy to clipboard

UFS SMMU can be disabled with the following change in `ufshc_mem` node in `<workspace_root_path>/sources/kernel/kernel_platform/kernel/arch/arm64/boot/dts/qcom/sc7280.dtsi` file.

-   qcom,iommu-dma = "fastmap";
    +   qcom,iommu-dma = "bypass";
    Copy to clipboard

Last Published: Oct 02, 2024

[Previous Topic
Debug](https://docs.qualcomm.com/bundle/publicresource/80-70015-6/topics/debug.md) [Next Topic
Debugging with sysfs or debugfs nodes](https://docs.qualcomm.com/bundle/publicresource/80-70015-6/topics/ufs-sysfs-debugfs.md)