RN104 crashed with kernal seg-fault or ???

[Jeff_D]

HI,

My RN104 stopped communicating and after I verified that it was ON but not answering I looked at the front display and all the unit said was do_exit+8d8. It was non-responsive to the power button, so I had to pull the power at the cord. Google has nothing on this except as a possible seg fault in linux. Whats wrong and whats the fix? My most recent change (yesterday) was to bind the 2 ethernet interfaces together. Else no other changes.

[mdgm-ntgr]

Which teaming mode are you using?

Which services and apps are you running?

Can you send me your logs (see the Sending Logs link in my sig)?

[Jeff_D]

Logs sent.

Corrections and additional information:

the same error display was just found with a shutdown I ordered just this eve. So the seg fault err shows as the box goes down and prevents it from going up until power is pulled and re-applied.

The OS is 6.4.2 not .2.4 as typed originally.

Teaming was adaptive load balancing, but I'm going to try changing it to Round-robin and see if it still crashes at shutdown.

Only apps running are SMB Plus and Log Analyzer.

Services are mostly file sharing (SMB, DLNA) and AV is currently Off as all the sharing is intranet only with me a the sole user.

[mdgm-ntgr]

If changing the teaming mode doesn't resolve it you may wish to try disabling Jumbo Frames as well.

[Jeff_D]

I spent almost 3 months getting FW 6.4.2 fixes to include proper support for Jumbo Frames (at 9216) on the RN104. I'm the party that got that code changed (withouout teaming). I'll be darned if I'll un-do that or that the dev's would like such a result. Now if it's broken in teaming, that's news.

Side note: with Round-Robin, and jumbo at 9216 my RN204 is fine and not seg fault's at shutdown. Odd, eh?

[Jeff_D]

after a change to Round-robin, it appears the seg-fault (?) still happens at shutdown, regardless which of these 2 teaming modes.

So it appears Jumbo Frames with teaming on the 104 is not happy. And it's OK on the 204.

I would like to request a ticket be opened for a fix to the code. Really.

Thanks,

Jeff

[mdgm-ntgr]

I suggested disabling Jumbo Frames to help isolate the cause of the problem. If the problem does not reoccur if that is disabled then that has helped to isolate what the problem is.

It is also worth noting this:

Skywalker wrote:

However, the benefits of jumbo frames on RN10x are questionable at best.  The Marvell chipset used in RN10x is not capable of doing TCP checksum or segmentation offloading on packets larger than 1600 bytes.  So you'll usually experience much better TX performance with a smaller MTU.

[Jeff_D]

I will try that tomorrow.

I'm always willing to help those helping me and more.

Sorry I didn't know what you posted about the Marvell vis-a-vis Jumbo frames. I hadn't tested yet, but all my other net devices are on Jumbo and so I needed/wanted the consistancy.

Thanks for the deep background, it's valuable.

[Jeff_D]

Can my RN204 handle Jumbo frames any better than the 104?

[mdgm-ntgr]

The RN204 is on a different ARM platform. It uses Annapurna whereas the RN104 uses Marvell. Jumbo Frames should work better with the RN204, and I think that's what you've already found in your experience?

[Jeff_D]

I won't know for a day or two. I'm refreshing my backup of 10.9Tb prior to trying the disk swap from 104 to 204 and will test later. Perhaps there's a post somewhere that could teach me about optimizing the 204 on Jumbo frames in case it too has limitations?

[mdgm-ntgr]

Optimising Jumbo Frames depends on the hardware you have and what MTU different devices on your network support.

If you're using teaming I don't think there is really any benefit to using Jumbo Frames.

[StephenB]

Of course if if crashes, that is a bug not a limitation.

Performance gains for jumbo frames come from the reduced packets-per-second processing in the devices (both the PC and the NAS).  They aren't more efficient for the network itself (network jitter actually will go up a bit because of the larger packet size).

The only way to see how much gain you get is to measure performance (in both directions) with JF on and off.  With some equipment JF actually hurts performance.

General rules:

You should check your equipment NIC configuration and make sure the MTU is set to match the device with the smallest MTU size.

You shouldn't use JF if you have a mixed fast ethernet/gigabit network.

You should confirm the path MTUs with ping after you have JF set up, just to make sure the JF packets are being delivered without fragmentation.

[Jeff_D]

Thanks StephenB

A bug is a bug!

On the other front: As it happens I have an otherwise all GigE, MTU 9000, dual NIC network for about a half-dozen systems(NASs and PCs) except on single NIC NAS. I'll have to do more investigating on the xfer rates and best settings as time allows this week.

Ultimately learning if  the Annapurna can handle Jumbo's and/or teaming and such will matter to me. Maybe I'll better see why the other brands of NAS units I have are more robust or then again...

[StephenB]

I use LACP teaming on my main NAS (a pro-6), but not the RN102 or RN202.  Both the newer NAS are for backup, and only rarely see multiple data flows.

In general I think the RN202 is fast enough to benefit from teaming (as it will deliver 100 MB/s on a single gigabit interface).  But my RN102 won't go faster than about 70 MB/s, so I don't much point to configure teaming with it.

I'm ok with my current LAN performance, so I've left Jumbo Frames disabled.  Most of my devices will run it, but the max MTU varies, and it didn't seem worth the trouble.

[mdgm-ntgr]

Using both teaming and Jumbo Frames isn't a common configuration we see with the 100 series. Indeed in the past before we released our ReadyNAS OS 6 models we didn't support NIC teaming on home models as there is typically limited benefit in a home environment.

If you're looking to exceed gigabit ethernet performance then e.g. the 210 series or better yet a business model such as the 516 would be the way to go anyway.

[rafalux]

I have the same problem, my RN104 does not reboot anymore and I have to pull the plug after every shutdown!

Can some please explain to me how to fix this??? Or do I need to throw it away?

[StephenB]

---

@rafalux wrote:

I have the same problem, my RN104 does not reboot anymore and I have to pull the plug after every shutdown!

Can some please explain to me how to fix this??? Or do I need to throw it away?

---

Please open a new thread, with more specifics on the firmware you are running, what apps you have installed, and what failure mode you are seeing (is it a kernel segment fault or something else???), 

[HelloGear]

Hello.

I encountered exactly the same error message "do_exit+8d8" shown on the front display.
It first happend when I upgraded the firmware to OS 6.4.2.
Since then, whenever I try to shutdown my RN104, I always see the error message and the shutdown cannot be completed by any means.
Once it happens, I cannot boot my RN104 in a normal way; I always have to boot it via Normal mode of the Boot Menu.
Although I cannot successfully shutdown my RN104 as described above, I can successfully reboot it from the admin web page.

In my case, it has nothing to do with teaming.

Thank you in advance for your help.

[StephenB]

I suggest sending in your logs ( http://kb.netgear.com/app/answers/detail/a_id/21543/~/how-do-i-send-all-logs-to-readynas-community-m... )

Alos PM @kohdee and @mdgm-ntgr, asking if they can take look (include a link to this thread and the subject line of your log email).

[HelloGear]

A log file sent by email.

Thank you.

[mdgm-ntgr]

Please try ReadyNASOS 6.5.0-T338 (Beta 2)

Also the snapshots on your system have not been upgraded so you should do:

# touch /.force_snapshots_upgrade

# systemctl restart readynasd

to force the upgrade.

[HelloGear]

I did both you mentioned above. However, situation seems to remain the same.
This time, the error message shown on the front display in shutting down is "do_exit+8d0", not "do_exit+8d8".
Should I send the log file again?

[mdgm-ntgr]

Was this a beta 104 unit?

[HelloGear]

I meant my RN104 showed the error message on the front display in shutting down as below:

- "do_exit+8d8" on ReadyNASOS 6.4.2
- "do_exit+8d0" on ReadyNASOS 6.5.0-T338 (Beta 2)

Obviously, upgrading the firmware affected the error message.