3935i Reverting Firmware

[Ian_Broadway]

Hi All,

We're having an issue with some of our 3935i access points

We've upgraded firmware on one of our c5210 controllers to 10.51.03.

Most APs are still running 10.41.06, mostly 3825i's.

3825i seem stable with the 10.51 code but a few of our 3935s keep rebooting with the error in this article. some of them have taken the code for over a day without issue so far though

https://extremeportal.force.com/ExtrArticleDetail?an=000059573

does the 3935 have different chipsets for different revisions of hardware or something?

this is the second time we've tried to upgrade but may have to rollback.

we had an issue with the 3825s upgrading beyond 10.41.06 to any 10.41 release. Devices not associating with 2.4 radios.

10.51 looks to have resolved this for us.

This is starting to become a common theme, issues with upgrading identifi access points.

we're essentially just looking for some stability at the same time not trying to fall behind with firmware revisions.

has anyone else had first hand of this issue?

Thanks
Ian

[Ian_Broadway]

Have raised a support ticket with our support vendor to request a gtac ticket.

Thanks for your help.

[Doug]

GTAC will want to review the complete crash log.

[Ian_Broadway]

Hmm looks like a pulled the wrong AP log.

This is the actual issue

---Problem report has valid size (35435 bytes)
---WARNING: Problem report has a bad checksum.
---WARNING: Problem report has invalid end-signature at address 40c25ab5

======== Access Point Problem Report =======

INFO: Linux version 3.4.107--10.51.03.0002 (chantry_build@bld-debian1) (gcc version 4.9.1 (crosstool-NG 1.21.0) ) #2 SMP Wed Apr 17 12:53:42 EDT 2019
INFO: Last HW-RD (null)<- (null) @ (null) from (null)
INFO: Last HW-RD (null)<- (null) @ (null) from (null)
INFO: Last HW-RD (null)<- (null) @ (null) from (null)
INFO: Last HW-RD (null)<- (null) @ (null) from (null)
INFO: 1836Y-1061500000, AP3935i-ROW, jiffies 001a8953

Internal error: Unable to handle kernel NULL pointer dereference at virtual address 00000002
: 17 [#1] SMP ARM
Modules linked in: dpi_drv(PO) wips(PO) chantry_ext(PO) ath_pktlog(PO) ath_dev(PO) qca_ol(O) ath_rate_atheros(PO) umac(O) hst_tx99(PO) ath_dfs(PO) ath_spectral(PO) ath_hal(PO) asf(PO) qdf(O) mem_manager(PO) tunnelDrv(PO) tlvDrv(PO) ipsecXform(PO) bonding qca_nss_ipsec(O) qca_nss_ipsecmgr(PO) qca_nss_cfi_ocf(PO) qca_nss_crypto(O) qca_nss_drv(O) qca_nss_gmac(O) ap_drv(PO) libeCrypto(PO) m2Task(PO) atherosHooks(PO) prodenv(PO)
CPU: 1 Tainted: P O (3.4.107--10.51.03.0002 #2)
PC is at mainRX+0x3c/0x2784 [tunnelDrv]
LR is at cleanup_module+0x1350/0x14 [tunnelDrv]
pc : bf0e0160 lr : bf17a79c psr: 60000113
sp : ef07f908 ip : ef07f9d8 fp : ef07f9d4
r10: c245e4c8 r9 : ef07c018 r8 : bf254938
r7 : ef07f9dc r6 : e585d000 r5 : c245e4cc r4 : e4f59280
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 000000f8
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5787d Table: 6525006a DAC: 00000015

[Doug · Accepted solution]

It's still under investigation with GTAC, I would suggest opening a ticket so you can track this issue until it's resolved.