All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: "Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>,
	"kvalo@qca.qualcomm.com" <kvalo@qca.qualcomm.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
Date: Thu, 15 Sep 2016 11:08:31 -0700	[thread overview]
Message-ID: <6dab62e6-4d5d-207c-b012-960f16e39b95@candelatech.com> (raw)
In-Reply-To: <50a08de4-1959-3dc9-cfc7-89d5b2914cc5@candelatech.com>

On 09/15/2016 10:59 AM, Ben Greear wrote:
> On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote:

> I have other patches that remember the last 100 or so firmware log messages from
> the kernel and provide that in a binary dump image when firmware crashes.
>
> This is indeed very useful.
>
> But, when debugging non-crash occasions, it is still useful to see what
> the firmware is doing.
>
> For instance, maybe it is reporting lots of tx-hangs and/or low-level
> resets.  This gives you a clue as to why a user might report 'my wifi sucks'.
>
> Since I am both FW and driver team for my firmware variant,
> and my approach has been working for me, then I feel it is certainly better than
> the current state.  And just maybe the official upstream FW team could start
> using something similar as well.  Currently, I don't see how they can ever make
> much progress on firmware crashes reported in stock kernels.

I forgot the other good reason about console logging this:

Sometimes ath10k firmware crash causes the entire kernel to crash, so there is no time to
grab the binary dump from a file system...but a serial console can help you
make progress...

Thanks,
Ben

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

WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com>
To: "Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>,
	"kvalo@qca.qualcomm.com" <kvalo@qca.qualcomm.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
Date: Thu, 15 Sep 2016 11:08:31 -0700	[thread overview]
Message-ID: <6dab62e6-4d5d-207c-b012-960f16e39b95@candelatech.com> (raw)
In-Reply-To: <50a08de4-1959-3dc9-cfc7-89d5b2914cc5@candelatech.com>

On 09/15/2016 10:59 AM, Ben Greear wrote:
> On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote:

> I have other patches that remember the last 100 or so firmware log messages from
> the kernel and provide that in a binary dump image when firmware crashes.
>
> This is indeed very useful.
>
> But, when debugging non-crash occasions, it is still useful to see what
> the firmware is doing.
>
> For instance, maybe it is reporting lots of tx-hangs and/or low-level
> resets.  This gives you a clue as to why a user might report 'my wifi sucks'.
>
> Since I am both FW and driver team for my firmware variant,
> and my approach has been working for me, then I feel it is certainly better than
> the current state.  And just maybe the official upstream FW team could start
> using something similar as well.  Currently, I don't see how they can ever make
> much progress on firmware crashes reported in stock kernels.

I forgot the other good reason about console logging this:

Sometimes ath10k firmware crash causes the entire kernel to crash, so there is no time to
grab the binary dump from a file system...but a serial console can help you
make progress...

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:[~2016-09-15 18:08 UTC|newest]

Thread overview: 118+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-11 17:02 [PATCH v2 00/21] ath10k patches, generic and CT firmware related greearb
2016-05-11 17:02 ` greearb
2016-05-11 17:02 ` [PATCH v2 01/21] ath10k: Fix crash related to printing features greearb
2016-05-11 17:02   ` greearb
2016-06-07 11:38   ` [v2,01/21] " Kalle Valo
2016-06-07 11:38     ` Kalle Valo
2016-06-20 20:49   ` [PATCH v2 01/21] " Ben Greear
2016-06-20 20:49     ` Ben Greear
2016-06-20 21:56     ` Valo, Kalle
2016-06-20 21:56       ` Valo, Kalle
2016-05-11 17:02 ` [PATCH v2 02/21] ath10k: fix typo in logging message greearb
2016-05-11 17:02   ` greearb
2016-09-27 12:19   ` [v2,02/21] " Kalle Valo
2016-09-27 12:19     ` Kalle Valo
2016-05-11 17:02 ` [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime greearb
2016-05-11 17:02   ` greearb
2016-09-14 14:06   ` Valo, Kalle
2016-09-14 14:06     ` Valo, Kalle
2016-09-14 15:33     ` Ben Greear
2016-09-14 15:33       ` Ben Greear
2016-09-15 14:19       ` Valo, Kalle
2016-09-15 14:19         ` Valo, Kalle
2016-09-15 15:07         ` Ben Greear
2016-09-15 15:07           ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 04/21] ath10k: rate-limit packet tx errors greearb
2016-05-11 17:02   ` greearb
2016-09-14 14:07   ` Valo, Kalle
2016-09-14 14:07     ` Valo, Kalle
2016-09-14 15:02     ` Ben Greear
2016-09-14 15:02       ` Ben Greear
2016-09-15 13:59       ` Valo, Kalle
2016-09-15 13:59         ` Valo, Kalle
2016-09-15 15:22         ` Ben Greear
2016-09-15 15:22           ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 05/21] ath10k: save firmware debug log messages greearb
2016-05-11 17:02   ` greearb
2016-05-11 17:02 ` [PATCH v2 06/21] ath10k: save firmware stacks upon firmware crash greearb
2016-05-11 17:02   ` greearb
2016-05-11 17:02 ` [PATCH v2 07/21] ath10k: save firmware RAM and ROM BSS sections on crash greearb
2016-05-11 17:02   ` greearb
2016-05-11 17:02 ` [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose greearb
2016-05-11 17:02   ` greearb
2016-09-14 14:12   ` Valo, Kalle
2016-09-14 14:12     ` Valo, Kalle
2016-09-14 15:06     ` Ben Greear
2016-09-14 15:06       ` Ben Greear
2016-09-15 14:02       ` Valo, Kalle
2016-09-15 14:02         ` Valo, Kalle
2016-09-15 15:17         ` Ben Greear
2016-09-15 15:17           ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 09/21] ath10k: print fw debug messages in hex greearb
2016-05-11 17:02   ` greearb
2016-09-14 14:18   ` Valo, Kalle
2016-09-14 14:18     ` Valo, Kalle
2016-09-14 15:13     ` Ben Greear
2016-09-14 15:13       ` Ben Greear
2016-09-15 14:06       ` Valo, Kalle
2016-09-15 14:06         ` Valo, Kalle
2016-09-15 15:14         ` Ben Greear
2016-09-15 15:14           ` Ben Greear
2016-09-15 17:34           ` Grumbach, Emmanuel
2016-09-15 17:34             ` Grumbach, Emmanuel
2016-09-15 17:59             ` Ben Greear
2016-09-15 17:59               ` Ben Greear
2016-09-15 18:08               ` Ben Greear [this message]
2016-09-15 18:08                 ` Ben Greear
2016-09-15 20:22               ` Grumbach, Emmanuel
2016-09-15 20:22                 ` Grumbach, Emmanuel
2016-05-11 17:02 ` [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG greearb
2016-05-11 17:02   ` greearb
2016-09-14 14:19   ` Valo, Kalle
2016-09-14 14:19     ` Valo, Kalle
2016-09-14 15:14     ` Ben Greear
2016-09-14 15:14       ` Ben Greear
2016-09-15 14:12       ` Valo, Kalle
2016-09-15 14:12         ` Valo, Kalle
2016-09-15 15:11         ` Ben Greear
2016-09-15 15:11           ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 11/21] ath10k: add fw-powerup-fail to ethtool stats greearb
2016-05-11 17:02   ` greearb
2016-09-14 14:25   ` Valo, Kalle
2016-09-14 14:25     ` Valo, Kalle
2016-09-14 15:19     ` Ben Greear
2016-09-14 15:19       ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 12/21] ath10k: Support up to 64 vdevs greearb
2016-05-11 17:02   ` greearb
2016-09-14 15:01   ` Valo, Kalle
2016-09-14 15:01     ` Valo, Kalle
2016-05-11 17:02 ` [PATCH v2 13/21] ath10k: Document cycle count related counters greearb
2016-05-11 17:02   ` greearb
2016-05-11 17:02 ` [PATCH v2 14/21] ath10k: Add tx/rx bytes, cycle counters to ethtool stats greearb
2016-05-11 17:02   ` greearb
2016-05-11 17:02 ` [PATCH v2 15/21] ath10k: support CT firmware flag greearb
2016-05-11 17:02   ` greearb
2016-09-14 14:30   ` Valo, Kalle
2016-09-14 14:30     ` Valo, Kalle
2016-09-14 15:24     ` Ben Greear
2016-09-14 15:24       ` Ben Greear
2016-09-15 14:15       ` Valo, Kalle
2016-09-15 14:15         ` Valo, Kalle
2016-09-15 14:43         ` Ben Greear
2016-09-15 14:43           ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 16/21] ath10k: Support 32+ stations greearb
2016-05-11 17:02   ` greearb
2016-05-11 17:02 ` [PATCH v2 17/21] ath10k: Enable detecting failure to install key in firmware (CT) greearb
2016-05-11 17:02   ` greearb
2016-05-11 17:02 ` [PATCH v2 18/21] ath10k: Note limitation on beaconing vdevs greearb
2016-05-11 17:02   ` greearb
2016-05-11 17:02 ` [PATCH v2 19/21] ath10k: Enable adhoc mode for CT firmware greearb
2016-05-11 17:02   ` greearb
2016-09-14 14:37   ` Valo, Kalle
2016-09-14 14:37     ` Valo, Kalle
2016-09-14 15:28     ` Ben Greear
2016-09-14 15:28       ` Ben Greear
2016-05-11 17:02 ` [PATCH v2 20/21] ath10k: read firmware crash over ioread32 if CE fails greearb
2016-05-11 17:02   ` greearb
2016-05-11 17:02 ` [PATCH v2 21/21] ath10k: Read dbglog buffers over register ping-pong greearb
2016-05-11 17:02   ` greearb

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=6dab62e6-4d5d-207c-b012-960f16e39b95@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ath10k@lists.infradead.org \
    --cc=emmanuel.grumbach@intel.com \
    --cc=kvalo@qca.qualcomm.com \
    --cc=linux-wireless@vger.kernel.org \
    /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.