200.18 -> very verbose logs with ” ... kernel: [...] this port is not xg port!”

[droopy]

Hello,

After a successful update to 200.18 on three installations, I looked at the logs.

Strangely, on the different installations, I get a kernel message that catches my attention : is very frequent, 4 per second !! : 

May 10 12:03:04 mas-de-vence-wifi kernel: [71175.328741] this port is not xg port!
May 10 12:03:05 mas-de-vence-wifi kernel: [71175.920739] this port is not xg port!
May 10 12:03:05 mas-de-vence-wifi kernel: [71175.922498] this port is not xg port!
May 10 12:03:05 mas-de-vence-wifi kernel: [71175.926366] this port is not xg port!
May 10 12:03:05 mas-de-vence-wifi kernel: [71175.928098] this port is not xg port!
May 10 12:03:06 mas-de-vence-wifi kernel: [71176.920653] this port is not xg port!

Furthermore, I can't find any literature on the subject. So, I'm reaching out to the community for some ideas to better understand the situation because, even though everything seems functional at the moment, it worries me a little.
Am I the only one in this situation? Is this normal?
Thank you in advance for your feedback.

Gerard

P.S.
By the way, thank you for the product, which is very useful to me, and the software updates, which seam’s very cool.

[gritech]

I tried 200.18 again and think I found the issue causing my performance, but then went to 200.17 after also seeing the application reboot events.

[louis]

I just ran into this at a site running R750s.

The interesting thing is this issue did not appear immediately after the upgrade, I checked the system logs a few hours after the upgrade, and there were no apparent issues. But then I tried to change some individual AP settings and received a different error that I've never seen before, I also couldn't find any mention of it online.

"The AP radio [channel-width-group] is invalid: [], should be: *|1|2."

I could not find a way around this error, even trying to change the settings via cli would fail with that message. I inspected the ap and ap group configs via the cli, nothing looked abnormal, they matched other sites without this issue. Then I checked the system logs again to see if there was some better indications of what the `channel-width-group` error was all about, and that's when I noticed they were suddenly filled with 

May 24 16:41:12 <Name of AP here> kernel: [  291.664431] this port is not xg port!

Since the upgrade to 200.18 had completely broken the ability to change any individual AP settings due to the `The AP radio [channel-width-group] is invalid` errors, I figured a factory reset and reconfiguring the system from scratch might help. The reset did fix the `The AP radio [channel-width-group] is invalid` issue. But unfortunately the system log is still flooded with `this port is not xg port!` errors. The errors started as soon as the system came up after the factory reset, all default configuration. After reconfiguring manually, they still continue. There are so many of them I do expect to see instability, but I haven't yet, I might rollback to 200.17 to be safe.

Another interesting thing to note, I upgraded a different site to 200.18 with a similar configuration, but running all R770s. I've not seen either of the issues I mentioned at that site.

[Lovatt67]

Has anyone got a resolution to this issue I'm getting "this port is not xg port!" flooding the logs as well. 

My AP is a R550

[sside]

Same behavior here -- deployed 200.18 with R670 and R750, but the R750 kept logging "this port is not xg port!" and the R670 would climb from 2-3ms -> 2000ms or higher with packet loss. Restarting the R670 by turning on/off POE seemed to fix this for a few hours to a day at most, but then it would lag again. I'm not sure the association between these two events, but I noticed the R750 logs seemed to be full of "this port is not xg port!" around the same time the R670 started to lag.

Similar to @louis and @gritech (linked thread from above), rolling back to 200.17.7.0.152 seems to have fixed it. Fingers crossed, let's see how it goes.

[Rom]

Hello everybody, new contributor here.
I am also experiencing the logs being littered with  "this port is not xg port". It only started when I upgraded my T750 to 200.18. So it looks more like software bug, at least in the meaning that if it is a new diagnostic mode added in the newer version, it can't be switched off in older systems not supporting this function. I am wondering if Ruckus has anything to contribute here?