Re: wlcore: Fix regression in wlcore_set_partition()
On Thu, Feb 25, 2016 at 1:13 PM, Ross Green wrote: > On Thu, Feb 25, 2016 at 11:11 AM, Emil Goode wrote: >> Hello Ross >> >> On Wed, Feb 24, 2016 at 04:40:50PM +1100, Ross Green wrote: >>> On Wed, Feb 17, 2016 at 4:34 PM, Ross Green wrote: >>> > Appreciate your efforts! >>> > >>> > Just trying to make sure it does not get lost. >>> > Introduced in rc1, not fixed by ... rc4. >>> > >>> > Anyway, I will continue to test, lots of other things still to chase >>> > even in rc4! >>> > >>> > Regards, >>> > >>> > Ross Green >>> > >>> > On Wed, Feb 17, 2016 at 2:24 AM, Kalle Valo wrote: >>> >> Ross Green writes: >>> >> >>> >>> On Fri, Feb 12, 2016 at 8:45 PM, Kalle Valo >>> >>> wrote: >>> >>> > The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") >>> > introduced a >>> > regression causing the wlcore to time out and go into recovery. >>> > Reverting the >>> > changes regarding write of the last partition size brings the module >>> > back to >>> > it's functional state. >>> > >>> > Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") >>> > Reported-by: Ross Green >>> > Signed-off-by: Emil Goode >>> > [kv...@codeaurora.org: improved commit log] >>> >>> Thanks, applied to wireless-drivers.git. >>> >>> Kalle Valo >>> >>> >>> >>> I just tested linux-4.5-rc4 it appears the above fix missed the release >>> >>> for rc4! >>> >>> So the behaviour of firmware reset being called after the access of >>> >>> the last partition timesout. >>> >>> >>> >>> Again tested patch with the new release - 4.5-rc4 and found everything >>> >>> to work as expected again. >>> >>> >>> >>> So Hopefully for rc5 - Please! >>> >> >>> >> It takes some time to get patches into Linus' tree. And being in a >>> >> conference and then getting sick is not really helping. I'm not sure if >>> >> this patch makes to rc5 on time, but I'll try. >>> >> >>> >> -- >>> >> Kalle Valo >>> >>> G'day all, >>> >>> I have tested Emil's patch with each 4.5-rc release. >>> >>> Seems to work fine with rc2, rc3, rc4. >>> I tried it with rc5 and get the following output from dmesg see attachment. >>> >>> So it looks like there is a reset that it recovers from and then proceeds >>> OK. >>> >>> I see the patch has been queued by David Miller so it might make it into >>> rc6. >>> That will be great. It still does not look quite as clean as it should >>> be however, given the noise in the dmesg output from rc5 >>> >>> Regards, >>> >>> >>> Ross Green >> >> I'm unable to reproduce that ELP wakeup timeout with v4.5-rc5 on my >> pandaboard es. >> Can you easily reproduce it and are you able to reproduce it with commit >> 3719c17e1816 reverted? >> >> However, I'm seeing another bug that occurs when the wlan is not configured >> to connect to >> an AP directly after boot (dmesg attached). It is not related to any recent >> changes and goes back >> before the 3.14 kernel. There seem to be an issue with the looped IRQ >> handling implementation. >> A scan on 2GHZ is performed and the wlcore_fw_status() call in >> wlcore_irq_locked() returns >> WL1271_ACX_INTR_HW_AVAILABLE, then nothing seem to happen until the delayed >> work queue >> scan_complete_work starts executing after the 30 sec timeout runs out and >> the wlcore goes into >> recovery. I guess a new scan should be initiated after wlcore_fw_status() >> return hw available, >> does anyone have input on that? >> >> Best regards, >> >> Emil Goode > > > Sorry Emil had not tried a reboot since getting that message. The wifi > module did recover and associate properly after that. So I just kept > on using the system. > > Trying to track down another problem that takes "AGES" before it shows > up so just kept the system running. Hoping to get some debug regarding > and RCU problem. > > I will check it again later when i get a chance to reboot. > > At least with your patch in place the system will keep functioning. > Plus I had not noticed any problems running rc2, rc3, rc4 with your > patch in place. > Everything behaved pre the 4.5 changes. > > I'll get back to you with what I find. It does look however that there > might be some other problems sitting there that possibly the new > changes show up more. Some slightly different timing situations. > > Regards, > > Ross Green G'day Emil, Just tried a reboot of the pandaboard es with the patches applied to the 4.5-rc5. Everything worked fine!!! So it might be a strange timing thing that happens "sometimes". the wl processor is running its own software from the firmware downloaded, there might be times when it accessed too soon. So there are still a few things to watch with the changes that have been been added during 4.5. I had assumed that this driver had been fairly stable for some time, but there might have always been a few problems lurking. attached is a small section of the dmesg output, showing good working order for the wl driver. Regards, Ross Green dmesg-4.5-
Re: wlcore: Fix regression in wlcore_set_partition()
On Thu, Feb 25, 2016 at 11:11 AM, Emil Goode wrote: > Hello Ross > > On Wed, Feb 24, 2016 at 04:40:50PM +1100, Ross Green wrote: >> On Wed, Feb 17, 2016 at 4:34 PM, Ross Green wrote: >> > Appreciate your efforts! >> > >> > Just trying to make sure it does not get lost. >> > Introduced in rc1, not fixed by ... rc4. >> > >> > Anyway, I will continue to test, lots of other things still to chase >> > even in rc4! >> > >> > Regards, >> > >> > Ross Green >> > >> > On Wed, Feb 17, 2016 at 2:24 AM, Kalle Valo wrote: >> >> Ross Green writes: >> >> >> >>> On Fri, Feb 12, 2016 at 8:45 PM, Kalle Valo wrote: >> >> > The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") >> > introduced a >> > regression causing the wlcore to time out and go into recovery. >> > Reverting the >> > changes regarding write of the last partition size brings the module >> > back to >> > it's functional state. >> > >> > Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") >> > Reported-by: Ross Green >> > Signed-off-by: Emil Goode >> > [kv...@codeaurora.org: improved commit log] >> >> Thanks, applied to wireless-drivers.git. >> >> Kalle Valo >> >>> >> >>> I just tested linux-4.5-rc4 it appears the above fix missed the release >> >>> for rc4! >> >>> So the behaviour of firmware reset being called after the access of >> >>> the last partition timesout. >> >>> >> >>> Again tested patch with the new release - 4.5-rc4 and found everything >> >>> to work as expected again. >> >>> >> >>> So Hopefully for rc5 - Please! >> >> >> >> It takes some time to get patches into Linus' tree. And being in a >> >> conference and then getting sick is not really helping. I'm not sure if >> >> this patch makes to rc5 on time, but I'll try. >> >> >> >> -- >> >> Kalle Valo >> >> G'day all, >> >> I have tested Emil's patch with each 4.5-rc release. >> >> Seems to work fine with rc2, rc3, rc4. >> I tried it with rc5 and get the following output from dmesg see attachment. >> >> So it looks like there is a reset that it recovers from and then proceeds OK. >> >> I see the patch has been queued by David Miller so it might make it into rc6. >> That will be great. It still does not look quite as clean as it should >> be however, given the noise in the dmesg output from rc5 >> >> Regards, >> >> >> Ross Green > > I'm unable to reproduce that ELP wakeup timeout with v4.5-rc5 on my > pandaboard es. > Can you easily reproduce it and are you able to reproduce it with commit > 3719c17e1816 reverted? > > However, I'm seeing another bug that occurs when the wlan is not configured > to connect to > an AP directly after boot (dmesg attached). It is not related to any recent > changes and goes back > before the 3.14 kernel. There seem to be an issue with the looped IRQ > handling implementation. > A scan on 2GHZ is performed and the wlcore_fw_status() call in > wlcore_irq_locked() returns > WL1271_ACX_INTR_HW_AVAILABLE, then nothing seem to happen until the delayed > work queue > scan_complete_work starts executing after the 30 sec timeout runs out and the > wlcore goes into > recovery. I guess a new scan should be initiated after wlcore_fw_status() > return hw available, > does anyone have input on that? > > Best regards, > > Emil Goode Sorry Emil had not tried a reboot since getting that message. The wifi module did recover and associate properly after that. So I just kept on using the system. Trying to track down another problem that takes "AGES" before it shows up so just kept the system running. Hoping to get some debug regarding and RCU problem. I will check it again later when i get a chance to reboot. At least with your patch in place the system will keep functioning. Plus I had not noticed any problems running rc2, rc3, rc4 with your patch in place. Everything behaved pre the 4.5 changes. I'll get back to you with what I find. It does look however that there might be some other problems sitting there that possibly the new changes show up more. Some slightly different timing situations. Regards, Ross Green
Re: wlcore: Fix regression in wlcore_set_partition()
Hello Ross On Wed, Feb 24, 2016 at 04:40:50PM +1100, Ross Green wrote: > On Wed, Feb 17, 2016 at 4:34 PM, Ross Green wrote: > > Appreciate your efforts! > > > > Just trying to make sure it does not get lost. > > Introduced in rc1, not fixed by ... rc4. > > > > Anyway, I will continue to test, lots of other things still to chase > > even in rc4! > > > > Regards, > > > > Ross Green > > > > On Wed, Feb 17, 2016 at 2:24 AM, Kalle Valo wrote: > >> Ross Green writes: > >> > >>> On Fri, Feb 12, 2016 at 8:45 PM, Kalle Valo wrote: > > > The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") > > introduced a > > regression causing the wlcore to time out and go into recovery. > > Reverting the > > changes regarding write of the last partition size brings the module > > back to > > it's functional state. > > > > Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") > > Reported-by: Ross Green > > Signed-off-by: Emil Goode > > [kv...@codeaurora.org: improved commit log] > > Thanks, applied to wireless-drivers.git. > > Kalle Valo > >>> > >>> I just tested linux-4.5-rc4 it appears the above fix missed the release > >>> for rc4! > >>> So the behaviour of firmware reset being called after the access of > >>> the last partition timesout. > >>> > >>> Again tested patch with the new release - 4.5-rc4 and found everything > >>> to work as expected again. > >>> > >>> So Hopefully for rc5 - Please! > >> > >> It takes some time to get patches into Linus' tree. And being in a > >> conference and then getting sick is not really helping. I'm not sure if > >> this patch makes to rc5 on time, but I'll try. > >> > >> -- > >> Kalle Valo > > G'day all, > > I have tested Emil's patch with each 4.5-rc release. > > Seems to work fine with rc2, rc3, rc4. > I tried it with rc5 and get the following output from dmesg see attachment. > > So it looks like there is a reset that it recovers from and then proceeds OK. > > I see the patch has been queued by David Miller so it might make it into rc6. > That will be great. It still does not look quite as clean as it should > be however, given the noise in the dmesg output from rc5 > > Regards, > > > Ross Green I'm unable to reproduce that ELP wakeup timeout with v4.5-rc5 on my pandaboard es. Can you easily reproduce it and are you able to reproduce it with commit 3719c17e1816 reverted? However, I'm seeing another bug that occurs when the wlan is not configured to connect to an AP directly after boot (dmesg attached). It is not related to any recent changes and goes back before the 3.14 kernel. There seem to be an issue with the looped IRQ handling implementation. A scan on 2GHZ is performed and the wlcore_fw_status() call in wlcore_irq_locked() returns WL1271_ACX_INTR_HW_AVAILABLE, then nothing seem to happen until the delayed work queue scan_complete_work starts executing after the 30 sec timeout runs out and the wlcore goes into recovery. I guess a new scan should be initiated after wlcore_fw_status() return hw available, does anyone have input on that? Best regards, Emil Goode [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.5.0-rc5-armv7-x1-1-gffdb57e (emil@lianli) (gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 2014.11) ) #23 SMP Wed Feb 24 20:36:15 CET 2016 [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: TI OMAP4 PandaBoard-ES [0.00] cma: Reserved 16 MiB at 0xbe80 [0.00] Memory policy: Data cache writealloc [0.00] OMAP4: Map 0xbfe0 to fe60 for dram barrier [0.00] On node 0 totalpages: 261632 [0.00] free_area_init_node: node 0, pgdat c0cbab40, node_mem_map ef6f9000 [0.00] Normal zone: 1728 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 196608 pages, LIFO batch:31 [0.00] HighMem zone: 65024 pages, LIFO batch:15 [0.00] OMAP4460 ES1.1 [0.00] PERCPU: Embedded 14 pages/cpu @ef696000 s24832 r8192 d24320 u57344 [0.00] pcpu-alloc: s24832 r8192 d24320 u57344 alloc=14*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 259904 [0.00] Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p5 ro rootfstype=ext4 rootwait quiet [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 999440K/1046528K available (7346K kernel code, 810K rwdata, 2404K rodata, 1024K init, 8123K bss, 30704K reserved, 16384K cma-reserved, 243712K highmem) [0.00] Virtual kernel memory layout:
Re: wlcore: Fix regression in wlcore_set_partition()
On Wed, Feb 17, 2016 at 4:34 PM, Ross Green wrote: > Appreciate your efforts! > > Just trying to make sure it does not get lost. > Introduced in rc1, not fixed by ... rc4. > > Anyway, I will continue to test, lots of other things still to chase > even in rc4! > > Regards, > > Ross Green > > On Wed, Feb 17, 2016 at 2:24 AM, Kalle Valo wrote: >> Ross Green writes: >> >>> On Fri, Feb 12, 2016 at 8:45 PM, Kalle Valo wrote: > The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced > a > regression causing the wlcore to time out and go into recovery. Reverting > the > changes regarding write of the last partition size brings the module back > to > it's functional state. > > Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") > Reported-by: Ross Green > Signed-off-by: Emil Goode > [kv...@codeaurora.org: improved commit log] Thanks, applied to wireless-drivers.git. Kalle Valo >>> >>> I just tested linux-4.5-rc4 it appears the above fix missed the release for >>> rc4! >>> So the behaviour of firmware reset being called after the access of >>> the last partition timesout. >>> >>> Again tested patch with the new release - 4.5-rc4 and found everything >>> to work as expected again. >>> >>> So Hopefully for rc5 - Please! >> >> It takes some time to get patches into Linus' tree. And being in a >> conference and then getting sick is not really helping. I'm not sure if >> this patch makes to rc5 on time, but I'll try. >> >> -- >> Kalle Valo G'day all, I have tested Emil's patch with each 4.5-rc release. Seems to work fine with rc2, rc3, rc4. I tried it with rc5 and get the following output from dmesg see attachment. So it looks like there is a reset that it recovers from and then proceeds OK. I see the patch has been queued by David Miller so it might make it into rc6. That will be great. It still does not look quite as clean as it should be however, given the noise in the dmesg output from rc5 Regards, Ross Green dmesg-4.5-rc5-wlcore Description: Binary data
Re: wlcore: Fix regression in wlcore_set_partition()
Appreciate your efforts! Just trying to make sure it does not get lost. Introduced in rc1, not fixed by ... rc4. Anyway, I will continue to test, lots of other things still to chase even in rc4! Regards, Ross Green On Wed, Feb 17, 2016 at 2:24 AM, Kalle Valo wrote: > Ross Green writes: > >> On Fri, Feb 12, 2016 at 8:45 PM, Kalle Valo wrote: >>> The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced a regression causing the wlcore to time out and go into recovery. Reverting the changes regarding write of the last partition size brings the module back to it's functional state. Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") Reported-by: Ross Green Signed-off-by: Emil Goode [kv...@codeaurora.org: improved commit log] >>> >>> Thanks, applied to wireless-drivers.git. >>> >>> Kalle Valo >> >> I just tested linux-4.5-rc4 it appears the above fix missed the release for >> rc4! >> So the behaviour of firmware reset being called after the access of >> the last partition timesout. >> >> Again tested patch with the new release - 4.5-rc4 and found everything >> to work as expected again. >> >> So Hopefully for rc5 - Please! > > It takes some time to get patches into Linus' tree. And being in a > conference and then getting sick is not really helping. I'm not sure if > this patch makes to rc5 on time, but I'll try. > > -- > Kalle Valo
Re: wlcore: Fix regression in wlcore_set_partition()
Ross Green writes: > On Fri, Feb 12, 2016 at 8:45 PM, Kalle Valo wrote: >> >>> The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced a >>> regression causing the wlcore to time out and go into recovery. Reverting >>> the >>> changes regarding write of the last partition size brings the module back to >>> it's functional state. >>> >>> Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") >>> Reported-by: Ross Green >>> Signed-off-by: Emil Goode >>> [kv...@codeaurora.org: improved commit log] >> >> Thanks, applied to wireless-drivers.git. >> >> Kalle Valo > > I just tested linux-4.5-rc4 it appears the above fix missed the release for > rc4! > So the behaviour of firmware reset being called after the access of > the last partition timesout. > > Again tested patch with the new release - 4.5-rc4 and found everything > to work as expected again. > > So Hopefully for rc5 - Please! It takes some time to get patches into Linus' tree. And being in a conference and then getting sick is not really helping. I'm not sure if this patch makes to rc5 on time, but I'll try. -- Kalle Valo
Re: wlcore: Fix regression in wlcore_set_partition()
On Fri, Feb 12, 2016 at 8:45 PM, Kalle Valo wrote: > >> The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced a >> regression causing the wlcore to time out and go into recovery. Reverting the >> changes regarding write of the last partition size brings the module back to >> it's functional state. >> >> Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") >> Reported-by: Ross Green >> Signed-off-by: Emil Goode >> [kv...@codeaurora.org: improved commit log] > > Thanks, applied to wireless-drivers.git. > > Kalle Valo I just tested linux-4.5-rc4 it appears the above fix missed the release for rc4! So the behaviour of firmware reset being called after the access of the last partition timesout. Again tested patch with the new release - 4.5-rc4 and found everything to work as expected again. So Hopefully for rc5 - Please! please find attached a copy of the dmesg output for 4.5-rc4 Regards, Ross Green dmesg-4.5-rc4 Description: Binary data
Re: wlcore: Fix regression in wlcore_set_partition()
> The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced a > regression causing the wlcore to time out and go into recovery. Reverting the > changes regarding write of the last partition size brings the module back to > it's functional state. > > Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") > Reported-by: Ross Green > Signed-off-by: Emil Goode > [kv...@codeaurora.org: improved commit log] Thanks, applied to wireless-drivers.git. Kalle Valo