Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Sound! I'll keep a copy of the log then. If the bisect on ath10k folder will lead nowhere I'll see if I can make it over the whole tree. At least by doing it on the ath10k tree I hope to narrow down the number of commit. Ok then I'll use Linus' master, no problem with this. I hope to at least get started this weekend. On 29 July 2015 at 11:30, Kalle Valo wrote: > Enrico Tagliavini 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 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, this will actually be the first time I do a >> proper bisect. > > And remember to always to mention if you have restricted the bisect > somehow, that's important information. And better if you provide 'git > bisect log' output as well. > >> Also do you want me to bisect Kalle's sources or Linus' master? By >> what Michał said I guess Kalle's but I ask to be sure. >> >> Also to be clear: I'm using Linus' sources at the moment, as provided >> by Fedora rawhide. >> >> For me it's the same, so let me know what you prefer and is more >> useful to solve this issue. > > Good that you brought this up. As ath.git master branch gets rebased > every rc1 release you really cannot use that for bisect. Either you > should use ath.git ath-next branch or Linus' tree. To be on the safe > side I always recommend to use Linus' tree if at all possible. > > -- > Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[ath6kl:pending 20/20] drivers/net/wireless/ath/ath10k/debug.c:2045:16: error: 'ATH10K_FW_STATS_BUF_SIZE' undeclared
tree: git://github.com/kvalo/ath pending
head: 8fd17abc73c862fd751d2fe7ac6be2dfaa4bdf8a
commit: 8fd17abc73c862fd751d2fe7ac6be2dfaa4bdf8a [20/20] ath10k: make fw stats
prints specific to firmware version
config: x86_64-randconfig-v0-07291957 (attached as .config)
reproduce:
git checkout 8fd17abc73c862fd751d2fe7ac6be2dfaa4bdf8a
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers/net/wireless/ath/ath10k/debug.c: In function
'ath10k_debug_fw_pdev_base_stats_fill':
>> drivers/net/wireless/ath/ath10k/debug.c:2045:16: error:
>> 'ATH10K_FW_STATS_BUF_SIZE' undeclared (first use in this function)
int buf_len = ATH10K_FW_STATS_BUF_SIZE;
^
drivers/net/wireless/ath/ath10k/debug.c:2045:16: note: each undeclared
identifier is reported only once for each function it appears in
drivers/net/wireless/ath/ath10k/debug.c: In function
'ath10k_debug_fw_pdev_extra_stats_fill':
drivers/net/wireless/ath/ath10k/debug.c:2076:16: error:
'ATH10K_FW_STATS_BUF_SIZE' undeclared (first use in this function)
int buf_len = ATH10K_FW_STATS_BUF_SIZE;
^
drivers/net/wireless/ath/ath10k/debug.c: In function
'ath10k_debug_fw_pdev_tx_stats_fill':
drivers/net/wireless/ath/ath10k/debug.c:2098:16: error:
'ATH10K_FW_STATS_BUF_SIZE' undeclared (first use in this function)
int buf_len = ATH10K_FW_STATS_BUF_SIZE;
^
drivers/net/wireless/ath/ath10k/debug.c: In function
'ath10k_debug_fw_pdev_rx_stats_fill':
drivers/net/wireless/ath/ath10k/debug.c:2159:16: error:
'ATH10K_FW_STATS_BUF_SIZE' undeclared (first use in this function)
int buf_len = ATH10K_FW_STATS_BUF_SIZE;
^
drivers/net/wireless/ath/ath10k/debug.c: In function
'ath10k_debug_fw_vdev_stats_fill_common':
drivers/net/wireless/ath/ath10k/debug.c:2203:16: error:
'ATH10K_FW_STATS_BUF_SIZE' undeclared (first use in this function)
int buf_len = ATH10K_FW_STATS_BUF_SIZE;
^
drivers/net/wireless/ath/ath10k/debug.c: In function
'ath10k_debug_fw_peer_stats_fill_common':
drivers/net/wireless/ath/ath10k/debug.c:2264:16: error:
'ATH10K_FW_STATS_BUF_SIZE' undeclared (first use in this function)
int buf_len = ATH10K_FW_STATS_BUF_SIZE;
^
drivers/net/wireless/ath/ath10k/debug.c: At top level:
>> drivers/net/wireless/ath/ath10k/debug.c:2278:6: error: redefinition of
>> 'ath10k_debug_fw_stats_fill'
void ath10k_debug_fw_stats_fill(struct ath10k *ar,
^
In file included from drivers/net/wireless/ath/ath10k/debug.c:24:0:
drivers/net/wireless/ath/ath10k/debug.h:138:1: note: previous definition of
'ath10k_debug_fw_stats_fill' was here
ath10k_debug_fw_stats_fill(struct ath10k *ar,
^
drivers/net/wireless/ath/ath10k/debug.c: In function
'ath10k_debug_fw_stats_fill':
drivers/net/wireless/ath/ath10k/debug.c:2283:16: error:
'ATH10K_FW_STATS_BUF_SIZE' undeclared (first use in this function)
int buf_len = ATH10K_FW_STATS_BUF_SIZE;
^
>> drivers/net/wireless/ath/ath10k/debug.c:2299:2: error: implicit declaration
>> of function 'ath10k_debug_fw_stats_num_peers'
>> [-Werror=implicit-function-declaration]
num_peers = ath10k_debug_fw_stats_num_peers(&fw_stats->peers);
^
>> drivers/net/wireless/ath/ath10k/debug.c:2300:2: error: implicit declaration
>> of function 'ath10k_debug_fw_stats_num_vdevs'
>> [-Werror=implicit-function-declaration]
num_vdevs = ath10k_debug_fw_stats_num_vdevs(&fw_stats->vdevs);
^
drivers/net/wireless/ath/ath10k/debug.c: At top level:
>> drivers/net/wireless/ath/ath10k/debug.c:2335:6: error: redefinition of
>> 'ath10k_debug_10x_fw_stats_fill'
void ath10k_debug_10x_fw_stats_fill(struct ath10k *ar,
^
In file included from drivers/net/wireless/ath/ath10k/debug.c:24:0:
drivers/net/wireless/ath/ath10k/debug.h:145:1: note: previous definition of
'ath10k_debug_10x_fw_stats_fill' was here
ath10k_debug_10x_fw_stats_fill(struct ath10k *ar,
^
drivers/net/wireless/ath/ath10k/debug.c: In function
'ath10k_debug_10x_fw_stats_fill':
drivers/net/wireless/ath/ath10k/debug.c:2340:25: error:
'ATH10K_FW_STATS_BUF_SIZE' undeclared (first use in this function)
unsigned int buf_len = ATH10K_FW_STATS_BUF_SIZE;
^
cc1: some warnings being treated as errors
vim +/ATH10K_FW_STATS_BUF_SIZE +2045 drivers/net/wireless/ath/ath10k/debug.c
2039 #ifdef CONFIG_ATH10K_DEBUG
2040 static void
2041 ath10k_debug_fw_pdev_base_stats_fill(const struct ath10k_fw_stats_pdev
*pdev,
2042 char *buf, int *length)
2043 {
2044 int len = *length;
> 2045 int buf_len = ATH10K_FW_STATS_BUF_SIZE;
2046
2047 len += scnprintf(buf + len, buf_len - len, "\n");
2048 len += scnprintf(buf + len, buf_len - len, "%30s\n",
2049 "at
Re: [PATCH] ath10k: Support different txbf configuration schemes
Vivek Natarajan writes: > qca61x4 uses the vdev param as a sole sufficient configuration > for txbf while qca99x0 enables txbf during peer assoc by > combining the vdev param value with peer assoc's vht capabilities > > This patch gets the appropriate txbf configuration scheme > before passing the wmi command to enable the same in the firmware. > > Signed-off-by: Vivek Natarajan The patches don't apply anymore and as they lacking proper sha1 ids I cannot fix the conflicts myself, so please rebase. Please always use ath.git master branch without _any_ extra patches because that way I can usually fix conflicts myself with the help of 3-way merge. Applying: ath10k: Support different txbf configuration schemes fatal: sha1 information is lacking or useless (drivers/net/wireless/ath/ath10k/mac.c). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 ath10k: Support different txbf configuration schemes -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Enrico Tagliavini 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 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, this will actually be the first time I do a > proper bisect. And remember to always to mention if you have restricted the bisect somehow, that's important information. And better if you provide 'git bisect log' output as well. > Also do you want me to bisect Kalle's sources or Linus' master? By > what Michał said I guess Kalle's but I ask to be sure. > > Also to be clear: I'm using Linus' sources at the moment, as provided > by Fedora rawhide. > > For me it's the same, so let me know what you prefer and is more > useful to solve this issue. Good that you brought this up. As ath.git master branch gets rebased every rc1 release you really cannot use that for bisect. Either you should use ath.git ath-next branch or Linus' tree. To be on the safe side I always recommend to use Linus' tree if at all possible. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: AP mode firmware crash on QCA9880-BR4A
On Wed, Jul 29, 2015 at 9:38 AM, Michal Kazior wrote: > I can't get smart antenna out of my head at this point - it wasn't > supported in 10.1 firmware (which works with your device). However > 10.2 seems to report that your hardware itself isn't capable of it so > it shouldn't be a problem (in theory). > > I guess you could try playing with the WMI_BCN_TX_REF_DEF_ANTENNA in > the driver and try things like: 0x1, 0x7, 0xf, 0xff, 0xff00, 0x, > 0xff, 0xff. I have tested the following values (while there were NO changes in ath10k_wmi_event_host_swba = my patch was reverted) and it's still crashing with all of them: 0x1, 0x3, 0x7, 0xf, 0xff, 0xff00, 0x, 0xff and 0xff > I doubt it'll help though. I guess other management frames would crash > firmware as well but I don't think they do. Can you verify that by > running scan from any station around to see if the ath10k AP responds > with a Probe Response and is hence visible in station's scan results, > please? I did that with my second patch applied (that skips sending beacons) and WMI_BCN_TX_REF_DEF_ANTENNA = 0. In this case the AP is *not* visible to other devices (I checked with two android phones, since those are the only other 5G ready devices I have at the moment). Regards, Martin ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
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, this will actually be the first time I do a proper bisect. Also do you want me to bisect Kalle's sources or Linus' master? By what Michał said I guess Kalle's but I ask to be sure. Also to be clear: I'm using Linus' sources at the moment, as provided by Fedora rawhide. For me it's the same, so let me know what you prefer and is more useful to solve this issue. On 29 July 2015 at 08:54, Kalle Valo wrote: > Michal Kazior writes: > >>> This wont work for bisecting. I have to setup something else. Is >>> it ok if I restrict the bisect on the ath10k tree? That has enough >>> commit already to begin with, plus I'm going to be on the road in less >>> than two weeks. >> >> As long as you establish a working and a non-working commit id on >> kvalo tree it should be fine I guess. > > And you can always limit the bisect to a certain directory, but the risk > here is that if the regression is outside ath10k bisect won't find it. > So you need to carefully consider is it safe to do or not. From the man > page: > > "Cutting down bisection by giving more parameters to bisect start > >You can further cut down the number of trials, if you know what >part of the tree is involved in the problem you are tracking >down, by specifying path parameters when issuing the bisect start >command: > >$ git bisect start -- arch/i386 include/asm-i386" > > Also if you can even just narrow down the regression to a smaller set of > patches, let's say few hundred, might make it easier to find the > regression. > > -- > Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v2] ath10k: Improve performance by reducing tx_lock contention.
Marty Faltesek writes: > From: Qi Zhou > > During tx completion, tx_lock is held for longer than required, preventing > efficient refill of htt->pending_tx. Refactor the code so that only MSDU > related operations are protected by the lock. > > Improves downstream performance on a dual-core ARM Freescale LS1024A > (f.k.a. Mindspeed Comcerto 2000) AP with a 3x3 client from 495 to 580 Mbps. > Other CPU bound multicore systems may also benefit. > > Signed-off-by: Denton Gentry > Signed-off-by: Avery Pennarun > [mfalte...@google.com: removed conflicting code for tracking msdu_ids.] > Signed-off-by: Marty Faltesek Thanks, applied. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v4] ath10k: enable raw encap mode and software crypto engine.
Liu CF/TW writes: > From: David Liu > > This patch enables raw Rx/Tx encap mode to support software based > crypto engine. This patch introduces a new module param 'cryptmode'. > >cryptmode: > > 0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX > encapsulation to the firmware. This is the default mode. > 1: Use sofware crypto engine globally with raw mode TX/RX > encapsulation to the firmware. > >Known limitation: > A-MSDU must be disabled for RAW Tx encap mode to perform well when > heavy traffic is applied. > >Testing: (by Michal Kazior ) > > a) Performance Testing > > cryptmode=1 >ap=qca988x sta=killer1525 > killer1525 -> qca988x 194.496 mbps [tcp1 ip4] > killer1525 -> qca988x 238.309 mbps [tcp5 ip4] > killer1525 -> qca988x 266.958 mbps [udp1 ip4] > killer1525 -> qca988x 477.468 mbps [udp5 ip4] > qca988x -> killer1525 301.378 mbps [tcp1 ip4] > qca988x -> killer1525 297.949 mbps [tcp5 ip4] > qca988x -> killer1525 331.351 mbps [udp1 ip4] > qca988x -> killer1525 371.528 mbps [udp5 ip4] >ap=killer1525 sta=qca988x > qca988x -> killer1525 331.447 mbps [tcp1 ip4] > qca988x -> killer1525 328.783 mbps [tcp5 ip4] > qca988x -> killer1525 375.309 mbps [udp1 ip4] > qca988x -> killer1525 403.379 mbps [udp5 ip4] > killer1525 -> qca988x 203.689 mbps [tcp1 ip4] > killer1525 -> qca988x 222.339 mbps [tcp5 ip4] > killer1525 -> qca988x 264.199 mbps [udp1 ip4] > killer1525 -> qca988x 479.371 mbps [udp5 ip4] > > Note: >- only open network tested for RAW vs nwifi performance comparison >- killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps) >- used iperf >- OTA, devices a few cm apart from each other, no shielding >- tcpX/udpX, X - means number of threads used > > Overview: >- relative Tx performance drop is seen but is within reasonable and > expected threshold (A-MSDU must be disabled with RAW Tx) > > b) Connectivity Testing > > cryptmode=1 >ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK >ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK >ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK >ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK >ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK >ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK >ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK >ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK >ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK >ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK >ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK >ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK >ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK >ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK >ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK >ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK >ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK >ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK >ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK >ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK >ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK >ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK >ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK >ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK > > Note: >- each test takes all possible endpoint pairs and pings >- each pair-ping flushes arp table >- ip6 is used > > c) Testbed Topology: > > 1ap1sta: > [ap] [sta] > > endpoints: ap, sta > > 1ap1sta2br: > [veth0] [ap] [sta] [veth2] >| | | | > [veth1] | \ [veth3] > \ /\ / > [br0][br1] > > endpoints: veth0, veth2, br0, br1 > note: STA works in 4addr mode, AP has wds_sta=1 > > 1ap1sta2br1vlan: > [veth0] [ap] [sta] [veth2] >| | | | > [veth1] | \ [veth3] > \ /\ / > [br0] [br1] > | | > [vlan0_id2]
Re: [PATCH] ath10k: suppress 'failed to process fft' warning messages.
Kevin Darbyshire-Bryant writes: > When using DFS channels on Ath10k, kernel log has repeated warning message > 'failed to process fft: -22' typically under medium/heavy traffic. > > This patch switches the warnings to driver debug (WMI events) mode only > thus reducing log file noise. > > DFS and spectral scan share underlying HW mechanisms and enabling one > (DFS) enables the other (spectral scan) as far as event reporting from > firmware to driver is concerned. Spectral scan events take no part in > processing of DFS radar pulses which are delivered as distinct events, > so the fft (spectral event) warning is harmless and DFS interference > detection/protection still occurs. > > Symptoms seen & fix tested in both debug & non-debug modes on TP-Link > Archer C7 v2 platform. > > Signed-off-by: Kevin Darbyshire-Bryant Thanks, applied. In the future please use v2, v3 to mark different versions of the patch so that I can easily find the latest version: https://www.kernel.org/doc/Documentation/SubmittingPatches -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: AP mode firmware crash on QCA9880-BR4A
On 29 July 2015 at 02:04, Martin Blumenstingl
wrote:
> Hi Michal,
>
> sorry for the delay, I was very busy for the past week.
> But now I am back with news.
> To keep it simple, all of my new findings below are with ath10k
> firmware 10.2.4.70-2.
> The wireless drivers were also updated in OpenWrt: "Loading modules
> backported from Linux version master-2015-07-21-0-g47cd203"
>
> On Thu, Jul 23, 2015 at 7:50 AM, Michal Kazior
> wrote:
>> Yes, this should be enough. You'll want to add/keep a print to know
>> how many SWBA event come in though.
> I have used this patch [0] to make ath10k_wmi_event_host_swba only do
> printk("%s()\n", __func__);
> Result: firmware is not crashing - kernel log can be seen here: [1]
>
>> Perhaps not submitting beacons will prevent the crash or it'll postpone it
>> until
>> after more SWBA events are delivered than before.
> I also tried that by #if 0'ing everything starting at "if
> (!arvif->beacon_buf)" until "trace_ath10k_tx_payload(ar, bcn->data,
> bcn->len);". The patch for this can be seen here: [2]
> The result: firmware is still not crashing - kernel log can be seen here: [3]
>
> Without any patches at all (only a printk at the start of
> ath10k_wmi_event_host_swba), this is the result the same as with old
> wireless driver versions: firmware crashes, see [5]
>
> Let me know what the next steps are - I'm sure we can fix this nasty bug! :-)
Awesome report, thanks!
It's good we narrowed the problem down to beacon transmission.
I can't get smart antenna out of my head at this point - it wasn't
supported in 10.1 firmware (which works with your device). However
10.2 seems to report that your hardware itself isn't capable of it so
it shouldn't be a problem (in theory).
I guess you could try playing with the WMI_BCN_TX_REF_DEF_ANTENNA in
the driver and try things like: 0x1, 0x7, 0xf, 0xff, 0xff00, 0x,
0xff, 0xff.
I doubt it'll help though. I guess other management frames would crash
firmware as well but I don't think they do. Can you verify that by
running scan from any station around to see if the ath10k AP responds
with a Probe Response and is hence visible in station's scan results,
please?
Michał
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
RE: Monitor mode TX retry reporting
On 29 July 2015 at 8:23, Michal Kazior wrote: > On 28 July 2015 at 14:21, Jussi Haakana wrote: > > Hi, > > > > I have the following test setup: > > - 1 interface in managed mode > > - 1 interface in monitor mode > > - attach to AP > > - start tcpdump on monitor interface > > - upload e.g. 200MB by using managed mode interface > > - check captured frames > > > > For some reason, on TX frames, I cannot see a single frame that has > retry bit set > > on frame control of 802.11 headers. For RX, retries seem to be reported > normally. > > I'd say that it is unlikely that retransmissions do not happen with > 200MB payload? > > Any ideas what could be causing this? > > You can't sniff your own retransmissions because they are performed by > device and tcpdump sees only a single frame that was submitted through > the networking stack. > > I guess you could emulate this by posting skbuff copies as Rx based on > tx retry series (which aren't available now due to ath10k firmware > limitation). However I'm not aware if there's any driver that does > that. Ok, understood. I've verified that sniffing TX retransmissions is possible with ath9k driver, but it seems not to be the case with ath10k. > If you want to sniff your client retransmissions you'll have to use a > separate device to act as a sniffer or listen on the other endpoint > (i.e. AP). > > > Michał Thanks, Jussi ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Michal Kazior writes: >> This wont work for bisecting. I have to setup something else. Is >> it ok if I restrict the bisect on the ath10k tree? That has enough >> commit already to begin with, plus I'm going to be on the road in less >> than two weeks. > > As long as you establish a working and a non-working commit id on > kvalo tree it should be fine I guess. And you can always limit the bisect to a certain directory, but the risk here is that if the regression is outside ath10k bisect won't find it. So you need to carefully consider is it safe to do or not. From the man page: "Cutting down bisection by giving more parameters to bisect start You can further cut down the number of trials, if you know what part of the tree is involved in the problem you are tracking down, by specifying path parameters when issuing the bisect start command: $ git bisect start -- arch/i386 include/asm-i386" Also if you can even just narrow down the regression to a smaller set of patches, let's say few hundred, might make it easier to find the regression. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
