The chip soldered on my device reads as Toshiba TC58BVG0S3HTA00, which has a different page organisation and it complains about fixable bit-flip detection and afterwards about uncorrectable ECC errors when it's handled like the N. Dunno yet how to fix, but haven't investigated further...
Sounds that there are Fritzboxes out there with different flash chips soldered on, the 7430 should be a sibling to the 7412. How to expand the patch to detect the right flash chip? (Can't speak C...) Completely reverting it is only the second best option I think, there is a reason for it...
I had some problems that were solved with 30/30/30, in the case of this problem that you report, I had to change the encryption, but after a while, the problem was a lack of connection with the repeater
so I thought it was better to change wpad wolf basic to wpad mini
Beware of the process of changing packages.
Had the same idea, added the missing 0x72 but left out a description for the B-model and built it this morning (my first build from sources...)
Nope, still remaining the detection of the wrong chip...
Actually I'm building a test (22.03.0-rc3) without the entire patch. But it's poking around...
Sidenote: qosify won't get downloaded for some unrecovered issues. The coresponding Makefile looks good at first sight...
Running 22.03.0-rc1/2/3 on Ubiquiti ER-X with no critical issues so far. However, I would to report a minor problem. When I enable hardware flow offload, RX/TX counters in ifconfig stop counting all packets/bytes, only some amount (?) of them.
Let me try to explain further below in more detail (WAN is on eth0):
Hardware flow offload is disabled:
a. Download a 100 MB file
b. ifconfig shows 100MB+ of RX traffic on interface eth0
Hardware flow offload is enabled:
a. Download a 100 MB file
b. ifconfig shows ~1MB of RX traffic on interface eth0
Some other observations:
This is also observed on a vanilla factory default config with no changes to the default settings.
In both cases traffic is incremented on the dsa interface.
This lack of RX traffic activity propagates to all parts of luci UI, so you can't effectively see the uptick of traffic on the "traffic" tab of "Realtime graphs" page or on the "Interfaces" page when you perform the download.
Software flow offload doesn't affect the correctness of traffic counters.
Most of the traffic doesn't seem to be present even when I run tcpdump on e.g. eth0 or other interfaces. I see some traffic in the tcpdump output but I can't yet find a pattern in what is shown and what's not.
I did a short test of 22.03.0-rc1/2/3 in an unprivileged lxc-container. Container has a config as in OpenWrt docs. dnsmasq refuse to start and system log gets these lines.
Sun May 29 17:37:00 2022 daemon.crit dnsmasq: failed to seed the random number generator: No such file or directory
Sun May 29 17:37:00 2022 daemon.crit dnsmasq: FAILED to start up
Sun May 29 17:37:00 2022 daemon.info procd: Instance dnsmasq::cfg01411c s in a crash loop 6 crashes, 0 seconds since last crash
However, dnsmasq starts ok with cmd /etc/init.d/dnsmasq trace, as it seems to start without ujail, so no meaningful info gets to trace log in /tmp.
dnsmasq works fine with the same container config on the stable version OpenWrt 21.02.3.
My guess is, the failure relates to dnsmasq ujail setup of release canditates in a lxc-container. ujailed ntp process is fine in the container.
22.03.0-rc1/2/3 rootfs were made with the image builder with OpenWrt default configs, no custom configs were yet injected to the container system.
Thanks for mentioning that. Could you please specify some keywords to search for me to find a relevant issue/discussion or maybe you could even give a link to some mailing list thread/forum post to find out more? I would highly appreciate that since I was googling with different combinations of various keywords but unfortunately to no avail.
Ok, if you want, you could have the "Reported-by:, Tested-by" tags of the patch that has to be sent upstream. Thing is, this requires your real name and e-mail. Yes, this name+e-mail will become public and spammer might pick them up.
Same deal for @hnyman, @neg2led I think you both suggested the fix? Please add a message with the tag to the issue for your contribution.
Did you check whether reading the fifth byte really works on a 7530 with the new flash chip? I never managed to read more than this four byte ID - or I did something wrong.
EDIT: OK, I did. And we have a problem now: With the five-byte ID, the flash chip on my 7530 is not properly detected.
EDIT2: Now that I added a printk() statement to check how long the ID is, I remember that I did that before when coming up with the patch. The ID len read in nand_base.c is only 4 bytes.