Unrelated to the above post, but what am I missing in the nbg6817.dts to fix this:
[ 3.425009] dwc3-qcom 110f8800.usb3: IRQ hs_phy_irq not found
[ 3.427475] dwc3-qcom 110f8800.usb3: IRQ dp_hs_phy_irq not found
[ 3.433280] dwc3-qcom 110f8800.usb3: IRQ dm_hs_phy_irq not found
[ 3.439404] dwc3-qcom 110f8800.usb3: IRQ ss_phy_irq not found
[ 3.446275] dwc3-qcom 100f8800.usb3: IRQ hs_phy_irq not found
[ 3.450980] dwc3-qcom 100f8800.usb3: IRQ dp_hs_phy_irq not found
[ 3.458698] dwc3-qcom 100f8800.usb3: IRQ dm_hs_phy_irq not found
[ 3.462898] dwc3-qcom 100f8800.usb3: IRQ ss_phy_irq not found
[ 3.470098] dwc3 11000000.dwc3: Failed to get clk 'ref': -2
[ 3.536901] dwc3 10000000.dwc3: Failed to get clk 'ref': -2
I might have overlooked something in the R7800.dts, but it seems the dwc3 part is defined "in-tree" as part of the ipq8064??
At a minimum, the following QCA drivers will be needed for basic ethernet NSS acceleration:
qca-nss-gmac + related kernel patches
qca-nss-drv + related kernel patches
shortcut-fe/simulated-driver
qca-nss-ecm + related kernel patches
NSS firmware
If QoS is required, then add in 'nss-ifb' driver.
If these can get accepted into the master branch, it'll benefit all ipq806x routers.
It will be tough tho, as someone needs to maintain the codes as the master branch evolve. Even before the maintenance starts, it has to be accepted into master, which I think it'll be really tough, as the kernel changes are very invasive. Likely will not sit well with the openwrt maintainers.
Looking at the changes with the master branch, it looks like a moving target at the moment. Maybe should wait until the next release based on the 5.x kernel?
Looks like there could be a bug with the NSS firmware that's related to the crypto engine. NSS Core 1 is dedicated to the crypto engine operation. If it's a bug with the firmware, there's nothing much we can do tho., unfortunately.
From the stack trace, it looks like the core dump is caused by watchdog? If that's the case, it could be due to your code encountering an infinite loop, deadlocking, causing the watchdog timer to timeout, resulting in a core dump restart?
@Ansuel - I am still treating you as "upstream" for the NSS patchset. Just wondering where your interest is in updating some of the NSS code? There was talk about:
@Ansuel can you take a look? it seems fairly straightforward, only thing i'm unsure about is the new sta block. it looked like something we should include in the offload path still, but i'm unsure.
FYI i haven't run this on my R7800 yet, waiting for the work(ing from home) day to end.
In the NSS drivers, does conntrack work the same way as before or is it in a different way ?
The reason I am asking this is , with the non-NSS boards like IPQ4019 , I was doing some content filtering with this project - https://github.com/vel21ripn/nDPI
This project enables us to do something like this -
iptables -t mangle -I PREROUTING -m ndpi --youtube -j DROP
Now with NSS enabled in the IPQ6018 chipset, the above does not work. I mean it drops the traffic momentarily and then all of a sudden starts working.
Then I felt it could be bcoz of connection tracking , so I even marked the connection and then dropped the mark, but still similar behavior.
There isn't... The problem here is that like the smartphone and any other device with a silicon chip... Every cpu has it's own voltage. Some chip are better than others and some needs more voltage than others.
On ipq806x there are efuses that are set by qcom (or who creates the cpu) that tells how much good the chip is. With this prerequisites....
The regulator system was never actually used (nobody actually enabled the regulator in the first place in the kernel) The regulator comunicate with the system with the rpm firmware. This is a one way comunication. We can tell him to set the value and we wait for a response (most of the time from some test, it does reject the set). AFAIK there is not way to ask the rpm interface to tell us what is the actual voltage used. The current regulator driver is shit and if the regulator is never enabled, it just set the voltage like it has been applied. (the voltage is stored in a simple struct and the value is changed also with the regulator disabled) So the number we gets from regulator_summary are just what we tell the system to set but not what is actually set.
tl;dr regulator system is broken, We can't get the current voltage set in the system.
Also in your case you probably have a working system for the fact that you have a very good silicon cpu... (mainly the last psv is fused and you can use the max freq with just 1050000 instead of 1262500
so your cpu can work with 1v at max freq instead of 1.2v. That if someone have some experience with overclock 0.2v for a cpu is a world of difference)
This is very interesting point. To make sure we are on the same page, I need to reiterate that prior to this build, I was having random reboots like everybody else.
I don't think I have an exceptionally good silicon. I'm never that lucky
Suggestion 1: if you can manage to take your code to work with the actual master, probably someone else can build it and test (for example, me :))
Suggestion 2: if you got it right and it is a matter of voltage (great catch!), i remember that when the nss cores are allowed to throttle themselves automatically the reboots are much more frequent. Maybe this can help in testing? my R7800 reboots more or less once every two or three weeks, i would not be able to test this..
I'm currently testing with a very bad code... Luckly the rpm firmware tells immediately if it does reject the voltage request.
Again this must be fixed or I must find a workaround...
The silicon world is so beautiful. If we apply the same rules that we apply for the normal cpu overclock, the first thing to do is disable cpu scaling to keep stability. And what we are doing here is the same.
well, but if we apply the same rules of the normal cpu/gpu overclock, NSS should be much more instable when fixed at maximum frequency then when fixed at minimum.. and it seems not the case, am i wrong?
