May 3 13:59:56 cesspit kernel: [167270.573707] XFS mounting filesystem sdb1
May 3 14:07:33 cesspit kernel: [167789.981969] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:10:19 cesspit kernel: [167973.291042] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:10:49 cesspit kernel: [168009.169512] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:10:59 cesspit kernel: [168021.281996] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:15 cesspit kernel: [168040.401488] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:16 cesspit kernel: [168040.778268] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:26 cesspit kernel: [168052.821977] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:26 cesspit kernel: [168053.058472] sd 10:0:0:0: Device offlined - not ready after error recovery
May 3 14:11:26 cesspit kernel: [168053.058508] sd 10:0:0:0: [sdc] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK,SUGGEST_OK
May 3 14:11:26 cesspit kernel: [168053.058638] sd 10:0:0:0: [sdc] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
May 3 14:11:39 cesspit kernel: [168068.578563] printk: 28 messages suppressed.
While watching the copy, I noticed the psc power down during a copy, the kde copy dialog stalled while the messages "usb 2-4: reset high speed USB device using ehci_hcd and address 17" were printing to var/log. The copy did resume once, picked back up normal speed but powered down again a 2nd time and failed to come back online.
trying to remount the device has been working over the past few days but not today, output (note I use labels for mounting):
root@cesspit:/mnt# umount usb2
root@cesspit:/mnt# mount usb2
Error opening '/dev/sdc1': No such device or address
Failed to mount '/dev/sdc1': No such device or address
You seem to have a SoftRAID/FakeRAID hardware and must use an activated,
different device under /dev/mapper/, (e.g. /dev/mapper/nvidia_eahaabcc1)
to mount NTFS. Please see the 'dmraid' documentation for help.
Power cycling fixed the device. I will note this drive is a bit old and noisy but has never presented any issues when in use on my fileserver (connected internally). The issues are also not present in windows xp on any machines. I would suspect ntfs to be contributing to the issue but the other identical psc has the same issue though it doesnt not need to be power cycled as often.
I did contact welland regarding the issue and the had this to say:
Dear Customer,
Thanks for your mail and purchased our product.
Pls. use our power saving AP tool to control the time of power down.
By the way, may I know where are you from? Thanks.
Thanks & Best regards,
Jing Lee / Sales department
Welland Industrial Co., Ltd
Tel: +886-2-8285-2345 ext. 18
Fax: +886-2-8282-5000, 8282-7000
E-mail: -
Web: www.welland.com.tw
-EOF-
I does seem they didnt realise I am in linux but I will plug these psc into a windows pc, use the tool to raise the timeout and retry. The latest kernel does not seem to fix the issue after all but it does seem an improvement.
Failure again, while copying from a welland psc (power saving caddy) to a normal firewire caddy. 5gb into copy.
Here is the strange ls output:
root@cesspit:/mnt# ls -la usb2/ r2beta1- 9.exe
total 4
drwxrwxrwx 1 mem root 4096 2008-05-03 14:02 .
drwxr-xr-x 8 root root 88 2008-05-01 21:08 ..
drwxrwxrwx 1 mem root 0 2008-05-02 00:01 Media
?--------- ? ? ? ? ? usb2/Incomming
?--------- ? ? ? ? ? usb2/SuperCopie
root@cesspit:/mnt# cat /etc/fstab | grep usb2
LABEL=sleepy2 /mnt/usb2 ntfs-3g defaults,uid=1000 0 0
var/log/messages output:
May 3 13:59:56 cesspit kernel: [167270.573707] XFS mounting filesystem sdb1 DRIVER_ OK,SUGGEST_ OK DID_NO_ CONNECT driverbyte= DRIVER_ OK,SUGGEST_ OK
May 3 14:07:33 cesspit kernel: [167789.981969] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:10:19 cesspit kernel: [167973.291042] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:10:49 cesspit kernel: [168009.169512] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:10:59 cesspit kernel: [168021.281996] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:15 cesspit kernel: [168040.401488] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:16 cesspit kernel: [168040.778268] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:26 cesspit kernel: [168052.821977] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:26 cesspit kernel: [168053.058472] sd 10:0:0:0: Device offlined - not ready after error recovery
May 3 14:11:26 cesspit kernel: [168053.058508] sd 10:0:0:0: [sdc] Result: hostbyte=DID_ABORT driverbyte=
May 3 14:11:26 cesspit kernel: [168053.058638] sd 10:0:0:0: [sdc] Result: hostbyte=
May 3 14:11:39 cesspit kernel: [168068.578563] printk: 28 messages suppressed.
While watching the copy, I noticed the psc power down during a copy, the kde copy dialog stalled while the messages "usb 2-4: reset high speed USB device using ehci_hcd and address 17" were printing to var/log. The copy did resume once, picked back up normal speed but powered down again a 2nd time and failed to come back online.
trying to remount the device has been working over the past few days but not today, output (note I use labels for mounting):
root@cesspit:/mnt# umount usb2 nvidia_ eahaabcc1)
root@cesspit:/mnt# mount usb2
Error opening '/dev/sdc1': No such device or address
Failed to mount '/dev/sdc1': No such device or address
You seem to have a SoftRAID/FakeRAID hardware and must use an activated,
different device under /dev/mapper/, (e.g. /dev/mapper/
to mount NTFS. Please see the 'dmraid' documentation for help.
Power cycling fixed the device. I will note this drive is a bit old and noisy but has never presented any issues when in use on my fileserver (connected internally). The issues are also not present in windows xp on any machines. I would suspect ntfs to be contributing to the issue but the other identical psc has the same issue though it doesnt not need to be power cycled as often.
I did contact welland regarding the issue and the had this to say:
Dear Customer,
Thanks for your mail and purchased our product.
Pls. use our power saving AP tool to control the time of power down.
By the way, may I know where are you from? Thanks.
Thanks & Best regards,
Jing Lee / Sales department
Welland Industrial Co., Ltd
Tel: +886-2-8285-2345 ext. 18
Fax: +886-2-8282-5000, 8282-7000
E-mail: -
Web: www.welland.com.tw
-EOF-
I does seem they didnt realise I am in linux but I will plug these psc into a windows pc, use the tool to raise the timeout and retry. The latest kernel does not seem to fix the issue after all but it does seem an improvement.