Hi All.
Just letting everyone know that I emailed the openwrt devel mailing list with two patches that add support for JG926A to openwrt.
Mostly the same as JG924A, with the same fan speed control and PoE stuff as the 8G PoE patch.
Only item of note is each bank of 8 ports is reversed in ID to network port for the PoE.
i.e. id's 1-8 are lan 8-1, id's 9-16 are lan16-lan9 etc.
IIUC, Netgear GS108Tv3/GS110TPv3/GS110TPP switch support - #54 by stragies and the next 4 messages, especially the ones from svanheule and bmork show the same symptom and a possible explanation/solution.
Wow thanks so much for the context!
Was trying to find out why by reading the forum a while back.
I also made a post regarding that earlier on the 1920 8G when I was writing wiki pages for them.
I'll keep that in mind if I ever want to try to get the LED's going and port order fixed.
Okay so the 6.6 stuff got merged into mainnline openwrt for realtek target.
I've rebased my changes and the JG926A works on kernel 6.6. Will probably send through my patches again soon.
@evs - just wanted to check the status on this. I have a JG926A if there's any additional testing or other code shepherding that might help.
I've got two myself =)
Main blocker is consensus on how to handle the fixes on the rtl8231 gpio init and the fan behaviour. I sent through a set of revisions for doing the gpio state per pin in device tree. Check the mailing list?
What it's going to take is me re-doing it with my per register gpio init and/or a change set that gives the option for trusting bootloader GPIO state. There was someone who wanted that functionality as they have a pin on a target that I think keeps PoE active. i.e. otherwise we toggle the PoE on a warm reboot, which may be undesirable.
I haven't been bothered to ping or ask who a realtek maintaineris/ or relevant person who has commit access to have a look yet as I'm not pressed to get this done yet. I'm yet to figure out when I want to swap out my other gear for this anyway.
edit:
@jmspswny Thanks for offering too. But only other thing I guess I haven't bothered to do is look at the factory fan behaviour and how temperature or PoE load effects the fan speed. If you can figure out whether it's open loop on PoE load. Or temperature / fan failure dependent only that would inform what options we can give a user by default in openwrt. Rather than have every user cook up their own fan control at their own risk.
edit2:
Another thing I haven't looked into is RPS/EPS detection, if there's any functionality there?
Thanks!
@evs - I was unable to generate enough load on my JG926A to get the fans to kick on. The JG925A, which is only rated for 180W output, does kick the fans on high when the peak power draw is over 100W, or roughly 50% of available power. After the fans have been triggered, they don't seem to shut off. I've left the switch running with 0 load for more than an hour in my longest test, and they kept running on high.
As for the temp sensor, at least from my digging into the HPE firmware side of things, there doesn't appear to be an accessible temperature sensor on the JG92xA line. That information is always set to 0C. That fact seems to have generated a fair bit of forum complaints.
Will poke at failure behavior next to see if there's anything there.
Cool thanks for the data point! I'll need to confirm what happens with algorithm on my jg922a on factory at some point I guess to see if there's commonality.
I'm going to have trouble getting to over 50% on my JG926A as well. I'll need to borrow some AP's. Getting to over ~120-150W on 24 ports is challenging.
I have JG928A so I could probably get >50% load on there eventually.
Interesting that the fans appear to be latched.
Mm. Asking about temperature relation as apparently the CPU has a temp sensor?
@evs - Further (more careful) testing seems to indicate that the fans are triggered on a threshold of 50% of the rated 180W capacity. The average load calculation doesn't seem to factor in.
The fans do eventually spin down, 30 minutes after the load drops below the 50% threshold. Not sure what was going on before, but I just reran this test on two different JG925A's and got the same results.
I'm still looking for a few more load sources to run the same test on the JG926A.
As for cpu temperature, I've not gotten into the switch beyond the available web and console interfaces, neither of which seem to have an option to pull that information.
Hahaha No worries regarding retesting. That sounds like reasonable behaviour too.
Yeah no worries. If it's not in the advanced command line thing then I guess it's not implemented. I guess that's a nice to have but putting it into the fan behaviour control loop would be an additional extra not required to restore default behaviour.
edit so I don'tt forget:
As far as I remember I did find something that looked like temperature data in the debug output from the HP firmware. IIRC, these were per-port data and looked uncalibrated (big port-to-port variations I think they were commonly off by 10C or more). I'd guess that these aren't used in any control algorithms. For a fan failure condition the fans ramped up to full speed. After a fan fault was cleared there was a long delay (~30 minutes?) before they went back down to low speed. These observations were a long time ago and this is all from memory so treat as low reliability.
To be useful for control purposes (i.e. avoiding component damage or premature wear by limiting component operating temperature) you'd really need temperature sensors in or near the PSU and/or air flow I think. If these aren't present in the design, then I had assumed (and looks like @jmspswny has confirmed) that it just controls fan speed based on power draw instead. The environmental spec for the switch is 0°C to 40°C so observing fan speed with no load and part load at extreme ends of that range would probably be a reasonable confirmation of that.
Mm. there's only two fan speeds anyway, so just knowing the thresholds and hysteresis times looks to be sufficient.
It'd be nice to integrate temperatures but getting to factory behaviour first so everyone is comfortable with the control scheme is a good start.
To clarify - I was suggesting a test to check if ambient temperature has any impact on the low/high fan speed threshold. Evidence to date suggests that it won't, but still worth a test I think.
Oh okay. Thanks for clarifying. I wanted to get out of making a hotbox and reflashing. It's summer here so I guess I'm waiting for a hot day..... =P
Well, it is winter here. I let a JG925A run in the garage overnight, ambient about 26F / -3C, and then plugged in load of more than 50% capacity. The fans spun right up.
So, at least on the low end, ambient doesn't seem to have any impact on fan behavior.
Mm. I had a user PM me that they did high temp testing and no change.
Anyway I'm going to be reading/testing @svanheule's new rtl8231 driver I guess to see if it will also keep the stock fan behaviour.
If the driver detects that the RTL8231 has been initialised already (output drivers started), then it will maintain the configuration. This includes configuration set by the bootloader before the kernel starts. So I hope this can help to improve the fan behavior too.
Awesome thanks! I'll need to have a go building and configuring device tree. This looks so much better than hacks on the existing driver.
@evs Someone else reposted the patches on github. I've merged them to both main and 24.10.