Is 4K60 enabled? .. If yes, disable it and try again.
Posts by chewitt
-
-
-
the mainline kernel works thanks to the work of volunteers
Google also bankrolls a lot of effort around the Graphics stack in support of ChromeOS (Chromebooks). Most of the work done by Collabora has its roots in ChromeOS needs. Rockchip staff are also upstreaming a lot of the core drivers and board support. There is still a lot of work done by volunteers, but as vendors go, Rockchip aren't bad (better than most, worse than others).
-
andrkac if the changes were packaged into a custom LE image; commit the changes and push to a public repo like GitHub and share the link so anyone following in your footsteps can see them.
-
Right-click, save-as.
-
I believe the following link is very relevant: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766377
If you believe it's relevant have you tried the workarounds it contains? e.g. "ethtool -K eth0 gso off gro off tso off" .. If you shared logs (as asked multiple times) we'd be able to confirm your box produces the same hang messages. No logs = No problem.
NB: LE11 nightlies are here: https://test.libreelec.net/ .. If you want to test safely, stop Kodi, rename /storage/.kodi to .kodi-old and then drop the udpate .tar file in /storage/.update and reboot. You will start with a clean Kodi install - which means we don't "upgrade" all your existing config to LE11 and the downgrade is simply the reverse process; stop Kodi, move folders around so the old folder so the active one and drop the older 'update' file in /storage/.update and reboot again. It's messing .. but low drama.
-
Any suggestions please?
Share logs else we can only make blind guesses at the problem. We suck at guessing, and it's tiresome.
-
intelmorino I think you need to trigger "recovery" mode on the box again. This will trigger the factory u-boot to search for boot scripts and read them, and the important bit - store/overwrite the file-search routines. If you've simply switched the SD card the stored config will be set to look for CE/Legacy files, hence LE bootscripts are not automatically found and read. It's also interesting to see the file rename approach, I wouldn't have thought it would work (but then I don't test with Legacy images or CE at all). Also good to hear the A95XF3 dtb is okay.. I've submitted it upstream and it should be merged for Linux 5.18.
-
If the NUC has LSPCON it makes sense that DP-1 is seen as connected, althoug it's a bit of a mystery why HDMI-1 is not active at the same time since (in theory?) it's the active output. Have you tried an LE11 nightly image? .. newer drivers might give different results (grasping at straws in the dark).
-
-
Kodi only searches for the active DRM device at startup, so if you connect (or power on) the monitor afterwards the kernel will detect it and reconfigure itself for the new active connection but Kodi will remain fixed on whatever it saw at boot. And it looks like the DP-1 port is seen to be active when HDMI is not connected.
The getedid script should work, but you will need to ensure HDMI is connected and the monitor powered on before you power on the NUC, else the script will probably find the DP-1 device active and then you get the EDID for the DP-1 port, maybe?
It's also possible to set "video=HDMI-A-1:1920x1080M@60" in kernel boot params, which should force output to the HDMI connector with some standard timings. Other random thoughts are to disable the DP ports in BIOS, if that's possible?
-
it does not continue loading and the error appears at the top right of the screen as already explained
And what does the error say? (snap a pic on a phone or take a slowmo video it's quick)
-
-
Urgh.. I didn't notice that
-
A95X F3 Air (S905X3)..has anyone had any success booting with one of these?
If Armbian boot scripts work, LE scripts should work too as the Armbian ones were plaiguarised from LE in the first place. Project stats show a few active installs so I assume it worked for someone somewhere (no guarantees your box is the same though as there are 20+ box vendors shipping 'Air' boxes that look identical).
-
Anyway, may I ask, what is the harm in shipping an improved driver with multiple bug fixes?
Test an LE11 nightly from https://test.libreelec.net/ and you will be using the latest LTS kernel driver that Intel has contributed fixes to. If we switched from the in-kernel driver frequently maintained by Intel to some forgotten out-of-tree kernel driver that Intel has not touched in two years; you can expect more breakage than fixage.
-
-
Users with a problem Ethernet connection are not unheard of, but I'd start with changes to Cables and Switches before pointing the finger at the kernel driver. LE uses the upstream in-kernel driver - which is also used by 10's of millions of other Intel devices. It's not impossible for the driver to have an issue, but if you do want to point the finger in that direction you will need to convince us by sharing some proper technical evidence of it being the source of problems! NB: In all cases we will not update to the not-in-kernel vendor driver, it would be a bad move.