9 replies to this topic

[Smaky]

After a couple of weeks running Emby Server beta 4.2.0.24 on my OS6 Upgraded ReadyNAS Ultra 6 Plus I have faced a couple of ocassions where the NAS becomes unresposive.

 

Upon review of the logs prior to the "crash" - as I had to hard boot the NAS after it became unresponsive, I am seeing several entries such as these in the kernel.log of the NAS:

 

Jul 04 18:16:18 ReadyNAS6Ultra kernel: ------------[ cut here ]------------
Jul 04 18:16:18 ReadyNAS6Ultra kernel: WARNING: CPU: 0 PID: 22335 at fs/btrfs/extent-tree.c:7282 btrfs_free_extent+0x49/0xe9()
Jul 04 18:16:18 ReadyNAS6Ultra kernel: Modules linked in: nv6lcd(O) vpd(PO)
Jul 04 18:16:18 ReadyNAS6Ultra kernel: CPU: 0 PID: 22335 Comm: EmbyServer Tainted: P        W  O    4.4.178.x86_64.1 #1
Jul 04 18:16:18 ReadyNAS6Ultra kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080014  07/26/2010
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  0000000000000000 ffff88009a0ff938 ffffffff883623e6 0000000000000000
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  0000000000000009 ffff88009a0ff970 ffffffff880dbe55 ffffffff8828301e
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  0000000000013907 0000000000001000 ffff88005b09fb58 ffff8800a7af4000
Jul 04 18:16:18 ReadyNAS6Ultra kernel: Call Trace:
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff883623e6>] dump_stack+0x4d/0x63
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff880dbe55>] warn_slowpath_common+0x8f/0xa8
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff8828301e>] ? btrfs_free_extent+0x49/0xe9
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff88062feb>] warn_slowpath_null+0x15/0x17
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff8828301e>] btrfs_free_extent+0x49/0xe9
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff882acc09>] __btrfs_drop_extents+0xb2e/0xc85
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff882d4122>] btrfs_log_changed_extents+0x2ad/0x4fb
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff882d4e0c>] btrfs_log_inode+0xa9c/0xc2e
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff8807e2be>] ? default_wake_function+0xd/0xf
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff8808de2f>] ? autoremove_wake_function+0xd/0x2f
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff882d5b68>] btrfs_log_inode_parent+0x27b/0x733
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff880de31a>] ? __filemap_fdatawrite_range+0xbe/0xca
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff88298b8d>] ? wait_current_trans.isra.9+0x1d/0xdf
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff88297815>] ? join_transaction.isra.3+0x20/0x3ac
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff882d6e58>] btrfs_log_dentry_safe+0x55/0x70
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff882ae961>] btrfs_sync_file+0x226/0x2da
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff881416d2>] vfs_fsync_range+0x86/0x95
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff8811d08c>] ? vfs_write+0x152/0x160
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff881416f8>] vfs_fsync+0x17/0x19
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff88141726>] do_fsync+0x2c/0x45
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff8814192d>] SyS_fsync+0xb/0xf
Jul 04 18:16:18 ReadyNAS6Ultra kernel:  [<ffffffff888e43ca>] entry_SYSCALL_64_fastpath+0x1e/0x8e
Jul 04 18:16:18 ReadyNAS6Ultra kernel: ---[ end trace fc8abb8082935d98 ]---

For now, I am waiting the NAS to Resync (a couple of days) after the hard-boot I had to perform and will wait a few days with Emby disabled to validate if this is truly related to this situation. Messages like the above occur continuously for about 3 hours until I finally noticed the NAS was not responsive and I ended up hard-booting it.

 

 

[Luke]

Server log from that time?

[Smaky]

Not sure how to collect the logs from the NAS. I stopped the server as I do not want to risk another freeze from it. It took a whole day to have it resynched. I have the logs from the NAS and may be able to ssh to the NAS to collect the logs from emby. Only not sure where they reside.

[Smaky]

Ok.. think I found them. This is the log... the HW detection file is just after I reboot the NAS (and the service restarted automatically).

 

Attached Files

•  embyserver-63697870920.txt   3.69MB   3 downloads
•  hardware_detection-63697871009.txt   116.67KB   0 downloads

[Luke]

Please try removing these plugins and then see if the issue persists:

	CoverArt 4.1.3.0
	Dlna 1.0.20.0
	ListenBrainz 1.0.1.0
	Movie Theme Songs 1.6.3.0
	Movie Theme Videos 1.6.3.0
	Open Subtitles 1.0.17.0
	Playback Reporting 1.5.1.0
	Statistics 2.0.10.2
	Theme Songs 1.6.3.0
	TuneIn 1.2.2.0
	TV Theme Videos 1.6.3.0

Thanks.

[Smaky]

Ok.. will wait for a few days with no apps enabled on the NAS, just to rule out this might be something unrelated to Emby. After that I will re-enable it an test. Thanks for your fast response.

[Luke]

Great, thanks.

[Smaky]

It's been five days since my NAS acted up. Since then I have run several HDD tests (both within the ReadyNAS web console and directly from an SSH console). So far, no lockups have presented.. and the NAS has been pretty stable. I am letting the NAS to have Emby disabled for one more week before I reenable it again just to give it more time to exhibit any issues before turning Emby back on. 

 

There have been no other errors reported so far in the ReadyNAS logs.

[Smaky]

Unfortunately, after having monitoring my NAS for almost a month with emby disabled, only a couple of days after re-enabling it, my NAS became unresponsive and once I had to reboot it I noticed the array was degraded with one HDD offline because of a failre. Long story short, I had to replace that disk with a new one.. and wait for the array to rebuild. After that -and back with Emby disabled- the NAS has been behaving properly since then (a few days ago).

 

I cannot say Emby is the culprit here as I have not yet found a direct link of the failure to some activity (heavy if you will) that may have been caused by Emby that ended up triggering the HDD to fail. I have opened a thread in Netgear Comunity's web site several weeks ago seeking out for advice. 

 

If I ever get any real data that links failure of the NAS to Emby I will post more feedback on this here.

 

For the time being.. back to monitoring the NAS looking for any signals of HW failure 

[Luke]

Let us know how you get on.