Hi Jason,
I don't want to lead you down the wrong path, but we upgraded to 6.5.0.3 back in November and recently came across an issue where a small population of AP-225s are resetting their 2.4GHz radios every 2 seconds - resulting in the SSID not being broadcasted on the 2.4GHz band - although the 5GHz SSID continues to function. I noticed this behavior back in December on one of our ticket-scanner AP where the manager said he could see it on his iPhone but not on the scanners -> when I saw his iPhone I immediately recognized the "5GHz delay" on the SSID. I rebooted the AP-225 and the problem went away. Only recently did I realize we may have a larger scale issue - my co-worker submitted a post after I discovered a 205H AP with about 13,000 radio resets in an area where a large population of APs only have maybe 10-15 at most - http://community.arubanetworks.com/t5/Wireless-Access/Problem-with-radio-resets-quot-BIG-Hammer-quot/m-p/285325
We haven’t had any reports beyond 1 or 2 about there being an issue as it appears a large amount of students are connecting to the 5Ghz radio – I was actually impressed that our 2.4 and 5 counts were 20% to 80%.
You could do a few quick samples on your AP-205 by running the following command and looking at "Total Radio Resets". However, some resets are due to interference as cjoseph as mentioned in our other posts - should compare similar models - 225 with a 225, 205 with a 205, and vice-versa.
show ap debug radio-stats ap-name <ap-name> radio 1
The big indicator is checking the driver-log and seeing BIG-hammer!!! reset over and over. A few 225s are generating these logs continuously.
show ap debug driver-log ap-name <ap-name>
[6333581.707517] chan dur ibss obss interf time
[6333581.707527] wl1: fatal error, reinitializing
[6333581.707538] wl1: wlc_reset: !!!BIG-hammer!!!
[6333581.762945] wl1 bmac set short slot 1, wl status 1
[6333581.793808] wl1: ap watchdog handler error
[6333583.707497] wl1: bcn inactivity detected HAMMERING
[6333583.707509] wl1: txbcnfrm 0 prev txbcnfrm 0 txbcn inactivity 2 timeout 2
[6333583.707521]
[6333583.707523] chan dur ibss obss interf time
[6333583.707533] wl1: fatal error, reinitializing
[6333583.707544] wl1: wlc_reset: !!!BIG-hammer!!!
[6333583.732442] stats > 100: ccastats_us: 8532, acc->statss_ms: 2
[6333583.763051] wl1 bmac set short slot 1, wl status 1
[6333583.793901] wl1: ap watchdog handler error
[6333585.707497] wl1: bcn inactivity detected HAMMERING
[6333585.707508] wl1: txbcnfrm 0 prev txbcnfrm 0 txbcn inactivity 2 timeout 2
[6333585.707520]
[6333585.707523] chan dur ibss obss interf time
[6333585.707533] wl1: fatal error, reinitializing
[6333585.707544] wl1: wlc_reset: !!!BIG-hammer!!!
[6333585.762967] wl1 bmac set short slot 1, wl status 1
[6333585.793819] wl1: ap watchdog handler error
[6333587.707005] wl1: bcn inactivity detected HAMMERING
[6333587.707017] wl1: txbcnfrm 0 prev txbcnfrm 0 txbcn inactivity 2 timeout 2
[6333587.707029]
[6333587.707031] chan dur ibss obss interf time
[6333587.707042] wl1: fatal error, reinitializing
[6333587.707052] wl1: wlc_reset: !!!BIG-hammer!!!
[6333587.762456] wl1 bmac set short slot 1, wl status 1
[6333587.793287] wl1: ap watchdog handler error
[6333589.707497] wl1: bcn inactivity detected HAMMERING
[6333589.707508] wl1: txbcnfrm 0 prev txbcnfrm 0 txbcn inactivity 2 timeout 2
Something of interest is that we don't have these problems on our 205Hs besides just the single outlier. This problem is largely noticeable in our 4th residence hall which is composed almost entirely of 205s - you actually led me to run the radio-stats command on our 233 APs and I only found maybe 4 or 5 that had the expected 10-15 counts. Now these stats could be normally considered all the home-devices that get brought into the rooms - but it's definitely an oddidity.
Finding out if your APs are exhibiting this issue is easier with a syslog server and setting the AP System Profile Driver Log to debugging (I tried the other levels one by one but didn't get the results till I reached debugging) -> note this is going to send a large amount of logs to your syslog server than normal. I consulted with our syslog admin prior to enabling this level and left it on for about 30 minutes to an hour. You should probably open a TAC case to be safe.
If you have splunk I could share the query our syslog admin created for us that has helped see where we have potential problems. We have a TAC case opened from last week and just yesterday they gathered some more logs to send to the development team.