config just ask.
Another factor speaking against (at least in principle) the relation
between the firmware crash and the suspend fail is that, very rarely,
the suspend actually succeed, despite the firmware crash happening.
-- Forwarded message --
From: Enrico Tagliavini
n 03/06/2017 10:40 AM, Ryan Hsu wrote:
>> On 03/06/2017 08:43 AM, Enrico Tagliavini wrote:
>>
>>> Assuming this doesn't make sense I assume the only mistake I might
>>> have maid was marking 05ee799f2021658cc0fc64c1f05c940877b90724 as
>>> good. And who knows
877b90724 as
good. And who knows maybe it was not even a mistake maybe it was a
fluke it worked. Doesn't really matter. I guess what I have to do is
to restart the bisect, mark v4.8 good and
05ee799f2021658cc0fc64c1f05c940877b90724 bad and keep going.
Am I right?
Thank you.
Kind regards
On 24 Feb
;kv...@qca.qualcomm.com> wrote:
> Enrico Tagliavini <enrico.tagliav...@gmail.com> writes:
>
>> Hello everybody,
>>
>> few days ago Fedora 24 pushed kernel 4.9.4 as a stable update, moving
>> from the last release of the 4.8 series. I use suspend to ram very
>
wont repost them here.
Needless to say I'm seeking some assistance here, since I rely on
suspend to ram for a few things that would make it annoying otherwise.
To start with, is my assumption correct in believing this is a fault
within ath10k?
Thank you for your time.
Kind regards.
Enrico
regards.
Enrico
On 5 August 2015 at 19:52, Enrico Tagliavini
<enrico.tagliav...@gmail.com> wrote:
> Bisect is done, unfortunately I think there is no good news
>
> $ git bisect log
> git bisect start '--' 'drivers/net/wireless/ath/ath10k/'
> # bad: [86ea07ca846a7c352f39dd0b7d
Yeah that's what I meant. My idea was to first bisect only the ath10k
directory, so restricting the bisect on the commits touching stuff
there. I guess if the issue is more broad it will come up somewhere
else as well, so this is a good starting point, I hope. Thank you for
pointing it out though,
get started this weekend.
On 29 July 2015 at 11:30, Kalle Valo kv...@qca.qualcomm.com wrote:
Enrico Tagliavini enrico.tagliav...@gmail.com writes:
Yeah that's what I meant. My idea was to first bisect only the ath10k
directory, so restricting the bisect on the commits touching stuff
there. I
not yet found a solution to this issue.
Best Regards
On 07/28/2015 03:57 PM, Enrico Tagliavini wrote:
I was testing the kernel from Fedora rawhide to test some issue
related to the sound card. So this is 4.2 rc3 as released by Linus
plus some Fedora patch. Nothing related to ath10k as far as I can
, Michal Kazior michal.kaz...@tieto.com wrote:
On 28 July 2015 at 13:00, Enrico Tagliavini enrico.tagliav...@gmail.com
wrote:
Hi Michal,
this is the dmesg output from a boot with kernel 4.1.2 with patch to
make the firmware load [1]
Jul 26 10:07:42 alientux.saurisiamonoi.org kernel: ath10k_pci
/linux-stable.git/commit/drivers/net/wireless/ath/ath10k/pci.c?id=11a002efbaa7fbd9f6e616695ab42aa9f1caf060
On 28 July 2015 at 06:31, Michal Kazior michal.kaz...@tieto.com wrote:
On 27 July 2015 at 22:08, Enrico Tagliavini enrico.tagliav...@gmail.com
wrote:
Hello there,
I gave 4.2 rc3 a shot and I
Hello there,
I gave 4.2 rc3 a shot and I discovered the wireless was not working
anymore with it. I tried adding irq_mode=1 alongside skip_otp=y in
ath10k_core (I assume you need fw api 5 to remove this, is that
correct?, I still have fw 4 only).
Loading with irq_mode=0
[ 21.130224]
Hi Kalle,
thank you very much. Hope to also see the firmware out soon :).
Best regards
On 21 July 2015 at 11:23, Kalle Valo kv...@qca.qualcomm.com wrote:
Enrico Tagliavini enrico.tagliav...@gmail.com writes:
Mhm seems like I assumed the backport missing from 4.0 was merged for
4.1
but the wi-fi performance comes only
to about 35%-40% of the performance on windows on the same machine downloading
the same file from the same server .
best regards
Gregor
Am Donnerstag, 4. Juni 2015, 19:03:55 schrieb Enrico Tagliavini:
Hi there,
Just got the following device
enrico
are the blockages to getting this properly supported? I figure he
kernel patch has to work it's way though the maintainers, but are there any
restrictions with publishing the firmware for the linux driver?
Sent: Thursday, June 04, 2015 at 1:22 PM
From: Enrico Tagliavini enrico.tagliav...@gmail.com
, Enrico Tagliavini enrico.tagliav...@gmail.com wrote:
Hi there,
Just got the following device
enrico@alientux ~ $ lspci -nn | grep QCA
03:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac
Wireless Network Adapter [168c:003e] (rev 20)
And discovered there is no firmware
16 matches
Mail list logo
