Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
xbian crashes on Cubox-i when viewing photos #850
I'm able to reproduce this issue, but being unsure what's causing it. No idea if this is Cubox/Hummingboard issue or Kodi issue or a combination of it.
Strange thing is, I have defined two pictures shares, both pointing to same picture folder on my server, containing more than 800 pics (no subfolders). The first one is Samba share, the second one is a sftp connection.
When I access first share (the Samba share), system always reboots and getting Kernel OOPs something like that:
However, accessing share 2 (the sftp share) is currently working well, no reboot and I'm able to show pictures correctly - but, I have to wait until thumbnails are displayed. If I want to open picture before thumbnail is displayed, Kodi does not responding anymore. So, seems we have 2 issues, not only one.
AFAIR, it is enabled per default. I also used it for a while some times ago
thanks for trying to repro this issue and I am glad, that I am not the only one who is seeing it (i.e. my hardware is not broken).
Correct, I am running stretch.
I have the pictures on an nfs share, I think I had them initially on the local SD card, but after the cubox-i crashed I moved them to the NFS share.
What I found: If I use the kodi filemanager, I can view the pictures w/o issues.
Since kodi is not running as root, I assume it is at least not only a kodi issue.
I will later try to hook up a serial console to get the last messages from the kernel when it crashes...(assuming that it does for now)
For me it just takes a little longer to see the crash. When I start the slideshow it crashes e.g. on the second photo again. It is an improvement, since before it crashed much earlier.
I think the real problem needs to be at system level, otherwise the kernel would not crash, but a userspace application would segfault.
Hmmm....interesting, seems that small things make a real difference. I have the pics on an NFS share.
I captured the kernel oops message on the serial console:
U-Boot SPL 2013.10-rc4-gd126ab8 (Jun 28 2017 - 18:28:20)
Yeah, and probably network (I'm using WLAN) and server performance. Can test NFS share and ethernet connection at weekend.
I see, there is kernel Oops and this is generating kernel panic and auto reboot after one second. Maybe not good idea, RPI configs and my server config does not generate panic and reboots when Oops occurs.
I think it would be good to get some help from somebody with more kernel expertise and try to understand why it crashes.
Can you tell if xbian uses a solid-run kernel, seems they are improving it constantly, e.g.
Or is a debian kernel the base, which has additional patches?
I checked with an ARM kernel developer, he says this is a bug in the proprietary GPU driver (so do not feel save, the issue can come back anytime to you ;-)
Since the cubox-i has excellent mainline support including graphics, he recommends to test the mainline kernel (4.12 or a 4.13rc) with the etnaviv driver.
linux-image-4.12.0-1-armmp is in sid (and eventually in backports).
Have you ever done that?
I know. Made some tests again today, and I can confirm that using nfs share inside Kodi, kernel crashes. But NOT when mounting NFS share by kernel (usually I let kernel mount shares by autofs), only when libnfs8 is used by Kodi kernel crashes.
No, unfortunately I do not have technical background (and time) to do that.
I don't think that this will work (there are a lot of imx specific Kodi and Kernel patches.