4625 firmware 5.10.4 pr creporter: Crash has occurred on device

4625AP connected 10SM and 2-3SM reboot with error Crash has occurred on device..
AP and SM firmware 5.10.4

Hi @madmax123 ,

could you PM me the techsupport files?

I sent you a private message

Is there any news this issue?

Hi @madmax123,

it is under investigation. I’m trying to reproduce it in our lab.
If it is still happening, please send me a new techsupport file!

Hi Andrii, we are having the same problem now with the lastest 5.11rc54 recently published and upgraded at 3hs occurring many crashes in a PTP 4625 in 40Mhz, TDD PTP Mode, in the AP side.

Before with 5.10.4 or 5.11rc49 we don’t have this issue…


Update 1: Hardware Acceleration Engine OFF (fix this situation, the AP has more than 9hs uptime), now we go to test with Hardware Acceleration Engine ON, but Hairpin Acceleration OFF

Update 2: with HwAccEng ON, but HairpinAcc OFF, the AP continue running at more than 13h of uptime, but I see a little picks of downs in the traffic, we continue testing and send the TSF to support.

Update 3: we are having a lot of reconnections in the link with theses messages in the suscriptor side: “Reason: 33 (GPFs MISS)”

Hi @Alessio_Garavano ,

could you please PM me techsupport files from the radios where you see crashes?

Hi, we have the same problem. Has any fix been released? We have noticed a lot of reboots and looking into log messages, we have found the same message.

Environment

  • ePMP 4500
  • Software version 5.10.4
  • 20 clients connected

Hi pdinoto - The first thing most folks are going to say is if you’re running 5.10.4 still, to upgrade to 5.12.0 which is at Release Candidate RC35 currently. It’s likely that during 5.10.x or 5.11.x or 5.12 that your issue has already been corrected. And/Or they won’t really be able to go back into 5.10.4 development, and fix it in place in 5.10.x anywhere :person_shrugging:

Upgrading a production system to a Release Candidate effectively means acting as a beta tester, which is frankly unacceptable.

If this is a known bug, Cambium should release a dedicated fix for every supported branch in which the issue is present.

Hello @pdinoto,

I understand your stance on running Release Candidates in a production environment, as uptime and stability are critical.

To determine the exact cause of the reboot and find the safest path forward, please submit a ticket using the Raise Ticket link at the top right of this page and attach the techsupport file from the unit. Our engineers can analyze the logs to verify if this is a known issue and advise on the most stable resolution for your setup.

If a newer build contains the resolution, testing it on a single non-critical sector first is often the safest way to validate the fix before a full rollout.

Thank you!