Jump to content

Myy

Members
  • Posts

    365
  • Joined

  • Last visited

Posts posted by Myy

  1. 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) )

  2. 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.

  3. 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. :D

  4. 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.

  5. 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.

  6. 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.

  7. 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 ?

  8. @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) ?

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines