We had 7.6.120.0 on a 5508 controller that we stood up specifically for new 3700's we put in a building we rewired which failed miserably with our webauth network. TAC gave us an engineering build of 7.6.122.9 which resolved that issue, then our eduroam network started having issues keeping clients connected with Client Band Select enabled. Fortunately, the old APs were just disabled while we were rolling this out.
I installed 7.6MR3 on the 5508, which resolved the band select issue in my test AP I stood up, but I'm leaving the 3700's in the aforementioned building turned off until we get through the first two weeks of our semester start. Also, food for thought. According to our TAC engineer, 5508's and WiSM-2's use the exact same code. As I'm told, validating using a 5508 WLC should mimic exactly that of production WiSM-2's. Cheers. Britton Anderson <blanders...@alaska.edu> | Senior Network Communications Specialist | University of Alaska <http://www.alaska.edu/oit> | 907.450.8250 On Thu, Sep 4, 2014 at 7:20 AM, Trent Hurt <trent.h...@louisville.edu> wrote: > There are a quite a few bugs with that release. I experienced a few of > them that caused high cpu and controller crash and they were webauth > related. I would recommend 7.6mr3 and not 8.0 unless you have specific > need for the newer features it has in it. I’m running 7.6mr3 on 5508’s and > 2504’s and have some HA pairs and so far it seems to be pretty stable. > > > > *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: > WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Danny Eaton > *Sent:* Wednesday, September 03, 2014 7:34 PM > *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > *Subject:* [WIRELESS-LAN] WiSM-2 and 7.6.120.0.... > > > > Is anyone seeing controller crashes on 7.6.120.0 with a high load? We > upgrade to 7.6.120.0 in May, but haven’t had a real load (over 5,000 > clients, say) until this past two weeks. > > > > We had “something” happen on Friday. We did do a “therapeutic reboot” on > Saturday morning (at oh my God it’s 3:30 in the morning!). However, today > it repeated. While investigating, we discovered the primary in one of the > clusters apparently failed and went into maintenance mode. However, the > active “secondary” still showed standby hot, so we did a failover – which > caused an outage (uh oh). While consoled in, we got the maintenance moded > primary back up, and was bringing the secondary back up, when we found this: > > > > pmallocProcessMemoryCorruption called by file(rrmSocket_wlc.c), line(128), > for size(2048), failureType = (4) > > this entry's previous access was by: file(capwap_ac_sm.c), line(7393) > > (pmallocProcessMemoryCorruption): > pmallocGenericCrashInfo=(++PMALLOC_POISONED_AREA_CORRUPTION) > > (pmallocProcessMemoryCorruption): thread ID(349256224) > > (pmallocProcessMemoryCorruption): thread name(Unknown task name, task id = > (349256224)) > > (pmallocProcessMemoryCorruption): current access file name(rrmSocket_wlc.c) > > (pmallocProcessMemoryCorruption): previous-access file name(capwap_ac_sm.c) > > pmallocProcessMemoryCorruption called by file(rrmSocket_wlc.c), line(128), > for size(2048), failureType = (4) > > this entry's previous access was by: file(capwap_ac_sm.c), line(7393) > > (pmallocProcessMemoryCorruption): > pmallocGenericCrashInfo=(++PMALLOC_POISONED_AREA_CORRUPTION) > > (pmallocProcessMemoryCorruption): thread ID(349256224) > > (pmallocProcessMemoryCorruption): thread name(Unknown task name, task id = > (349256224)) > > (pmallocProcessMemoryCorruption): current access file name(rrmSocket_wlc.c) > > (pmallocProcessMemoryCorruption): previous-access file name(capwap_ac_sm.c) > > Dumping a core. This can take a few minutes... > > Controller crashed ....Queue Woken up jiffies = 4295262648 > > > > Obviously, that is bad (and yes, we’re opening a TAC case). > > > > tl;dr > > > > Has anyone else seen oddities with crashes on 7.6.120.0, > and if so, did you upgrade? To 7.6.130.0, or 8.0.100.0? I’m running > 8.0.100.0 in the lab, but light load. (which is what we did on 7.6.120.0 > since May)… > > > > Thoughts? Opinions? > > > > > > > > Respectfully, > > > > Danny Eaton > > > > Snr. Network Architect > > Networking, Telecommunications, & Operations > > Rice University, IT > > Mudd Bldg, RM #205 > > Jones College Associate > > Office - 713-348-5233 > > Cellular - 832-247-7496 > > dannyea...@rice.edu > > > > Soli Deo Gloria > > Matt 18:4-6 > > > > G.K. Chesterton, “Christianity has not been tried and found wanting. It’s > been found hard and left untried.” > > > > > > > > > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
