NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ReadyNAS Pro 6 Became Inaccessible - Support Case: 25326829
Hi all,
This morning a NAS I support in business became inaccessible. Status screen showed IP address etc and lights on but would not even respond to ping. Had to press and hold power button to power cycle device. After this device was back online.
A perusal of the logs does not reveal much, other than it seems to be related to the USB attached storage device (backup drive). I had disconnected this earlier in the day through frontview but not removed from the port yet. Here is an exert from the logs showing the last moments of it being online and then when it was restarted this morning. The last logs were at 21:20:29. It almost seems the device hard locked up.
I have raised support case 25326829 and uploaded a full compliment of logs there.
I'd appreciate your support to identify the root cause of this issue.
Thanks...
This morning a NAS I support in business became inaccessible. Status screen showed IP address etc and lights on but would not even respond to ping. Had to press and hold power button to power cycle device. After this device was back online.
A perusal of the logs does not reveal much, other than it seems to be related to the USB attached storage device (backup drive). I had disconnected this earlier in the day through frontview but not removed from the port yet. Here is an exert from the logs showing the last moments of it being online and then when it was restarted this morning. The last logs were at 21:20:29. It almost seems the device hard locked up.
Jun 22 14:09:50 despair kernel: sd 28:0:0:0: Attached scsi generic sg4 type 0
Jun 22 14:09:50 despair kernel: sd 28:0:0:0: [sde] 976773164 512-byte logical blocks: (500 GB/465 GiB)
Jun 22 14:09:50 despair kernel: sd 28:0:0:0: [sde] Write Protect is off
Jun 22 14:09:50 despair kernel: sd 28:0:0:0: [sde] Mode Sense: bf 00 00 00
Jun 22 14:09:50 despair kernel: sd 28:0:0:0: [sde] Assuming drive cache: write through
Jun 22 14:09:50 despair kernel: sd 28:0:0:0: [sde] Assuming drive cache: write through
Jun 22 14:09:50 despair kernel: sde: sde1
Jun 22 14:09:50 despair kernel: sd 28:0:0:0: [sde] Assuming drive cache: write through
Jun 22 14:09:50 despair kernel: sd 28:0:0:0: [sde] Attached SCSI disk
Jun 22 14:09:51 despair kernel: kjournald starting. Commit interval 5 seconds
Jun 22 14:09:51 despair kernel: EXT3-fs (sde1): using internal journal
Jun 22 14:09:51 despair kernel: EXT3-fs (sde1): mounted filesystem with journal data mode
Jun 22 21:10:25 despair kernel: usb 1-2: USB disconnect, address 24
Jun 22 21:10:26 despair kernel: JBD: I/O error detected when updating journal superblock for sde1.
Jun 22 21:10:26 despair kernel: EXT3-fs (sde1): I/O error while writing superblock
Jun 22 21:10:26 despair kernel: scsi: killing requests for dead queue
Jun 22 21:10:28 despair kernel: usb 1-2: new high speed USB device using ehci_hcd and address 25
Jun 22 21:10:28 despair kernel: scsi29 : usb-storage 1-2:1.0
Jun 22 21:10:29 despair kernel: scsi 29:0:0:0: Direct-Access Seagate Portable SF06 PQ: 0 ANSI: 4
Jun 22 21:10:29 despair kernel: scsi: killing requests for dead queue
Jun 22 21:10:29 despair last message repeated 7 times
Jun 22 21:10:29 despair kernel: sd 29:0:0:0: Attached scsi generic sg4 type 0
Jun 22 21:10:29 despair kernel: sd 29:0:0:0: [sde] 976773164 512-byte logical blocks: (500 GB/465 GiB)
Jun 22 21:10:29 despair kernel: sd 29:0:0:0: [sde] Write Protect is off
Jun 22 21:10:29 despair kernel: sd 29:0:0:0: [sde] Mode Sense: bf 00 00 00
Jun 22 21:10:29 despair kernel: sd 29:0:0:0: [sde] Assuming drive cache: write through
Jun 22 21:10:29 despair kernel: sd 29:0:0:0: [sde] Assuming drive cache: write through
Jun 22 21:10:29 despair kernel: sde: sde1
Jun 22 21:10:29 despair kernel: sd 29:0:0:0: [sde] Assuming drive cache: write through
Jun 22 21:10:29 despair kernel: sd 29:0:0:0: [sde] Attached SCSI disk
Jun 23 08:14:32 despair kernel: klogd 1.4.1#18, log source = /proc/kmsg started.
Jun 23 08:14:32 despair kernel: Initializing cgroup subsys cpu
Jun 23 08:14:32 despair kernel: Linux version 2.6.37.6.RNx86_64.2.4 (jmaggard@calzone) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Wed Aug 20 11:41:34 PDT 2014
Jun 23 08:14:32 despair kernel: Command line: initrd=initrd.gz reason=normal BOOT_IMAGE=kernel
Jun 23 08:14:32 despair kernel: BIOS-provided physical RAM map:
I have raised support case 25326829 and uploaded a full compliment of logs there.
I'd appreciate your support to identify the root cause of this issue.
Thanks...
6 Replies
Replies have been turned off for this discussion
- It now seems support don't want to help me as it's beyond 90 days. I've had e-mail support previously and it should be provided beyond 90 days as per:
* Lifetime Technical Support is provided via free phone support for first 90 days, and via free online chat thereafter.
Needless to say I have pointed this out to the agent...
May be writing a letter to Rob Wells and Patrick Lo if I am actually denied support! :x
Such a shame as the folks on this forum are very helpful. - Since you suspect the USB disk may be related to the problem have you checked its health?
- Thanks for your response...
So far it has been disconnected and have no intention of reconnecting until I understand the cause.
The disk was already disconnected from frontview so I don't see how this should have happened.
In anycase it is not good behaviour for the box to hang irrespective of a disk issue.
Are you able to comment on the support beyond 90 day piece? - Not sure why it hung looking at your logs.
You could run the memory test boot menu option for a few passes and perhaps also run the disk test boot menu option if you like. - Well, what I do find interesting is the fact the USB drive is even doing anything. If you look at the full logs uploaded to my case you will see that I had already disconnected it from Frontview but had not gone to site to remove it as yet.
I suspect the drive may have been the trigger but I don't see how it came to get reconnected and furthermore lead to a crash with no other dumps etc.
If there were other random lockups then yes I would look at disk and memory tests. Interestingly whilst the device was inaccessible and didn't respond to pings etc, pressing the button on the front did display IP address, I do suspect this is handled separately to the underlying OS though.
You can see why I am reluctant to pay for extended support in this instance because I suspect they won't be able to find the fault. It was more curiosity to see if anybody else had seen the same behaviour from your large customer base. - Also... Not related to the lockup but does anybody else see these after doing FS checks:
May 31 15:12:46 despair RAIDiator: Filesystem check completed with no errors. [USB_HDD_1]
May 31 15:12:47 despair kernel: kjournald starting. Commit interval 5 seconds
May 31 15:12:47 despair kernel: EXT3-fs (sde1): using internal journal
May 31 15:12:47 despair kernel: EXT3-fs (sde1): mounted filesystem with journal data mode
May 31 15:12:47 despair RAIDiator: Could not open USB storage remover. <<<<<<<<<<<<<<<<<<
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
