NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ReadyNAS 316 LCD/Touchpanel issues
So today I had an odd issue with my RN31600 in which the Netgear Logo and touch controller would remain lit up. Normally they would turn off after a few minutes but today they stayed lit for hours. A...
Pingjockey, thank you for posting about this. We may be facing the same issue here; the symptoms appear to be the same. (The LEDs on the front panel stay lit, and the buttons on the touchpanel become unresponsive.)
For us, the issue appeared on an unused RN31600 immediately after manually upgrading it from ReadyNAS OS 6.2.4 to ReadyNAS OS 6.7.0 using the downloadable image. I've done some experimenting over the past few days, and here is a short summary of what I've found.
The only two ways that I have found to reliably restore responsiveness are:
1. After the LEDs and touchpad have become unresponsive, performing a "Factory Default" via the web admin page can restore them to proper working order (wiping any user data, of course). Generally, one has to perform at least one manual powercycle after the factory default routine has finished for the LEDs and touchpad to begin working again. (Once out of four tries, I had to powercycle the unit twice before the LEDs and touchpad returned to working order.)
2. After the LEDs and touchpad have become unresponsive, performing another "Manual Install Firmware" action with the same 6.7.0 image will restore the LEDs and touchpad to working order.
Once the LEDs and touchpad are working again, they will stay working for a number of power cycles. Eventually, though, they will become unresponsive again. Once they have become unresponsive, they will generally stay in that state for subsequent power cycles. However, twice I have had the LEDs and touchpad spontaneously return to working order. Both times, they became unresponsive again after the next power cycle.
SSHing into the box, I have not been able to find anything different in the logs of the unit when it is functioning properly versus when the LEDs and touchpad are unresponsive. However, comparing the output of `dmesg` on the affected ReadyNAS with that of a brand new, unaffected RN31600 running OS 6.6.0 shows two things that worry me.
The first concerns the LPC Super I/O chip. On the unaffected OS 6.6.0 box, the dmesg log reports:
it87: Found IT8721F chip at 0xa00, revision 4
However, on the affected 0.6.7 box, we get a report of:
gpio_it87: Unknown Chip found, Chip 8721 Revision 4
The second concerning bit of output concerns the internal USB drive. On the unaffected OS 6.6.0 unit, the relevant lines in the dmesg log reads as:
scsi 8:0:0:0: Direct-Access SMI USB DISK 1100 PQ: 0 ANSI: 0 CCS sd 8:0:0:0: Attached scsi generic sg6 type 0 sd 8:0:0:0: [sdg] 489472 512-byte logical blocks: (251 MB/239 MiB) sd 8:0:0:0: [sdg] Write Protect is off sd 8:0:0:0: [sdg] Mode Sense: 43 00 00 00 sd 8:0:0:0: [sdg] No Caching mode page found sd 8:0:0:0: [sdg] Assuming drive cache: write through sdg: sdg1 sd 8:0:0:0: [sdg] Attached SCSI removable disk
On the affected OS 6.7.0 unit, though, we get:
scsi 8:0:0:0: Direct-Access SMI USB DISK 1100 PQ: 0 ANSI: 0 CCS sd 8:0:0:0: Attached scsi generic sg6 type 0 sd 8:0:0:0: Embedded Enclosure Device sd 8:0:0:0: Wrong diagnostic page; asked for 1 got 0 sd 8:0:0:0: Failed to get diagnostic page 0xffffffea sd 8:0:0:0: [sdg] 489472 512-byte logical blocks: (251 MB/239 MiB) sd 8:0:0:0: Failed to bind enclosure -19 sd 8:0:0:0: [sdg] Write Protect is off sd 8:0:0:0: [sdg] Mode Sense: 43 00 00 00 sd 8:0:0:0: [sdg] No Caching mode page found sd 8:0:0:0: [sdg] Assuming drive cache: write through sdg: sdg1 sd 8:0:0:0: [sdg] Attached SCSI removable disk
(All of my search results around the error message of "Failed to bind enclosure -19" bring up posts of people having trouble with external USB hard drives, or incorrectly compiled kernels circa the 3.X series.)
If anyone has an unaffected ReadyNAS running OS 6.7.0 that they are comfortable SSHing into, could you please let me know if your `dmesg` output contains the same problems as mine does? I'm trying to narrow down if this problem is a problem with the hardware in this unit, or perhaps a problem with the OS 6.7.0 release. (I hope that doesn't sound accusatory; I don't mean it that way.) I don't want to upgrade our OS 6.6.0 unit to 6.7.0 until I'm more positive that it is a hardware problem, since the release notes state that we aren't supposed to downgrade from 6.7.0. (If it is just a case of losing user data, no problem, but there are no specifics given in the release notes as to why.)
I hope this information helps anyone else that might run into this problem. I have more detailed notes about what I have and haven't tried if anyone needs them, and still have both units open for testing at the moment, too. Thank you in advance for any insight that anyone else is able to provide on this issue.
voidfunc please send in the logs for both units (see the Sending Logs link in my sig)
Thank you for replying, mdgm.
I have sent the zips of the log files for both units (in the manner specified by the page linked to in your signature) with information about them in the e-mail body.I wasn't sure if it is considered good community etiquette to also reply "in thread" after sending logs or not. I have replied so that the thread doesn't look abandoned, and I apologize if this is frowned upon or makes more "noise" for you.
Thanks again.
voidfunc wrote:
I wasn't sure if it is considered good community etiquette to also reply "in thread" after sending logs or not.
It's fine to do that, and it can be helpful to keep the community informed on progress.
StephenB, thanks for the follow up on community etiquette. I'm glad to know I wasn't committing a faux pas.
Concerning the issue at hand, it turns out that it is not limited to the OS 6.7.0 unit after all. After a sufficient number of power cycles, the brand-new RN31600 unit running OS 6.6.0 has shown similar symptoms. There has been no significant change to the output of `dmesg` on the OS 6.6.0 unit, though, so the issues found in the log files for the 6.7.0 unit are most likely unrelated. (I'm still worried about them, of course, so I may start a separate thread about them.)
In addition to the "panel-LEDs-stuck-on-and-touch-panel-unresponsive" state that was seen on the 6.7.0 unit, sometimes the 6.6.0 unit will get itself into an "inverted" state. The touch panel works somewhat (the OK button is almost impossible to press at these times) but the panel LEDs function in a manner opposite to how they should. They stay lit at full brightness until you touch a button. When you touch a button, that LED goes dark. While you are touching the button, the LED behind the "Netgear" logo normally flashes on and off rapidly, too.
One other thing that I have observed on boots where the touch panel gets messed up is that right after turning on power to the unit, the LCD panel will often quickly display the "Shutting down...Goodbye" message. The LCD then blanks and displays the expected "Booting" message. I believe that this is due to the residual charge in the unit keeping the previous data "alive" in the touch panel hardware. My current working theory is that the touch panel hardware is not getting initialized properly on boot, and that this residual charge may contribute to (but is not the sole cause) of the touch panel/LED problems. As such, I've found that another useful workaround when the issue arises is to shut down the machine and remove any residual charge from it. A simple way to do this is to:
1. Gracefully shut down the unit via the web admin page or by pressing the power button on the front of the unit twice.
2. Locate the master power switch on the back of the unit, and flick it to the "off" ("0") position.
3. While the master switch is still off, press and hold down the power button on the front of the unit for 30 seconds (to be safe).
4. Flick the master power switch on the back of the unit to the "on" ("1") position. The unit will automatically begin booting.
On both machines, ALMOST every time this fixes the problem with one power-drain reboot. Only once, I had to do this procedure three times in a row on the OS 6.6.0 unit to bring it back to a fully normal state. Each time the touch panel got more responsive, progressing through the "inverted" state to normal working order. (This is one reason why I do not think that old data being held in place by the residual charge is the sole cause of the problem.)
Obviously there are still many unanswered questions, and I would love to hear any further input or ideas anyone may have. Admittedly, I may be completely off-base in my line of thinking, but hopefully this post will be of some help to others.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
