[naloj]

Same problem. Nothing interesting in kodi logs when this happens. Hoping Openelec 5.0.1 brings more stability.

I had a total freeze w/Asus Chromebox + OpenELEC 5.0.1 about 2.5 minutes into playing a 720p mp4 video. Totally frozen; wouldn't respond to pings (ethernet).
Rebooted to see if I could reproduce and video playback was fine for 30 minutes straight.

Not sure how to debug such a thing, maybe connect a second display and direct kernel messages to it?

I'm Getting it much more frequently than you. I'll have to test a few files but with one one file I tried to play, it happened 4 times after reboot. I kept trying in the same location of the video

I just got my Chromebox on Saturday and setup on Sunday so I haven't had much time to mess with it.

Last night:

720p h264 mkv via smb played ok for 42 mins.
720p h264 mkv via smb had to buffer twice and was a tad slow about it but was otherwise ok for 42 mins.
Tried to play something via ServerWMC and connection failed. Pretty sure ethernet dropped again. GF played back show via xbox 360 fine.

This morning:

Tried to play a show for my daughter; network down. Verified network was up according to the openelec interface but couldn't ping.
Rebooted, played 480p h264 mp4 ok for 7 mins.
Played second 480p h264 mp4 show; froze after 2 mins.

UI was unresponsive to mouse/kbd input for a few minutes. Was about to reboot it when I saw that the default 3 min screensaver dim kicked in. UI was responsive again. Network came back on it's own.

I did ssh in after the network came back on it's own and no errors or messages of any kind in the dmesg buffer. So it's not the link going up/down I don't think (still need to verify link lights on switch/NIC).

I had an i5 NUC (D54250WYKH1) connected to the same switch with the same cable and it never had any network playback issues. (ServerWMC, Netflix, Amazon Prime Video). Decided to downgrade since it was so overpowered for what I was doing.

I'm at work now and couldn't ssh or ping it. Then tried again a few minutes later and it's up. Really weird.

I saw there's a fix for Atheros 93xx cards freezing the whole system in the kernel changelog for 3.8.15.

commit 587a7ba37c5c1e53731b6b48dcde7b17a682b5ac
Author: Alex Williamson <[email protected]>
Date: Thu Jan 15 18:17:12 2015 -0600

PCI: Mark Atheros AR93xx to avoid bus reset

commit c3e59ee4e76686b0c84ca8faa1011d10cd4ca1b8 upstream.

Reports against the TL-WDN4800 card indicate that PCI bus reset of this
Atheros device cause system lock-ups and resets. I've also been able to
confirm this behavior on multiple systems. The device never returns from
reset and attempts to access config space of the device after reset result
in hangs. Blacklist bus reset for the device to avoid this issue.

[bhelgaas: This regression appeared in v3.14. Andreas bisected it to
425c1b223dac ("PCI: Add Virtual Channel to save/restore support"), but we
don't understand the mechanism by which that commit affects the reset
path.]

[bhelgaas: changelog, references]
Link: http://lkml.kernel.org/r/20140923210318....c.maya.org
Reported-by: Andreas Hartmann <[email protected]>
Tested-by: Andreas Hartmann <[email protected]>
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Bjorn Helgaas <bhelgaas@Google.com>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b01f14468da12c2e548dc965d522b12d51d4be9b
Author: Alex Williamson <[email protected]>
Date: Thu Jan 15 18:16:04 2015 -0600

PCI: Add flag for devices where we can't use bus reset

commit f331a859e0ee5a898c1f47596eddad4c4f02d657 upstream.

Enable a mechanism for devices to quirk that they do not behave when
doing a PCI bus reset. We require a modest level of spec compliant
behavior in order to do a reset, for instance the device should come
out of reset without throwing errors and PCI config space should be
accessible after reset. This is too much to ask for some devices.

Link: http://lkml.kernel.org/r/20140923210318....c.maya.org
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Bjorn Helgaas <bhelgaas@Google.com>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Card in my Asus Chromebox is a 9462 though but I still find it very suspicious.

Going to pull the card and see if that helps any. If not will try to load Arch on there so I can mess around a bit when it happens again.

EDIT: Forgot to mention the USB devices I have attached which may be relevant in finding some sort of commonality:

- Logitech unifying receiver (via usb extension cable for K400)
- FLIRC (not setup/used yet)
- Turtle Beach soundcard (not setup/used yet)