-
Posts
365 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Myy
-
-
If you know how to recompile armbian kernels ( sudo ./compile.sh docker EXPERT="yes" ), could you test this :
https://github.com/armbian/build/pull/1887
And see if that works with your TV ?
-
This might be due to the lack of some YUV configurations support in the Rockchip DRM drivers used in mainline kernels.
I'll try some new HDMI patches next week, against mainline kernels, see if that resolve these kind of situations.
-
Hmm, the WARNING can either happen during these four situations :
- https://elixir.bootlin.com/linux/v5.4.35/source/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#L1234
- https://elixir.bootlin.com/linux/v5.4.35/source/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#L1252
- https://elixir.bootlin.com/linux/v5.4.35/source/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#L1253
- https://elixir.bootlin.com/linux/v5.4.35/source/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#L1269
In the first case, that means that the VOP unit got disabled, for whatever reasons.
The others mean some DRM/KMS bugs, which might be due to Rockchip DRM drivers.
The best way to be sure would be to recompile a kernel and place logs before the specified points ( dev_err(crtc->dev, KERN_ERROR "Blabla is %d\n", value_to_test) )
-
Yeah, the logs message clearly indicate that something is going very wrong. My guess is that there's a driver messing up with the system memory, so you get very random behaviour or crashes.
So, indeed, try without the Bluetooth dongle for a week or so, see if there's any issue.
If there isn't, you'll have to find updated Bluetooth drivers for this chip, or just find another Bluetooth dongle with decent drivers.
-
Try Werner steps first.
Installing libgles2 installed OpenGL ES 2.x drivers. So, to test it, you could try glmark2-es2 (which is installed with glmark2).
I'm still surprised that apt install mesa returns nothing.
-
The BUG messages in the logs clearly comes from the Realtek driver.
Where did you find its driver and which version are you using ?
Could you try this one : https://github.com/aircrack-ng/rtl8812au ?
-
Anything in dmesg related to W1 ?
If the modules are loaded, that mean that the detection was done correctly. However, something might have happened during one of these modules initialization.
-
Is the w1-gpio module loaded ?
-
Interesting... So the mouse acting up through the Bluetooth driver might have generated some severe issues ?
Well, misbehaving kernel drivers can trigger a lot of issues, since they can write anywhere in memory.
So, if I understand correctly, no issues so far now that you've recompiled the Bluetooth drivers ? (Beside the WARN messages)
Also searching "http://ix.io/2iU9" in DuckDuckGo returned me the weirdest search results I've seen so far, with all results pointing to EXE files. It seems that "2iU9" is a common string in .EXE files.
-
So, what does apt install libgles2-mesa does ?
Does it install the 20.1~git2004201930.a1f6ae~oibaf~b version ?
-
Ah, my bad, I thought their build system generated a "mesa" package, but it splitted it into multiple ones ( https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers/+packages )
Try apt show libgles2-mesa
-
Hmm, wait.
if you do apt-get install mesa
Does it install anything ?
Could you show what apt show mesa returns ?
-
What's the output of dpkg -L mesa* on your system ?
-
I don't think so, this will build the latest Mesa drivers for your graphics card, whatever distribution you're using.
-
You might want to follow the "panfrost" build steps provided in the first post link :
-
Could you just provide the output of :
find / -name "libGL*.so*"
My guess is that you might have two set of Mesa libraries, the ones provided through dpkg and the ones you might have installed yourself.
Also, give glmark2 a try too.
Maybe the OpenGL drivers are not the right one, but the OpenGL ES are.
-
Yes, the patch is being tested currently : https://github.com/armbian/build/pull/1887
-
Quote
OpenGL vendor string: VMware, Inc.
Are you sure you're using Panfrost ?
-
Yeah, the causes of the CPU not coming online and the cause of the WARNING message are completely different.
It seems that CPU 4 and 5 belong to another part of the system :
[ 0.000000] GICv3: GIC: PPI partition interrupt-partition-0[0] { /cpus/cpu@0[0] /cpus/cpu@1[1] /cpus/cpu@2[2] /cpus/cpu@3[3] }
[ 0.000000] GICv3: GIC: PPI partition interrupt-partition-1[1] { /cpus/cpu@100[4] /cpus/cpu@101[5] }
So I *guess* that something is happening during the initialization of interrupt-partition-1[1] bringing both CPU down the drain.
However, your first logs seem to suggest that 5.5 kernel were able to put the CPU online... Hmm...
Does the problem happen on every boot ? Only after a cold boot ? Only after a reboot ?
If that happens from times to times, that might be a timing issue...
But I don't really see any patch to the GICv3 driver that could have fixed this issue directly :
https://github.com/torvalds/linux/commits/master/drivers/irqchip/irq-gic-v3.c
They only fixed a few issues that mattered to Cavium boards, when it comes to ARM64 specific patches.
-
Same thing here.
As always, I think it will come down to :
- Generating a H264 sample frame
- Looking at the documentation about how to send this to the driver
- Get the result
But everytime I think about the 2 first steps, I'm like... "Ugh... do I really have to do this ?".
If that's still the case with the 5.7, I'll try to build a test framework.
Quite frankly, I looked at the FFMPEG patches and I still don't know how the FFMPEG select the right decoder in the first place.
As with all big projects, there might be a few "magic tricks" here and there to do the whole auto-selection of each component with the least amount of code.
And that's without counting the fact that "ffmpeg -hwaccels" list another kind of "hwaccels" so you won't know anything based on that output.
I also heard there were a "libva" library built around V4L2 request system. I guess this might worth a try, if it still exists and is still developed.
-
On 4/15/2020 at 5:29 AM, AgentCasey said:
First question first. I ran armbianmonitor after it happned the last time which was three days ago. It doesn't happen frequently. I think I may have found a working theory on what may be causing it. More on that later. It happens over a stretch of time, not frequently, so no not after 30 minutes or intermittently, so no there is no noticeable pattern but there may be one that I'm not noticing. The last time it happened I was up for 38 days. Nothing will bring the screen back, not even scripts that I've written to wake up some screens. When I ssh the machine is still working which is good because I can restart it in an orderly way. Yes, I'm using Xfce there is no screensaver software running and neither is there any screen locking software running either.
Does that happen when letting the screen on a console for a while? No, I work in the console often running tmux, it's only seems to happen when I'm running X. Now I think I have a clue as to why this has recently been happening. As you may be aware, the Rock64 board has no Bluetooth, therefore I've been using a dongle that I picked up on the Pine64 Store when I bought the first board. It, the dongle has been acting erratically, at first it would identify devices but would fail to pair or connect to them. This started in January. I would just remove the device from the list of devices and scan for devices again and that seemed to work. No the dongle is getting worse it no longer recognizes devices that it once did. I suspect that this Bluetooth dongle may be at the heart of my malfunctions. It's just a hunch. I've ordered new ones and have removed the device to see if my theory holds water. If indeed, the problem presents itself when the dongle is removed then I can eliminate it as the culprit and think about finding new ones.
Ok...
If that was the Bluetooth driver, the screen going black should also happen when displaying a console.
There might be some bugs in the Wifi or Bluetooth driver as noted with the WARNING in the logs, about the nl80211_send_chandef
But that might just be due to some broken channel configuration : https://elixir.bootlin.com/linux/v5.4.28/source/net/wireless/nl80211.c#L3159
Hmm... If you can try it, try disabling X11 and run a Wayland compositor using DRM/KMS directly like weston and see if that also occurs with Wayland compositors.
Note that weston is very limited (no, seriously, it's more limited than twm), so it's only good for a little try. I don't know if mutter will work.
Also, are you using the official Power supply ? No power issue these days in your vicinity ?
-
@AgentCasey Was armbianmonitor launched after the issue or before the issue ?
I guess that unplugging / plugging a screen back doesn't work too ? Same thing when executing chvt 1 from SSH ?
Is there a recurring pattern ? Like it does it after 30 mins or one hour ?
Which desktop are you running ? Xfce ? Is there a screensaver software running (like xscreensaver) ?
Does that also happen when letting the screen on a console for a while ?
Could you try to boot once with ignore_loglevel passed to the kernel (Mind you, the dmesg spam might be atrocious with that amount of logs) ?
-
Ah, I didn't know it was already merged.
So the actual patch should be accessed from here : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/panfrost/panfrost_mmu.c?id=eb9d8ddbc107d02e489681f9dcbf93949e1a99a4
-
Ow. Let's see if anyone can run SuperTuxKart... Or a WebGL benchmark for a change ?
Testing HDMI with Tinkerboard (and others RK3288)
in Tinkerboard
Posted
If anyone has troubles with HDMI when using 5.x kernels, and has enough skills to recompile an armbian, give this a try : https://github.com/Miouyouyou/build
And then either answer here, or in the bug report : https://github.com/armbian/build/pull/1887