Bug NFS failure after resume from standby | Context timeout ->reinit
#1
Hi,

I switched from SMB to NFS for performance gain which works perfect.

But after resuming from Standby(one hour or more) i can't browse my NFS shares because the NFS-server "session" is timeouted but XBMC thinks its still valid.
And since NFS is UDP (stateless) there is no validation mechanism which ensures a reconnect.

I looked into the code an maybe it's a good idea to call a NFSConnection:Big GrineInit() at OnSleep or OnWake to kill all NFS-context. So that after resume XBMC will automaticly reastablish a NFS-"session" Wink

Can anyone(dev) look into this ?

Thank you
Reply
#2
I have the same problem. Good suggestion, wonder if it's being included in an upcoming release?
Reply
#3
Sad 
Hi,

same problem here with latest official release.
I have to reboot after a resume from standby (mysql connectivity OK, but NFS down)

Gigius
Reply
#4
Confirming with OpenELEC 3.0.x on x64 with FreeNAS 8.3.x - switching to OS NFS mounts is another solution. Always have to reboot after a suspend to restore NFS access when using XBMC NFS mounts.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#5
This is a very widespread issue and I've never seen so few interest from the devs to fix this...

Similar threads:
https://github.com/OpenELEC/OpenELEC.tv/issues/1178
http://openelec.tv/forum/65-storage/4459...and-higher
http://trac.xbmc.org/ticket/13286
http://openelec.tv/forum/76-network-file...or-wake-up
http://forum.xbmc.org/showthread.php?tid=157848
http://openelec.tv/forum/69-network/5995...from-sleep
http://openelec.tv/forum/65-storage/4459...and-higher
http://openelec.tv/forum/69-network/6275...er-suspend
https://github.com/OpenELEC/OpenELEC.tv/issues/1012
https://github.com/OpenELEC/OpenELEC.tv/issues/1178
Platforms: macOS - iOS - OSMC
co-author: Red Bull TV add-on
Reply
#6
You assume it's easy to fix, or that people replying to posts indicates dev interest or not. It also appears to be a mostly OE-related problem. I can't say that I've ever had such an issue on other platforms.
Reply
#7
Lol - this is the first time i even read about it ... sorry ... *cis* (ohh and no - i won't start reading openelec forums or issue trackers ...)

Interesting that it not only affects nfs but samba too...

@upsite did you test your approach by any chance?

I think this issue might even be an OpenElec kernel thingy or something. Cause the NFS implementation already invalidates timed out contexts (every 4 mins!). So tbh i doubt that the approach upsite proposed will fix this. And the fact that smb has the same issue (which is tcp and not stateless!) makes me think its more of a driver / network stack issue.
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#8
Does weather data get pulled after sleep? (so is anything networking related working?)
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#9
I am gathering references to this problem here in the OE forum since a while:
http://openelec.tv/forum/76-network-file...or-wake-up

I am still not sure if it is a XBMC problem or an OpenELEC problem. Most references are mentioning OE though.

The most interesting part for me is that its 100% reproducable after a suspend time of quite exactly 90 seconds. If I wake up before 90 seconds SMB is working instantly. If I sleep more than 90 seconds then SMB is gone after wakeup.
Reply
#10
Well, I tested lots of different stuff and did some tests with the XBMC source code.

Here is what I currently think is happening:
It does only happen on Linux, not on Windows cause Windows is using a different SMB code (WINFileSMB.cpp). Linux uses libsmbclient. The problem seems to be that XBMC is not calling smb.Deinit() before going to suspend which makes libsmbclient go nuts upon wakeup.

After 90 seconds of idle time the SMB interface deinits itself. So the problem does not occur if there was no SMB access for 90 seconds before going to suspend. Some addons (like library watchdog) permanently keep SMB connections open so the idle time will never apply and the problem will occur on every suspend

Im still playing around with it but hopefully the above information is correct and some XBMC devs have a good idea what to do about it.
Reply
#11
I also experience the same issue but on a standard XBMC Frodo 12.2 installation (also visible on Gotham Alpha 5 I had for a while) over Ubuntu minimal (kernel 3.8.0-22-generic), so it's not just OpenElec problem.
Reply
#12
Yeah it happens on all Linux distros. If you are willing to help, I am desperately searching for someone to test a fix:
http://openelec.tv/forum/76-network-file...p?start=60

So if you are able to reproduce the issue on OpenELEC 3.1.2 I will provide a (possibly) fixed version for you to try out.
Reply
#13
Ok, so I tried with stock OpenELEC Testing - ION x86_64 Version:3.1.2 from http://openelec.tv/get-openelec/download...load/3/162 started from USB (live boot on the same machine I have my Ubuntu mini installation with XBMC). So far I tried to suspend it for 30min only and it successfully resumed NFS after waking it up. So, it looks really promising Smile Any chance for integration of the patch to the standalone XBMC soon?

My configuration:Asus EeeBox PC EB1012P connected wirelessly to NAS running OpenMediaVault.
Code:
OpenELEC:~ # lspci
00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge (rev 02)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02)
00:1d.0 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA Controller [AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
02:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2)
02:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1)
03:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
05:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)

Code:
root@nas:/# nfsstat -o net
Server packet stats:
packets    udp        tcp        tcpconn
207325     2          207323     12

Client packet stats:
packets    udp        tcp        tcpconn
0          0          0          0
Reply
#14
Well, when resuming after ~8h of hibernation on that OpenELEC I got "Could not connect to network server" error again. So I was able to reproduce it on OpenELEC 3.1.2 taken directly from their site.
Reply
#15
It might sound odd but that is a good thing since my patch in the stock OE 3.1.2 does not patch NFS. I would be confused if NFS would have been fixed in there already.
Please have a try with the image in this post:
http://openelec.tv/forum/76-network-file...t=60#79376

Thats the vanilla 3.1.2 version + NFS-patch.
Reply

Logout Mark Read Team Forum Stats Members Help
NFS failure after resume from standby | Context timeout ->reinit1