xbian crashes on Cubox-i when viewing photos

[rdorsch]

Hi,

my xbian installation crashes (system restarts) when I view photos. Unfortunately, I do not see any log. I could attach a serial console, has xbian enabled that by default?

Are there any other useful debug information?

Thanks
Rainer

[mkreisl]

@rdorsch
Are you running Debian Jessie or Stretch (I suppose Stretch, I know you from IRC)

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:

Message from syslogd@kmxbimx at Aug 20 12:47:30 ...
 kernel: [45966.879110] Code: ea20 0003 f3bf 8f4f (ee07) 0f3a 

Message from syslogd@kmxbimx at Aug 20 12:49:09 ...
 kernel: [   89.524385] Internal error: Oops - BUG: 817 [#1] PREEMPT SMP THUMB2

Message from syslogd@kmxbimx at Aug 20 12:49:09 ...
 kernel: [   89.638956] Process kodi.bin (pid: 3160, stack limit = 0xd4734218)

Message from syslogd@kmxbimx at Aug 20 12:49:09 ...
 kernel: [   89.645520] Stack: (0xd4735cf0 to 0xd4736000)

Message from syslogd@kmxbimx at Aug 20 12:49:09 ...
 kernel: [   89.650155] 5ce0:                                     80116005 d95a2ffc 00000000 8011124d

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.

I could attach a serial console, has xbian enabled that by default?

AFAIR, it is enabled per default. I also used it for a while some times ago

[rdorsch]

Hi Manfred,

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)

Thanks
Rainer

[mkreisl]

@rdorsch

Seems to be fixed with 17.4. At least on my test system, this issue has gone after merging recent commits from @mk01

Please update to Kodi 17.4 (you have to update cec packages also) and test again

[rdorsch]

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.

[mkreisl]

Hmmm, that's weird.

Slideshow works like a charm here (Samba share, about 800 pics). Tested two different kernels, randomize display or not, does not make any difference

[rdorsch]

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:
[38375.425565] Internal error: Oops: 805 [#1] PREEMPT SMP THUMB2
[38375.425598] Modules linked in: joydev mousedev input_leds hid_logitech_hidpp brcmfmac brcmutil hid_logitech_dj cfg80211 ir_lirc_codec lirc_dev rc_rc6_mce gpio_ir_recv uio_pdrv_genirq uio ft
[38375.425608] CPU: 0 PID: 2287 Comm: kodi.bin Not tainted 4.8.15+rt9+ #1
[38375.425610] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[38375.425614] task: a8e53400 task.stack: a216a000
[38375.425637] PC is at v7_dma_clean_range+0x20/0x32
[38375.425647] LR is at __dma_page_cpu_to_dev+0x25/0x74
[38375.425653] pc : [<80116022>] lr : [<801111fd>] psr: 08070033
[38375.425653] sp : a216bcd8 ip : 00000002 fp : 80c06f04
[38375.425656] r10: 3df2c000 r9 : 00004562 r8 : 00000000
[38375.425660] r7 : 04562000 r6 : ab558000 r5 : 80116065 r4 : 00000000
[38375.425665] r3 : 0000001f r2 : 00000020 r1 : 74562000 r0 : 70000000
[38375.425672] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user
[38375.425676] Control: 50c5387d Table: 324dc04a DAC: 00000055
[38375.425680] Process kodi.bin (pid: 2287, stack limit = 0xa216a218)
[38375.425684] Stack: (0xa216bcd8 to 0xa216c000)
[38375.425689] bcc0: 80116065 a3b6f180
[38375.425695] bce0: 00000000 8011124d a82aecc0 a26f6b10 80ce7240 8064453f 00000707 00000000
[38375.425702] bd00: 00000001 a2c8e180 ab72fe40 a26f6b00 a8c0c000 a216be24 a26f6b10 a82aecc0
[38375.425707] bd20: 00000000 a2c5c600 00000000 8064d181 a26f6b10 a26f6b14 a216bd40 8013a50b
[38375.425713] bd40: a3755e50 a9d1a64c a216bd88 a216bdf8 00000000 a8c0c000 00000001 a26f6b00
[38375.425719] bd60: a216a000 806478bd 00000000 8015112d a216a000 80151135 00000000 00000000
[38375.425725] bd80: 00000000 00000000 000008ef a2c8e634 00000001 a216bd90 a216bef0 7eb4f050
[38375.425731] bda0: 00000000 00000000 a216bef0 a216a000 a216a000 80c03508 a92dd400 a2c50540
[38375.425737] bdc0: 00007530 00000018 a216a000 a2c5c600 00000000 8064238b 7eb4ee00 00000000
[38375.425743] bde0: 000000f8 00000000 7eb4ee00 00000000 000000f8 00000000 0000000d 00000001
[38375.425748] be00: 7eb4ee70 7eb4ee64 00000036 7658525c 0000ff03 00000000 a26f6b00 00000000
[38375.425754] be20: 00000000 7662d0d4 44870000 7660f198 0000000f 76683110 00000003 58cd84a0
[38375.425760] be40: 58cd84e0 58cd84e0 00000000 00000001 00000003 58e32618 7eb4f138 00000000
[38375.425767] be60: 58e32618 7eb4ef08 00000002 7662dca4 00000000 7eb4ef38 44870000 765b08a0
[38375.425772] be80: 7eb4ef58 7660f198 00000006 7eb4eed8 0000001b 000002bd 00000001 58c3dc88
[38375.425778] bea0: 7eb4ef58 7660f198 00000000 7660f198 00000000 7eb4eed0 44870000 7660f198
[38375.425784] bec0: 000000d4 58c3dc88 00000000 7660f448 7eb4ef08 7660b1e8 00000000 765a9fe0
[38375.425790] bee0: 000000f8 58c3dc88 593e18a0 00000000 593d0718 0004080f 7eb4edc0 a9285920
[38375.425796] bf00: 00000018 00007530 00000018 a216a000 a2c5c600 801ff10f b44fd3a7 0000024d
[38375.425802] bf20: ffffffff 00000000 00000000 00000000 000095e7 00000000 b451f01a 00000000
[38375.425807] bf40: 000095e7 00000000 069a9d93 00000000 00000000 a216bf90 00000004 80206f5d
[38375.425813] bf60: a2c5c600 80206f5d 00002710 a2c5c601 7eb4edc0 a2c5c600 00007530 00000018
[38375.425819] bf80: a216a000 00000000 00000000 801ff679 00002710 7660f198 00007530 00000036
[38375.425825] bfa0: 80106c04 80106a41 00002710 7660f198 00000018 00007530 7eb4edc0 58c44698
[38375.425831] bfc0: 00002710 7660f198 00007530 00000036 00000000 00000000 593e18c8 00000000
[38375.425837] bfe0: 7660b41c 7eb4edac 765f6bfc 759b8766 28070030 00000018 44ed9007 304623b1
[38375.425858] [<80116022>] (v7_dma_clean_range) from [<801111fd>] (__dma_page_cpu_to_dev+0x25/0x74)
[38375.425878] [<801111fd>] (__dma_page_cpu_to_dev) from [<8064453f>] (gckOS_LockPages+0xc7/0x260)
[38375.425896] [<8064453f>] (gckOS_LockPages) from [<8064d181>] (gckVIDMEM_Lock+0x65/0x264)
[38375.425913] [<8064d181>] (gckVIDMEM_Lock) from [<806478bd>] (gckKERNEL_Dispatch+0x809/0xd08)
[38375.425923] [<806478bd>] (gckKERNEL_Dispatch) from [<8064238b>] (drv_ioctl+0xcf/0x1c8)
[38375.425940] [<8064238b>] (drv_ioctl) from [<801ff10f>] (do_vfs_ioctl+0x7f/0x5c0)
[38375.425950] [<801ff10f>] (do_vfs_ioctl) from [<801ff679>] (SyS_ioctl+0x29/0x48)
[38375.425966] [<801ff679>] (SyS_ioctl) from [<80106a41>] (ret_fast_syscall+0x1/0x4a)
[38375.425977] Code: ea20 0003 f3bf 8f4f (ee07) 0f3a
[38375.823571] ---[ end trace 0000000000000002 ]---
[38375.828352] Kernel panic - not syncing: Fatal exception
[38375.828371] CPU1: stopping
[38375.828381] CPU: 1 PID: 1294 Comm: syslog-ng Tainted: G D 4.8.15+rt9+ #1
[38375.828384] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[38375.828426] [<8010dc81>] (unwind_backtrace) from [<801098b9>] (show_stack+0x11/0x14)
[38375.828442] [<801098b9>] (show_stack) from [<803cdb27>] (dump_stack+0x73/0x80)
[38375.828453] [<803cdb27>] (dump_stack) from [<8010c801>] (handle_IPI+0x281/0x2c4)
[38375.828461] [<8010c801>] (handle_IPI) from [<8010131f>] (gic_handle_irq+0x6f/0x74)
[38375.828469] [<8010131f>] (gic_handle_irq) from [<8010a5b5>] (__irq_usr+0x55/0x80)
[38375.828473] Exception stack(0x94d61fb0 to 0x94d61ff8)
[38375.828479] 1fa0: 76c906e4 00000000 00000001 000019f8
[38375.828485] 1fc0: 00000000 766a6e70 00000180 76cbb637 7eadb930 00000000 00000000 00000000
[38375.828490] 1fe0: 76cce010 766a6228 76bf8a87 76bf5050 40010030 ffffffff

U-Boot SPL 2013.10-rc4-gd126ab8 (Jun 28 2017 - 18:28:20)
Boot Device: SD1
spl: error reading image u-boot.img, err - -1
Load image from RAW...

[mkreisl]

Hmmm....interesting, seems that small things make a real difference. I have the pics on an NFS share.

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.

[rdorsch]

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.

http://forum.solid-run.com/viewtopic.php?t=1156&p=22414#p22414

?

Or is a debian kernel the base, which has additional patches?

[rdorsch]

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?
Do you see a reason, why mainline is a problem?

[mkreisl]

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 ;-)

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.

Have you ever done that?

No, unfortunately I do not have technical background (and time) to do that.

Do you see a reason, why mainline is a problem?

I don't think that this will work (there are a lot of imx specific Kodi and Kernel patches.
And, not sure if the mechanism of kernel fail booting will work together with mainline kernel without additional patches (when standard kernel does not boot, watchdog will reset system and kernel in /boot/fail will be used for next boot - if available)