Failure to mount USB HDD and Asuswrt-Merlin on RT-N66R

[StR]

I have found several threads with a very similar problem: various HDDs couldn't be mounted on the RT-N66R running Asuswrt-Merlin.

In my case, it was running 380.58, but I just upgraded to 380.59. Both versions behave the same way.
According to the logs, The disk gets mounted first and then gets umounted.

But what is weird that even when I disconnect the drive, the logs keep showing endless records:
Jul 5 21:40:36 kernel: scsi 1:0:0:0: rejecting I/O to dead device
Jul 5 21:40:36 kernel: scsi 1:0:0:0: rejecting I/O to dead device
It is occasionally interrupted by records like these:
Jul 5 21:40:36 kernel: printk: 599 messages suppressed.
Jul 5 21:40:36 kernel: Buffer I/O error on device sdb1, logical block 425681968
just to continue:
Jul 5 21:40:36 kernel: scsi 1:0:0:0: rejecting I/O to dead device

It looks like some process gets stuck running on the server (is it some type of partition scanner that starts once the disk is unmounted)?

Here is the log excerpt of when the disk is first connected:
Jul 5 20:50:51 kernel: scsi 2:0:0:0: Direct-Access SAMSUNG HD204UI PQ: 0 ANSI: 4
Jul 5 20:50:51 kernel: sd 2:0:0:0: [sdb] 3907029168 512-byte hardware sectors (2000399 MB)
Jul 5 20:50:51 kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jul 5 20:50:51 kernel: sd 2:0:0:0: [sdb] Assuming drive cache: write through
Jul 5 20:50:51 kernel: sd 2:0:0:0: [sdb] Assuming drive cache: write through
Jul 5 20:50:51 kernel: sd 2:0:0:0: [sdb] Attached SCSI disk
Jul 5 20:50:51 kernel: sd 2:0:0:0: Attached scsi generic sg1 type 0
Jul 5 20:50:52 usb: USB /dev/sdb1(ntfs) failed to mount At the first try!
Jul 5 20:50:52 kernel: ufsd: use builtin utf8 instead of kernel utf8
Jul 5 20:50:55 usb: USB ntfs fs at /dev/sdb1 mounted on /tmp/mnt/Iomega_HDD.
Jul 5 20:50:55 kernel: ufsd: sdb1 without journal
Jul 5 20:50:56 asusware: umount partition /dev/sdb1...
Jul 5 20:50:56 disk monitor: unmount partition
Jul 5 20:50:57 syslog: USB partition unmounted from /tmp/mnt/Iomega_HDD
Jul 5 20:50:57 asusware: Automatically scan partition /dev/sdb1...
Jul 5 20:50:57 disk monitor: scan partition

 

[StR]

A followup on that:

With a freshly rebooted router, I tried to attach the HDD again.
After doing the same mount attempt and then unmounting, the router was seemingly "chewing" on the HDD for a while. After that, it finished, and logged the following log records:
Jul 6 00:09:11 asusware: re-mount partition /dev/sdb1...
Jul 6 00:09:11 disk monitor: re-mount partition
Jul 6 00:09:11 usb: USB /dev/sdb1(ntfs) failed to mount At the first try!
Jul 6 00:09:11 kernel: ufsd: use builtin utf8 instead of kernel utf8
Jul 6 00:09:15 kernel: ufsd: sdb1 without journal
Jul 6 00:09:15 usb: USB ntfs fs at /dev/sdb1 mounted on /tmp/mnt/Iomega_HDD.
Jul 6 00:09:15 asusware: done.
Jul 6 00:09:15 disk monitor: done
Jul 6 00:09:19 admin: sh /opt/S50asuslighttpd.1 start
Jul 6 00:09:23 admin: sh /opt/S50downloadmaster.1 start
Jul 6 00:09:35 transmission-daemon[1890]: UDP Failed to set receive buffer: requested 4194304, got 237568 (tr-udp.c:78)
Jul 6 00:09:35 transmission-daemon[1890]: UDP Failed to set send buffer: requested 1048576, got 237568 (tr-udp.c:89)
Jul 6 00:09:44 rc_service: hotplug 716:notify_rc restart_nasapps
Jul 6 00:09:44 FTP Server: daemon is stopped
Jul 6 00:09:44 Samba Server: smb daemon is stopped
Jul 6 00:09:44 miniupnpd[690]: shutting down MiniUPnPd
Jul 6 00:09:44 Samba Server: daemon is started
Jul 6 00:09:46 miniupnpd[1981]: HTTP listening on port 57060
Jul 6 00:09:46 miniupnpd[1981]: Listening for NAT-PMP/PCP traffic on port 5351

So, it looks like there was something on the drive that didn't let the router to mount it, most likely after it was not properly unmounted from the router.

However, in the mean time while having problems mounting this drive to the router, I've mounted (and "ejected") this drive on two different Windows boxes (Win 7 and Win XP), and neither of them complained about the HDD having problems.
I wonder if somehow the partition was mounted "not clean" in a way that Windows didn't care about.

 

[StR]

It looks like some type of a bug in the firmware: even if I explicitly and properly unmounted the external USB drive from the router, and reattached, - the router (RT-N66R) first needs to scan the HDD first (which takes lots of time, - 20-30 minutes, possibly more for a 2TB drive.)
This was not happening with the ASUS' own firmware, and, while I am not sure, I suspect it was not happening with v. 380.58, but started with 380.59.

Could you please check if you can fix this bug in .60 or .61?

 

[RMerlin]

The USB-related code is untouched by me, and is the stock Asus code (which they keep changing every new release).

 

[StR]

The USB-related code is untouched by me, and is the stock Asus code (which they keep changing every new release).

Thank you for your quick response (and the great work!).

I believe my last version version of the Asus firmware was 378.x,
possibly 3.0.0.4.378.9459. And that was working fine with this same USB HDD.
After that I've installed 360.58 and then 360.59, both exhibiting this problem.
And I see that there were some USB-related fixes in Asus' 3.0.0.4.376.3602 and 3.0.0.4.378.6117.

I am a bit confused how the version numbers are correlated. (Sorry I am new to Merlin Firmware.) Are your current ones based on 3.0.0.4.360.* ?

If that's a wrong assumption, and the numbering system is different, could you please provide some reference for comparing those? Which one is 360.59 based on?

And if 360.59 is based on a relatively recent version of Asus' firmware, any suggestions of how to report this problem to ASUS in the most effective way?

 

[RMerlin]

Thank you for your quick response (and the great work!).

I believe my last version version of the Asus firmware was 378.x,
possibly 3.0.0.4.378.9459. And that was working fine with this same USB HDD.
After that I've installed 360.58 and then 360.59, both exhibiting this problem.
And I see that there were some USB-related fixes in Asus' 3.0.0.4.376.3602 and 3.0.0.4.378.6117.

I am a bit confused how the version numbers are correlated. (Sorry I am new to Merlin Firmware.) Are your current ones based on 3.0.0.4.360.* ?

If that's a wrong assumption, and the numbering system is different, could you please provide some reference for comparing those? Which one is 360.59 based on?

And if 360.59 is based on a relatively recent version of Asus' firmware, any suggestions of how to report this problem to ASUS in the most effective way?

There's no 360_*, it's 380_*.

Each of my releases are based on different GPL code, so you have to look at the Changelog to determine on which GPL version a specific Asuswrt-Merlin release is based on. 380.59 for instance was based on 3.0.0.4.380_2697.