All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: guennadi.liakhovetski@linux.intel.com,
	alsa-devel@alsa-project.org, kai.vehmanen@linux.intel.com,
	lgirdwood@gmail.com, pierre-louis.bossart@linux.intel.com,
	ranjani.sridharan@linux.intel.com
Subject: Re: [PATCH 00/19] ASoC: SOF: Improvements for debugging
Date: Thu, 7 Oct 2021 09:46:24 +0300	[thread overview]
Message-ID: <473a911b-2cdd-9cec-541b-aa392f9fb21a@linux.intel.com> (raw)
In-Reply-To: <YV2HIkZv9dmSmvts@sirena.org.uk>

Hi Mark,

my mail client dropped everyone except the list, resending with correct
TO/CC

On 06/10/2021 14:23, Mark Brown wrote:
> On Wed, Oct 06, 2021 at 02:06:26PM +0300, Peter Ujfalusi wrote:
>> Hi,
>>
>> The aim of this series is to clean up, make it easier to interpret and less
>> 'chatty' prints aimed for debugging errors.
>>
>> For example currently the DSP/IPC dump is printed every time we have an IPC
>> timeout and it is posible to lost the first and more indicative dump to find the
>> rootcause.
> 
> You might want to look at tracepoints and/or trace_printk, apart from
> anything else they're very useful for flight recorder style applications
> since they're very low overhead and have comparitively speeaking lots of
> storage available.

The trace infra is indeed a direction which would help on new hardware,
architecture bringup.

I should have used different subject for the cover letter as the end
result is to have better quality bug reports from users in the unlikely
event that something goes wrong (mostly on the firmware side).

To speed up the turnaround to get it fixed as the first report should
contain enough details to hint us where to look.

At the end the series will actually reduce the noise from dev_err() in
case of a failure by printing only needed information without repetition.


-- 
Péter

  parent reply	other threads:[~2021-10-07  6:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-06 11:06 [PATCH 00/19] ASoC: SOF: Improvements for debugging Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 01/19] ASoC: SOF: core: debug: force all processing on primary core Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 02/19] ASoC: SOF: debug: Swap the dsp_dump and ipc_dump sequence for fw_exception Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 03/19] ASoC: SOF: ipc and dsp dump: Add markers for better visibility Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 04/19] ASoC: SOF: Print the dbg_dump and ipc_dump once to reduce kernel log noise Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 05/19] ASoC: SOF: loader: Print the DSP dump if boot fails Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 06/19] ASoC: SOF: intel: atom: No need to do a DSP dump in atom_run() Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 07/19] ASoC: SOF: debug/ops: Move the IPC and DSP dump functions out from the header Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 08/19] ASoC: SOF: debug: Add SOF_DBG_DUMP_OPTIONAL flag for DSP dumping Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 09/19] ASoC: SOF: intel: hda-loader: Use snd_sof_dsp_dbg_dump() for DSP dump Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 10/19] ASoC: SOF: Drop SOF_DBG_DUMP_FORCE_ERR_LEVEL and sof_dev_dbg_or_err Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 11/19] ASoC: SOF: debug: Print out the fw_state along with the DSP dump Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 12/19] ASoC: SOF: ipc: Re-enable dumps after successful IPC tx Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 13/19] ASoC: SOF: ops: Force DSP panic dumps to be printed Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 14/19] ASoC: SOF: Introduce macro to set the firmware state Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 15/19] ASoC: SOF: intel: hda: Drop 'error' prefix from error dump functions Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 16/19] ASoC: SOF: core: Clean up snd_sof_get_status() prints Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 17/19] ASoC: SOF: loader: Drop SOF_DBG_DUMP_REGS flag when firmware start fails Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 18/19] ASoC: SOF: Intel: hda-loader: Drop SOF_DBG_DUMP_REGS flag from dbg_dump calls Peter Ujfalusi
2021-10-06 11:06 ` [PATCH 19/19] ASoC: SOF: Intel: hda: Dump registers and stack when SOF_DBG_DUMP_REGS is set Peter Ujfalusi
2021-10-06 11:23 ` [PATCH 00/19] ASoC: SOF: Improvements for debugging Mark Brown
2021-10-06 12:32   ` Pierre-Louis Bossart
2021-10-07  6:42   ` Péter Ujfalusi
2021-10-07  6:46   ` Péter Ujfalusi [this message]
2021-10-07 21:37 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=473a911b-2cdd-9cec-541b-aa392f9fb21a@linux.intel.com \
    --to=peter.ujfalusi@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=guennadi.liakhovetski@linux.intel.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.