jdog09

It has been running perfect and none of the LinkUp/Down messages in the log since 7/7. If I tried the other build, usually would be hosed up before it could complete a parity check on 9TB.

It has been longer than any other after 12a release and still stable on the RealTek Issue....

uRaid 5.0rc3 can't even get through a parity check before having an upstable NIC connection.. This is a trace from rolling back to Beta 14.. Last one still works.. un 3 18:35:31 stadiumNAS kernel: ------------[ cut here ]------------ Jun 3 18:35:31 stadiumNAS kernel: WARNING: at net/core/dev.c:3827 net_rx_action+0x78/0x12a() Jun 3 18:35:31 stadiumNAS kernel: Hardware name: EP45-UD3P Jun 3 18:35:31 stadiumNAS kernel: Modules linked in: md_mod xor pata_jmicron jmicron r8169 ahci libahci i2c_i801 i2c_core [last unloaded: md_mod] Jun 3 18:35:31 stadiumNAS kernel: Pid: 1645, comm: nfsd Tainted: G W 3.1.1-unRAID #1 Jun 3 18:35:31 stadiumNAS kernel: Call Trace: Jun 3 18:35:31 stadiumNAS kernel: [] warn_slowpath_common+0x65/0x7a Jun 3 18:35:31 stadiumNAS kernel: [] ? net_rx_action+0x78/0x12a Jun 3 18:35:31 stadiumNAS kernel: [] warn_slowpath_null+0xf/0x13 Jun 3 18:35:31 stadiumNAS kernel: [] net_rx_action+0x78/0x12a Jun 3 18:35:31 stadiumNAS kernel: [] __do_softirq+0x6b/0xe5 Jun 3 18:35:31 stadiumNAS kernel: [] ? irq_enter+0x3c/0x3c Jun 3 18:35:31 stadiumNAS kernel: [] ? irq_exit+0x32/0x53 Jun 3 18:35:31 stadiumNAS kernel: [] ? do_IRQ+0x7c/0x90 Jun 3 18:35:31 stadiumNAS kernel: [] ? common_interrupt+0x29/0x30 Jun 3 18:35:31 stadiumNAS kernel: [] ? csum_partial_copy_generic+0x6c/0x100 Jun 3 18:35:31 stadiumNAS kernel: [] ? tcp_sendmsg+0x2a3/0x915 Jun 3 18:35:31 stadiumNAS kernel: [] ? inet_sendmsg+0x6f/0x78 Jun 3 18:35:31 stadiumNAS kernel: [] ? sock_sendmsg+0xa5/0xbb Jun 3 18:35:31 stadiumNAS kernel: [] ? blk_finish_plug+0xd/0x28 Jun 3 18:35:31 stadiumNAS kernel: [] ? do_sync_readv_writev+0x84/0xb7 Jun 3 18:35:31 stadiumNAS kernel: [] ? fsnotify+0x1ad/0x1c7 Jun 3 18:35:31 stadiumNAS kernel: [] ? kernel_sendmsg+0x28/0x37 Jun 3 18:35:31 stadiumNAS kernel: [] ? sock_no_sendpage+0x45/0x58 Jun 3 18:35:31 stadiumNAS kernel: [] ? tcp_sendpage+0x32/0x66 Jun 3 18:35:31 stadiumNAS kernel: [] ? do_tcp_sendpages+0x490/0x490 Jun 3 18:35:31 stadiumNAS kernel: [] ? inet_sendpage+0x82/0x9c Jun 3 18:35:31 stadiumNAS kernel: [] ? inet_dgram_connect+0x5e/0x5e Jun 3 18:35:31 stadiumNAS kernel: [] ? kernel_sendpage+0x1a/0x2d Jun 3 18:35:31 stadiumNAS kernel: [] ? svc_send_common+0x41/0xdf Jun 3 18:35:31 stadiumNAS kernel: [] ? svc_sendto+0x112/0x15f Jun 3 18:35:31 stadiumNAS kernel: [] ? nfsd_cache_update+0x88/0x10f Jun 3 18:35:31 stadiumNAS kernel: [] ? nfs3svc_encode_renameres+0x3b/0x3b Jun 3 18:35:31 stadiumNAS kernel: [] ? nfsd_cache_update+0xb3/0x10f Jun 3 18:35:31 stadiumNAS kernel: [] ? auth_domain_put+0x10/0x42 Jun 3 18:35:31 stadiumNAS kernel: [] ? svcauth_unix_release+0x15/0x4d Jun 3 18:35:31 stadiumNAS kernel: [] ? svc_authorise+0x28/0x2e Jun 3 18:35:31 stadiumNAS kernel: [] ? svc_tcp_sendto+0x32/0x83 Jun 3 18:35:31 stadiumNAS kernel: [] ? svc_send+0x53/0x88 Jun 3 18:35:31 stadiumNAS kernel: [] ? svc_process+0xff/0x112 Jun 3 18:35:31 stadiumNAS kernel: [] ? nfsd+0xd1/0x108 Jun 3 18:35:31 stadiumNAS kernel: [] ? nfsd_svc+0x131/0x131 Jun 3 18:35:31 stadiumNAS kernel: [] ? kthread+0x62/0x67 Jun 3 18:35:31 stadiumNAS kernel: [] ? kthread_worker_fn+0x10a/0x10a Jun 3 18:35:31 stadiumNAS kernel: [] ? kernel_thread_helper+0x6/0xd Jun 3 18:35:31 stadiumNAS kernel: ---[ end trace 85ce947744be7903 ]--- Jun 3 18:35:31 stadiumNAS kernel: r8169 0000:04:00.0: eth0: link up

Here is the Syslog.. Didn't even get through the parity check... A lot of R8139 Messages Unraiderro20120601.txt

I am down again too... When I get home and physically reboot, I can take a picture of stack trace on Monitor. I will open a tail -f on Syslog and let it run....

Likewise, RC14 worked like a champ... I will snap a picture of the Stack traces on the monitor next time it goes toes up... I just rebooted so it will be a few days..

Any update on the NFS issue? I have used Unraid for a couple of years as a NFS store for VMWare and XenCenter. I can't keep a NFS from going stale. Usually 12-24 hours something happens. I drop and remount the client (XenCenter) and I can restart my VM. The NFS mount point on Private Only.. NO SMB or AFP enabled. Private Security Rule 192.168.1.199(rw,no_root_squash) Any other ideas..

There is some type of problem with NFS Stale issues on client side. I have used VMWare and XenServer as NFS clients for the past couple of years and NFS has been flawless. Now with 5.0 it is too unstable. Anyone have any suggestions?

MTA is exchange 2007.. What are you testing with? I always received the emails from unraid_notify.. Just no body.. Subject only..

If you are going to stick with unraid_notify, please throw a \n not a \r\n after the existing one in your packaging of your tar ball.

All three addresses are set to the same Email Address....

I figure this one out... It is a problem withe unraid_notify script. I added an additional \n after subject on output creation and all is good now.

Getting this message alot... Sep 5 11:58:20 stadiumNAS unmenu[13488]: bad method - 159 174 1313 940 10 2 96 0 0 940 940159- Sep 5 11:59:01 stadiumNAS last message repeated 106 times Sep 5 12:00:07 stadiumNAS last message repeated 211 times Any ideas?

Ant, Looks like my tweak to remove AuthMethod, etc from the ssmtp.conf files works and I get an email on my internal Exchange MTA. However, on-boot I see a message generated and accepted from my MTA but no message delivered to my mailbox. I run the Configuration Test and do immediately receive the test message with Subject and Body. Next I go to Notification screen and push the test and immediately receive an email with Subject only. However I see in the log where the unraid information was collected.

Yes, I am talking about LOGIN/MD5. Since I host my own MailServer domain and Unraid is inside my FW no need to Auth. Others may have a similar request. Keep up the good work.