The PSU is 2A, I don't have any of the "official" RPI power supplies, but I'll see if I can wire up my desktop power supply and give it exactly 5v at any amperage it wants.
I figured it would be a 2A, have like half a dozen of them from old cell phones. Pi 4 is 3A, so it's probably even more common. I hope it solves your problem, really strange that a kernel change would yield that as a SD card issue, but stranger things have happened.
In my experience, the RPI ALWAYS complains about low voltage no matter what power it's given. Another reason I'm done with RPIs...
I have never had that problem. Make sure it is at least 2.5A, what is your current rating on the power supply now?
I have tried a few other SBCs, and frankly they are all worse than the Raspberry Pi on mainline. I guess I don't mind tinkering or solving problems, but really haven't had any problems with the Raspberry Pi 4B that weren't livable. But an open source media center isn't for everyone, that's why Nvidia Shield and Android TV boxes exist, but it seems like most people are pretty unsatisfied with the former -- haven't heard anything really bad about the Nvidia Shield.
Armbian has patches for 6.1, but I believe they are in-tree kernel patches and typically LE is out-of-tree for driver builds based on what has been recommended. The wifi chip itself is supposed a Unisoc UWE5266.
That driver appears to quite large at 214 files. I would just pick up a wifi dongle and call it a day. 
Well, I don't see a single person reporting the same issue I'm having, here or on the RPI forums, so it might be premature for me to report it as a bug. Could be something specific to my RPI3 or the SanDisk cards or LE11 or ??
Yep, your situation is pretty unusual (works on 5.10, not anything later). It's not LE11 specific, you more or less proved that. But you said earlier you have used Ubuntu and other OSes, have you taken inventory what version of the Linux kernel was running on those? Considering this issue has been there since at least 5.15, and no one else reported it, seems to suggest a fairly unique to you problem.
The easiest solution is to probably to re-evaluate whether you really need a large SD card (256GB is quite large for a media center, but not sure what other stuff your doing there) and perhaps downsize/buy a different class/brand/something. There is quite the possibility that the engineers over at Raspberry Pi may not spend a lot of effort on it, considering there isn't widespread reports -- although they dug into the CPU problem (not all cores were coming up sporadically) that I had and I was the only one reporting it.
I also have tried this on 2 other 256gb cards I have and it's entirely repeatable every time.
Ahh, thanks for the confirmation. So that closes that door.
I downloaded RPI-OS 64-bit, and didn't even need to do the rpi-update, it failed without that. So, I feel pretty confident that this is a bug in the latest RPI kernel, since it doesn't show up when I install Ubuntu, Moode, LE9, LE10 or any of a number of other distros on this same card (and 2 others I have)
Okay, so there we go. What I would do next is go over to Github and report the bug here:
Just hit the New issue button, and see what the engineers over there can help figure out, and hopefully report back for others to learn your findings. Good luck.
Might be time to try an alternative high capacity SD card so you can emphatically state that LE is having difficulties with them.
I would agree this is a worthwhile test, if you have a fresh SD card of the same size it would be a good idea to load LE11 and test that it also has an issue.
Even though it works with LE 9 and LE 10, you don't really know if it's kernel related or just happens to be the possibility that the SYSTEM image lands on a bad memory cell with LE11 and doesn't with LE10 or LE9. So, no need to say "but works on LE10 and LE9", this is my rationale on why it could still be an SD card failure. Although, I don't think that is the case here, because the kernel is failing to probe the card and don't think it has even gotten this far.
SD card failure is the most likely cause of the problem. If the another similar size SD cards works with LE11, then you would want to do a destructive read/write test on the suspect card to confirm it.
Is 'mmc' how linux identifies a small card, and 'sdhc' how it identifies a large card? If so, then it looks like the problem is that it's trying to read a large card as a small one, which would totally make sense.
Those are just some of the driver components that SD cards (and even eMMCs) share, generally the driver will probe the device and negotiate the appropriate voltage levels and signaling that is supported by both.
I don't know any other tricks, but based on what your describing it would seem to be a kernel issue. You'll want one of the Raspberry Pi engineers to help you further, those guys can guide you on how to turn on debugging to perhaps gather more information.
I just know SD cards can be finicky, and paired with driver bugs it's hard for an end user to figure out because usually the error messages are pretty generic.
TY for confirming. Can I run 'sudo rpi-update' or should I use the build number as frakkin64 suggested?
The latest version is 6.1.19, so you should be OK with rpi-update. The reason I mentioned the commit is yesterday 6.1.16 was the latest and had wireless breakage.
The number of RPi2/3 users on LE10 and LE11 is actually quite high, during the last year the overall userbase distribution has been quite stable at roughly 40% RPi4, 30% RPi2/3, 20% Generic/x86, 10% everything else.
Interesting, I guess it goes to prove that the forums are really only about problems. Do you guys publish those stats anywhere?
I might try this if I get time, but the fact that this is a VERY repeatable error (this same sd card works fine with LE9 and LE10 but once upgraded to LE11, fails) leads me to believe there's a change somewhere between 10 and 11 that affects it's ability to read larger sd cards.
Hopefully a dev at some point who has an RPI3 and large SD card can give this a whirl and see what they find.
Yeah, that's where the Raspberry Pi OS comes into play, if it happens there then you might get more help on the Raspberry Pi Github or Forums. I don't know what the installs look like with LE11, but the impression from the release notes is that most RPi3 users may not be upgrading due to the loss of HEVC accelerated decoding. But they will be running the before mentioned kernel on Raspberry Pi OS, and the problem is probably something in the kernel since what you provided shows the kernel is failing to detect the SD card.
Exiting the "debug shell" resulting in a panic is normal, because the kernel can't mount disks. A few things to try:
1. Try "blkid" and report back what that shows in the shell.
2. Try "dmesg" and see if you can capture the output in any meaningful way, looking to see if the mmc is detected. Alternatively you can try to filter it down to things that say mmc or sdhc with "dmesg|egrep -i '(mmc|sdhc)'" (without double quotes). You can also try piping dmesg output into more with "dmesg |more" if you want to capture each page on the display with a camera.
3. Try adding " sdhci.debug_quirks2=4" to the end of /flash/cmdline.txt (without quotes, same line). This drops 1.8V signaling for UHS cards and runs them at a lower speed, it's worth a shot if only to narrow down the problem.
Lastly, it might be a good idea to test with Raspberry Pi OS and use "sudo rpi-update 889323" to bump to the 6.1.14 kernel (should be similar/close to what LE11 is running) and reboot/test to see. If it's a problem there, then I would report it over on their Github. You can also bump around different kernel versions on Raspberry Pi OS with rpi-update to try and pin-point where it started by using the commit id's from the commit log here.
It doesn't seem like it is a known issue, or a common issue -- but one of the developers might be in the know. I only use Raspberry Pi 4's, and only 1 of them has a 128GB SD card (and it's using Raspberry Pi OS with 6.1.15 kernel) and no problems there. The rest are all 16GB or 32GB cards.
Answered here. TL;DR no wifi suppport at this point -- only mainline wifi drivers are supported.
HiassofT Are the addons available for aarch64 or is that the piece that is in the works?
I already switched over to LE12/aarch64, working great so far. But I had to build the addons and side-load them.
LE is using the default libc resolver and this caches records according to their TTL values so I doubt caching is the issue.
glibc resolver doesn't cache at all, you have to pair it with nscd to get caching. I believe most Linux distributions are using systemd-resolved as a DNS proxy to get DNS caching (never actually cared enough to look, but would assume it does).
LE as far as I remember never had a caching resolver, where as Windows has a caching resolver as part of the OS.
I suspect it's probably always worked this way and your just noticing it now. Here is a thread from 2018 that talks about using the connman DNS proxy:
It appears to be intentional to avoid user confusion.
ah, yes, RTL8822BU would work, but not RTL8812BU...
deleonkikko bad luck, try another wifi dongle.
I have two of these, works with rtw88 driver from 6.2 + usb patches & fixes from wireless mailing list. I think those are all rolled into the Allwinner builds, so maybe it's just enabling the module or running a later image?
This is from an RPi4 w/ the patches from 6.2 + usb patches from mailing list:
Bus 001 Device 003: ID 2357:012d TP-Link Archer T3U [Realtek RTL8812BU]
BTW, I don't know if usb.ids is right here, because I have always used 8822bu drivers but perhaps they actually support 8812 & 8822:
rtw88_8822bu 16384 0
rtw88_8822b 221184 1 rtw88_8822bu
rtw88_usb 24576 1 rtw88_8822bu
rtw88_core 147456 2 rtw88_usb,rtw88_8822b
mac80211 749568 2 rtw88_core,rtw88_usb
I think the Allwinner problem is this maybe:
# CONFIG_RTW88_8822BU is not set
jernej This new patch:
[v2,0/3] wifi: rtw88: USB fixes - Patchwork
Seems to resolve the performance issues with rtw88-usb (RTL8822BU), back to 250Mbit/s now and I suspect the lock-up/crashing will be gone. Running a test build now on Pi4 using these patches:
Isn't host part optional?
If I remember right, and I probably don't, it defaults to server hostname. MariaDB might have changed it, but that's what I remember about MySQL.
Display MoreSET PASSWORD FOR 'root' localhost=PASSWORD('kodi');
CREATE USER IF NOT EXISTS 'kodi';
CREATE USER IF NOT EXISTS 'kodi' localhost;
SET PASSWORD FOR 'kodi'=PASSWORD('kodi');
SET PASSWORD FOR 'kodi' localhost=PASSWORD('kodi');
GRANT ALL ON *.* TO 'kodi';
GRANT ALL ON *.* TO 'kodi' localhost;
flush privileges;
Are you connecting from localhost? If not, you need to add in your network & subnet mask, something like
CREATE USER 'kodi'@'192.168.0.0/255.255.255.0';
MySQL :: MySQL 8.0 Reference Manual :: 6.2.4 Specifying Account Names
