ReadyNAS 316 LCD/Touchpanel issues

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.