TomatoUSB

I'll leave the performance discussion to the other thread on here. This is about stability.

If I have multiple sources of activity on a USB attached hard drive, the mounted fileshare will disappear. It's fixed by going into TomatoUSB and remounting the USB drive.

Example:
Downloading a torrent with Transmission to the USB attached hard drive while a PC is reading from that drive. It may take a few minutes or even ten or twenty minutes but the performance will degrade quickly and then the mount just disappears. This never seems to happen as long as I make sure only one thing is happening on a drive at a time.

Firmware: Tomato Firmware v1.28.9049 MIPSR2-beta19 K26 USB vpn3.6
Router: Asus RT-N16
Drive: Samsung 1TB 5400rpm "green" drive formatted with NTFS

What is the CPU and memory usage right before the drive disappears?
Are there any messaged in the system log?
Is this behavior the same among multiple different drives / different file systems? Have you tried Ext3/Ext2, for example?
What if torrents are not involved at all, and you just have two or more clients reading from and writing to the same drive?

There was a problem on WL-520GU in the kernel when it was doing overlapped I/O to more than one USB drives simultaneously. That was fixed by a patch to the 2.4 kernel several versions ago.

But I'm not sure that it is/was solved in the 2.6 kernel. My suspicion is that it was not, based on the fact the TeddyBear re-inserted some of the kludged code we had in while we were trying to resolve the issue.

I think that there's a bug in the USB hardware, and my "fix" resolved it by preventing overlapped I/O.

I believe overlapped IO is not a problem in K26, and the issue - if there's one - must be elsewhere. But for sure there are still bugs in the USB layer, and my backports from newer kernel versions might be incomplete, etc.

As for the kludged usb hotplug serialization code, I added it back to 2.6 builds since I'm using hotplug2, and even though it reads kernel events sequentially, it then forks new processes to execute custom commands (i.e. to call our hotplug-usb), so they can overlap.

I have mostly the same problem on two setups:

• wl500gp upgraded to 128mb, running a K24 build from 6 months ago, and with 3 USB disks. They work perfectly under heavy load unless I activate a swap partition on one of them. If I do, they randomically get disconnected after a while. If I use no swap or swap on an attached USB pendrive, they work ok.
• rt-n16 with a single USB drive, k26 build. It never works reliably with USB 2.0 ehci support; as soon as I start writing some data to the disk in heavy fashion, it gets disconnected. I am using the disk in USB 1 mode, which sucks a lot but at least it works without crashing. I am really thinking of selling the drive on eBay and get another one — any other one probably works. Obviously the unit itself is not broken (I stressed it on my ubuntu pc without problems in usb2) so it must be a bug in the kernel of K26 that has been fixed in newer versions.

I may have seen this last night as well (latest K26 beta on RT-N16). Hooked up a second USB drive (swap and data on the first drive) and executed a simple "cp -a /mnt/first/* /mnt/second" - about 3 minutes into the copy, router spontaneously rebooted (swap dismounted?). Could not reproduce.

Rodney

Yes i think there is some bug in swap on USB

Gah. Something's up with beta 54 (or 53? I skipped it on purpose…). I just had my second spontaneous unexplained restart in 24 hours. It's not related to the wireless driver because there are no wireless devices active in my house today (or yesterday), but I never saw this on 52 or prior. The last entry in messages was the output from SIGUSR1 to the latest pixelserv build (outputs the number of ads served).

I don't even know how to start debugging this, since I have no idea how to consistently reproduce it. Since my message log is on the USB disk, you could theoretically argue it -may- be related to USB, but I'm not willing to go that far yet.

Rodney

…then again, it might be pixelserv V22 crashing me out. Will report back in about 48 hours.

EDIT: That was quick. It isn't pixelserv. Fell back to beta 52 to see if it makes any difference…seems I get into trouble when doing mass NAS copies to an ext3 USB device.

Rodney

@Rodney - did you have your log stored on the USB drive before, or only started to do it with the last build or recently (maybe you never saw the issue before only because you didn't use the USB drives as heavy)? What would help to localize the problem is the console log of the crash (there must be an oops or something before reboot - doubt it just goes off silently - but it may not be seen in the syslog), and to know exactly what build the problem started from (if it was not there from the beginning). Obviously, it may be difficult and time consuming to find this out :(…

@Rasky - what exactly clarifies for a "heavy fashion"? When I experimented with Transmission (I don't use it regularly), I did see the drive getting disconnected from time to time, and - depending on the drive - either auto-reconnected and re-mounted back again, or just stay off until I unplug it and plug it back in. What seemed to help with disconnects up to a point, was increasing the "log2_irq_thresh" parameter value when loading EHCI driver.

There's an experimental nvram key now you can play with - "usb_irq_thresh" (can be set to a value from 0 to 6). Try setting it to "4" to start with, and see if it helps (you either need to reboot with the new settings commited, or disable and then re-enable the USB support, otherwise EHCI driver will not be reloaded). Generally the higher the value the more stable the USB operations should be - but performance may decrease a little.