Kalle Valo writes:
>> Since this is just debugfs then I imagine you could have a userspace
>> program that would create the single blob/crash report from things it
>> thinks is important, e.g.. `uname -a`, debugfs entries (fw stack
>> traces, dbglog, etc), recent kernel log buffer, etc. It could
On 20 August 2014 07:40, Kalle Valo wrote:
> Pushpal Sidhu writes:
>
>> One interesting thing I found is if I use OpenWrt trunk, ath10k seems
>> to behave fine, but another distro seems to break things. I'll need to
>> dig further into that, but in the mean time, do you have any thoughts?
>
> Wha
Michal Kazior writes:
> On 19 August 2014 17:25, Ben Greear wrote:
>> On 08/19/2014 02:33 AM, Michal Kazior wrote:
>>> On 19 August 2014 10:22, Kalle Valo wrote:
> [...]
+ __le32 target_version;
+ __le32 fw_version_major;
+ __le32 fw_version_minor;
+
On 19 August 2014 17:25, Ben Greear wrote:
> On 08/19/2014 02:33 AM, Michal Kazior wrote:
>> On 19 August 2014 10:22, Kalle Valo wrote:
[...]
>>> + __le32 target_version;
>>> + __le32 fw_version_major;
>>> + __le32 fw_version_minor;
>>> + __le32 fw_version_release;
>>> +
On 19 August 2014 20:27, Pushpal Sidhu wrote:
> Hi,
>
> I'm having issues with ath10k timing out when trying to communicate
> with the wireless card (UNEX DAXA-O1 + have tried several others).
> Below is what I grabbed from dmesg.
>
> $ dmesg | grep ath10k
> [5.233469] ath10k_pci :09:00.0:
Kalle Valo writes:
> Pushpal Sidhu writes:
>
>> I'm having issues with ath10k timing out when trying to communicate
>> with the wireless card (UNEX DAXA-O1 + have tried several others).
>> Below is what I grabbed from dmesg.
>>
>> $ dmesg | grep ath10k
>> [5.233469] ath10k_pci :09:00.0:
Pushpal Sidhu writes:
> I'm having issues with ath10k timing out when trying to communicate
> with the wireless card (UNEX DAXA-O1 + have tried several others).
> Below is what I grabbed from dmesg.
>
> $ dmesg | grep ath10k
> [5.233469] ath10k_pci :09:00.0: enabling device (0140 -> 0142)
Pushpal Sidhu writes:
> One interesting thing I found is if I use OpenWrt trunk, ath10k seems
> to behave fine, but another distro seems to break things. I'll need to
> dig further into that, but in the mean time, do you have any thoughts?
What do you mean? On the exact same board ath10k works w
On Tue, Aug 19, 2014 at 5:56 PM, Adrian Chadd wrote:
> Yeah, but you have to be careful to not drop any queued frames or
> associated station state. Hence why it's done as a separate vdev,
> rather than being done under software channel change control.
That makes sense. So how doomed am I if I w
Yeah, but you have to be careful to not drop any queued frames or
associated station state. Hence why it's done as a separate vdev,
rather than being done under software channel change control.
-a
___
ath10k mailing list
ath10k@lists.infradead.org
http
On Tue, Aug 19, 2014 at 11:23 AM, Adrian Chadd wrote:
> Yes. The whole point is that the firmware knows about the vdev and you
> set the channel on that. The intention is that there's multiple vdevs
> and if they're on different channels (eg STA + P2P, or STA + STA) then
> the firmware can handle
On Tue, Aug 19, 2014 at 11:42 AM, Ben Greear wrote:
> Have you tried a WLE900 VX NIC? Those have worked well for me.
I haven't yet, though I'll get my hands on one to try out. I have
tried a WLE900N5-20 with the
same results below, however.
>> I am using the following software on an ARM board:
On 08/19/2014 11:27 AM, Pushpal Sidhu wrote:
> Hi,
>
> I'm having issues with ath10k timing out when trying to communicate
> with the wireless card (UNEX DAXA-O1 + have tried several others).
Have you tried a WLE900 VX NIC? Those have worked well for me.
> Below is what I grabbed from dmesg.
>
Hi,
I'm having issues with ath10k timing out when trying to communicate
with the wireless card (UNEX DAXA-O1 + have tried several others).
Below is what I grabbed from dmesg.
$ dmesg | grep ath10k
[5.233469] ath10k_pci :09:00.0: enabling device (0140 -> 0142)
[5.575954] ath10k: pci ir
On 08/18/2014 02:45 AM, Vu Hai NGUYEN wrote:
> I'd cleaned all rules of iptables and removed all modules of iptables from
> kernel by command modprobe -r
> But there's still some process of netfilter process running. I disabled
> netfilter on bridge interface by writing 0 to these files:
> /proc
On 08/19/2014 08:25 AM, Ben Greear wrote:
>>> + dump_data->kernel_ver_code = cpu_to_le32(LINUX_VERSION_CODE);
>>> + strlcpy(dump_data->kernel_ver, VERMAGIC_STRING,
>>> + sizeof(dump_data->kernel_ver));
>>> +
>>> + dump_data->tv_sec = cpu_to_le64(crash_data->timestam
On 08/19/2014 02:33 AM, Michal Kazior wrote:
On 19 August 2014 10:22, Kalle Valo wrote:
From: Ben Greear
Store the firmware crash registers and last 128 or so
firmware debug-log ids and present them to user-space
via debugfs.
Should help with figuring out why the firmware crashed.
Signed-
Hi,
Yes. The whole point is that the firmware knows about the vdev and you
set the channel on that. The intention is that there's multiple vdevs
and if they're on different channels (eg STA + P2P, or STA + STA) then
the firmware can handle channel changing, sending sleep notifications
to the AP, b
+ spin_lock_bh(&ar->data_lock);
+
+ /* First 4 bytes are a messages-dropped-due-to-overflow counter,
+* and should not be recorded in the dbglog buffer, so we skip
+* them.
+*/
+ ath10k_debug_dbglog_add(ar, skb->data + 4, skb->len - 4);
Can't we just:
On 08/19/2014 05:11 AM, Kalle Valo wrote:
gree...@candelatech.com writes:
From: Ben Greear
Only print error message upon failure, and print more
details in case it does find an error.
Signed-off-by: Ben Greear
---
This is on top of the firmware crash reporting patches,
not sure it would
Michal Kazior writes:
> On 14 August 2014 10:40, Kalle Valo wrote:
>> Michal Kazior writes:
>>
>>> It doesn't make much sense to overwrite send_cb
>>> and recv_cb callbacks over and over again whenever
>>> transport starts. Just make sure to unmask copy
>>> engine interrupts when starting.
>>>
On 14 August 2014 10:40, Kalle Valo wrote:
> Michal Kazior writes:
>
>> It doesn't make much sense to overwrite send_cb
>> and recv_cb callbacks over and over again whenever
>> transport starts. Just make sure to unmask copy
>> engine interrupts when starting.
>>
>> Signed-off-by: Michal Kazior
gree...@candelatech.com writes:
> From: Ben Greear
>
> Only print error message upon failure, and print more
> details in case it does find an error.
>
> Signed-off-by: Ben Greear
> ---
>
> This is on top of the firmware crash reporting patches,
> not sure it would apply clean until those get in
Michal Kazior writes:
>>> @@ -1905,22 +1915,10 @@ static int __ath10k_pci_hif_power_up(struct ath10k
>>> *ar, bool cold_reset)
>>> goto err;
>>> }
>>>
>>> - ret = ath10k_ce_disable_interrupts(ar);
>>> - if (ret) {
>>> - ath10k_err("failed to disable CE int
Service mapping for main firmware branch was
incorrectly used for 10.x firmware and vice-versa.
This caused wmi_services in debugfs to print wrong
values.
This actually fixes a problem with the previous
wmi service bitmap patch itself. For some reason
there was either a conflict that wasn't resolv
Michal Kazior writes:
> On 12 August 2014 09:44, Kalle Valo wrote:
>> Michal Kazior writes:
>>
>>> The 10.x and main firmware branches have
>>> conflicting WMI service bitmap definitions.
>>>
>>> This also fixes WMI services parsing on big-endian
>>> hosts and changes debugfs output to be more
On 19 August 2014 11:39, Michal Kazior wrote:
I miss-clicked, sorry for the noise.
> On 19 August 2014 10:23, Kalle Valo wrote:
>> From: Ben Greear
>>
>> They may be dumped through the firmware dump debugfs
>> file.
>>
>> Signed-off-by: Ben Greear
>> Signed-off-by: Kalle Valo
>> ---
>> dri
On 19 August 2014 10:23, Kalle Valo wrote:
> From: Ben Greear
>
> They may be dumped through the firmware dump debugfs
> file.
>
> Signed-off-by: Ben Greear
> Signed-off-by: Kalle Valo
> ---
> drivers/net/wireless/ath/ath10k/wmi.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff
On 19 August 2014 10:23, Kalle Valo wrote:
> From: Ben Greear
>
> This can be used to get a useful back trace out of a firmware
> crash that involves an interrupt handler. For instance, a
> null-pointer-exception would be this kind of trace. A user-space
> tool can read the debugfs file and dec
On 19 August 2014 10:23, Kalle Valo wrote:
> From: Ben Greear
>
> Firmware developers can decode this and maybe figure out
> why the firmware crashed.
>
> Signed-off-by: Ben Greear
> Signed-off-by: Kalle Valo
> ---
[...]
> +/* Save the firmware exception stack */
> +static void ath10k_pci_dump_
On 19 August 2014 10:23, Kalle Valo wrote:
> From: Ben Greear
>
> Should help debug firmware crashes, and give users a way
> to provide some useful debug reports to firmware developers.
>
> Signed-off-by: Ben Greear
> Signed-off-by: Kalle Valo
> ---
[...]
> +/* Save the main firmware stack */
>
On 19 August 2014 10:22, Kalle Valo wrote:
> From: Ben Greear
>
> Store the firmware crash registers and last 128 or so
> firmware debug-log ids and present them to user-space
> via debugfs.
>
> Should help with figuring out why the firmware crashed.
>
> Signed-off-by: Ben Greear
> Signed-off-by
From: Ben Greear
This can be used to get a useful back trace out of a firmware
crash that involves an interrupt handler. For instance, a
null-pointer-exception would be this kind of trace. A user-space
tool can read the debugfs file and decode things as wished.
This requires a packaged firmwar
From: Ben Greear
Should help debug firmware crashes, and give users a way
to provide some useful debug reports to firmware developers.
Signed-off-by: Ben Greear
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/core.h |1 +
drivers/net/wireless/ath/ath10k/debug.c | 12 +
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/core.c | 17 ++---
drivers/net/wireless/ath/ath10k/debug.c | 18 ++
drivers/net/wireless/ath/ath10k/debug.h |1 +
drivers/net/wireless/ath/ath10k/pci.c |4 +---
4 files changed, 22 insertions(
From: Ben Greear
Firmware developers can decode this and maybe figure out
why the firmware crashed.
Signed-off-by: Ben Greear
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/core.h |1 +
drivers/net/wireless/ath/ath10k/debug.c | 11 +++
drivers/net/wireless/ath/at
From: Ben Greear
Store the firmware crash registers and last 128 or so
firmware debug-log ids and present them to user-space
via debugfs.
Should help with figuring out why the firmware crashed.
Signed-off-by: Ben Greear
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/core.h |
ath10k_pci_diag_read32() is for reading u32 from a device and
ath10k_pci_diag_read_hi()
is a helper for reading data using "host interest" table.
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/pci.c | 55 +++--
1 file changed, 38 insertions(+), 17 de
From: Ben Greear
They may be dumped through the firmware dump debugfs
file.
Signed-off-by: Ben Greear
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/wmi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wire
Better to have a clear name for the function. While at it, clear up the title
for the register dump.
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/pci.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drive
Hi,
new version of the firmware crash dump support for ath10k. Hopefully the last
one :)
Kalle
TODO for the future:
* atomic allocation in ath10k_pci_dump_dbglog() is bad. Should we
allocate a big buffer with vmalloc and use that?
* dynamic allocation for BSS buffers
v7:
* really send "ath
On 12 August 2014 09:44, Kalle Valo wrote:
> Michal Kazior writes:
>
>> The 10.x and main firmware branches have
>> conflicting WMI service bitmap definitions.
>>
>> This also fixes WMI services parsing on big-endian
>> hosts and changes debugfs output to be more human
>> friendly.
>>
>> Signed-o
On 19 August 2014 08:30, Kalle Valo wrote:
> Michal Kazior writes:
>
>> On 19 August 2014 08:07, Kalle Valo wrote:
>>> Avery Pennarun writes:
>>>
>> Are there any plans to implement this feature? It's important in
>> order to implement automatic channel change in case of changes in the
43 matches
Mail list logo
