If you aren't seeing it on build 34, you are unlikely to need the fix, but you are still at risk. The customer who was seeing it readily would see it mostly occur during the CNUT upgrade phase when using AP as the file server. Once the upgrade was done, the event log recovery message very rarely showed up.
If you can, I would go to build 35 just because that is what would become the release build if we are able to proceed next week. Thanks, -Aaron -----Original Message----- From: Af [mailto:[email protected]] On Behalf Of Matt via Af Sent: Friday, October 24, 2014 6:43 PM To: [email protected] Subject: Re: [AFMUG] 13.2(Build 35) Open Beta > Changes in this build include an updated fix for the remaining 13.2 > release blocker. As I discussed with many of you at Wispapalooza, > that issue was related to the “Ethernet Tx Ring stall” message that > may show up in the event log, where very rarely, the recovery didn’t > recover. Because that non-recovery condition led to an AP that had to > be remotely rebooted, we Should we update all all our build 34 to 35 to avoid this or is it unlikely to happen if build 34 is running fine? Just updated to 34. > were unable to release. Over the past couple of weeks we have been > able to get this reproduced at will internally and verify a fix that > took care of the problem. This build has been running a customer site > for a couple of days that saw the issue readily on previous loads, and > the issue has not been seen. > > > > This build also contains a fix for the SM’s color code rescan timer > display (which is new to 13.2) and an update to help with some registration > issues. > > > > This is a release candidate build and we are hoping to have the > release available next week. Please load it and send feedback if you can.
