# Debug UFS issues

Source: [https://docs.qualcomm.com/doc/80-70014-6/topic/debug_ufs.html](https://docs.qualcomm.com/doc/80-70014-6/topic/debug_ufs.html)

This section describes how to debug different UFS issues.

## UFS device issue

When a UFS device issue occurs *cmd pending in the device* or *no response                    from device* error log recorded in the kernel log as shown below. 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

## PA/DL error

In the kernel log, when we see *pa\_err\_cnt\_total* and *dl\_err\_cnt\_total* as
                non-zero then we can consider this as a PA/DL error issue. This issue indicates that
                the signal quality between the SoC and the UFS device is not strong. Typically,
                resolving such issues involves collaboration among hardware, software, and the UFS
                vendor.

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/debugCopy 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

This section explains the debug steps
                to troubleshoot excess power consumption issues due to active/sleep power states.

**Active state**

During active state, if UFS power consumption
                is high, use the following steps to debug.

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_freqCopy 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 using the following ssh command on the
                    host
                    machine:

        #cat /sys/devices/platform/soc@0/1d84000.ufs/clkscale_enableCopy to clipboard
4. Check the UFS clocks frequency and UFS rails at the point of issue.
5. The issue may occur after device bootup due to initial configuration or during
                    suspend/resume 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 it causes
                    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

**Parent Topic:** [Debug](https://docs.qualcomm.com/doc/80-70014-6/topic/troubleshooting.html)

Last Published: Jul 10, 2024

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