This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux: Issues - General guidelines for better issue description and providing logs

Tool/software: Linux

A problem well described is a problem well understood.

Lack of information demands unnecessary communication thereby delaying actual debug of the problem and costs time for both sides.

Here's a simple guideline for better describing issues and reducing delays in resolution.

It's just a template and all steps may not be required or applicable for every issue.

I hope below six step guideline or parts of it, as necessary, will help save everyone's time and efforts.

1. Post title 

    • <Platform:driver name: one line statement> [ex: AM572x: eMMC: command timeout error during write to card]

2.  HW description

    • SoC [AM5728, AM3352, DRA7XX etc] & PG - Rev 1.0, 2.0 etc

    • TI EVM or a custom board, IF TI EVM which Rev (A< B, G etc) or variant (IDK, uEVM etc)

    • Relevant device info - PMIC, DDR, CAM, DISPLAY, ETH card, PCIE card, et

3.  SW description

    • SDK version, Kernel and U-boot version

    • Custom bootloader vs SDK bootloader

    • Application, middle ware, frameworks used

    • additional patches/changes done on top of an SDK

4.  Problem Scenario

    • Describe the usecase and components involved

    • Events leading to the issue

    • Time taken to issue reproduction and Frequency of reproduction

    • If it's on a custom board, has it been tried on a TI HW?

5.  Relevant logs

    • Usually - full boot log leading upto the issu

    • At least complete issue signature when it's not feasible to share entire boot log

    • Check for debug options - ex: setting "loglevel=7", "earlyprintk" in bootargs, enabling driver specific debug "CONFIG_PM_DEBUG" or "CONFIG_MMC_DEBUG", etc.

6.  Attach relevant collaterals

    • share device tree source (dts/dtsi) files if modified or using a custom board

    • system block diagram for system level problems involving more than just kernel drivers

    • A standlone application/test case to reproduce issue when required

Regards,

RK