All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Michal Kazior <michal.kazior@tieto.com>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [PATCH v5] ath10k: save firmware debug log messages.
Date: Tue, 02 Sep 2014 09:03:57 -0700	[thread overview]
Message-ID: <5405EA6D.2040803@candelatech.com> (raw)
In-Reply-To: <87y4u2ksl1.fsf@kamboji.qca.qualcomm.com>

On 09/02/2014 07:25 AM, Kalle Valo wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
> 
>> On 2 September 2014 15:38, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>>> (Dropping linux-wireless)
>>>
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> They may be dumped through the firmware dump debugfs
>>>> file.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>
>>> Before I start looking at this in detail: this looks fragile and
>>> complicated from ath10k point of view. Why not just take a dump of the
>>> whole firmware memory and postprocess this, with whatever else we might
>>> need from the firmware? That's a lot easier to maintain.
>>
>> I like the idea although it still makes sense to keep some sort of a
>> circular buffer for the debug mesg events delivered via wmi, does it
>> not?
> 
> How would ath10k use those stored debug mesg events? Attach them to the
> firmare crash dump file? Or did you have something else in mind?

It can log them to /var/log/messages as hex for ongoing firmware logging.
It can allow dumping snapshots through debugfs for similar reasons.
Using the above, it can allow firmware devs to insert the equivalent of printf in their
firmware around crash sites and get some debug info in the logs to
aid debugging firmware crashes or other strange things w/out having
a serial console attached to the ath10k NIC.  That is how I debug and fix
crashes in firmware that are not obvious from the initial dump.
Surely your firmware guys could use similar tools.

You have no guarantee when debug log messages are delivered to the host,
so without storing them as received from the target, you may not have anything
useful to dump/decode at crash time.

> But most importantly, would that be useful? Does the firmware send debug
> events now? Or would it require the user to change the firmware log
> level through fw_dbglog debugfs file before the crash?

Standard firmware sends some info with un-modifed ath10k driver,
and modified firmware can provide much more as needed.  There is
no need to twiddle firmware debug log levels for basic use, though
that may give added benefit in some cases.

> I want to avoid a situation where we have to maintain a feature which
> nobody uses.

Anyone that cares about fixing firmware bugs and making the firmware
stable can make good use of this feature.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  reply	other threads:[~2014-09-02 16:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-28 15:24 [PATCH v5] ath10k: save firmware debug log messages greearb
2014-08-28 15:24 ` greearb
2014-09-02 13:38 ` Kalle Valo
2014-09-02 13:51   ` Michal Kazior
2014-09-02 14:25     ` Kalle Valo
2014-09-02 16:03       ` Ben Greear [this message]
2014-09-02 14:52     ` Ben Greear
2014-09-02 14:58       ` Li, Yanbo
2014-09-02 15:50         ` Ben Greear

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=5405EA6D.2040803@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ath10k@lists.infradead.org \
    --cc=kvalo@qca.qualcomm.com \
    --cc=michal.kazior@tieto.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.