On Wed, Jul 25, 2012 at 10:46:37AM -0700, Sarah Sharp wrote: > Hi Matthew! It helps if you Cc my email address in your mail. > Otherwise it might get lost in a separate folder and ignored for a > couple days. I was attempting to follow the pattern you established with Gary when you redirected his private mail to linux-usb. Now that I know your personal system I'll do my best to go along with it to avoid any confusion. > Ok, it looks like the same version of Etron host controller as Gary: > > 03:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01) (prog-if 30 [XHCI]) > 03:00.0 0c03: 1b6f:7023 (rev 01) (prog-if 30 [XHCI]) > > Have you tried applying the patch I sent to Gary for testing? I think > that will remove the messages. The copy I found online did not apply cleanly due to some sort of formatting woes. So I added the necessary additional line by hand to get it going and the message did disappear from dmesg as we'd expect. > I don't think it will corrupt the data. It will just slow down reading > data from the card. But you have a point about the messages filling up > dmesg. I'll send you a patch shortly that rate limits the warning > messages. I've seen cases where having too many printk's in the wrong places crashed my system when I was writing kernel modules before. In any event this is a side topic, and I extend my sincere thanks for helping to rate-limit the message, this is a big help. > The patch fixed Gary's printk warnings, but didn't fix his overall > issue. I need to follow up on that. > > So, can you test with the patch that I sent Gary and make sure that the > printks go away and USB devices work properly under the Etron host? > Then revert the patch, apply the printk rate limiting patch I'll send > you shortly, and make sure you only get the SHORT_TX quirk message once. I think I'm in the same state as Gary only different. ;) I am getting weird behavior with the quirk patch. The device popped up for about half a minute, then went haywire and disappeared after the exfat FUSE FS tried to mount it and begin reading the volume successfully for a short moment. The exfat code seems unhappy because something triggered an obscure warning which is probably not innocuous, because nobody else seemed to hit as the only Google searches went to the source code (I saw the "fsync failed" below): The one usage I could find in libexfat for exfat_fsync was for writing a superblock. If that's failing I think we'll run into big problems. However something from the FUSE layer might have triggered the fsync too possibly. I'd need some help because I haven't coded up FUSE based stuff before. http://exfat.googlecode.com/svn/trunk/libexfat/io.c static int commit_super_block(const struct exfat* ef) { exfat_pwrite(ef->dev, ef->sb, sizeof(struct exfat_super_block), 0); return exfat_fsync(ef->dev); } ... int exfat_fsync(struct exfat_dev* dev) { #ifdef USE_UBLIO if (ublio_fsync(dev->ufh) != 0) #else if (fsync(dev->fd) != 0) #endif { exfat_error("fsync failed"); return 1; } return 0; } I did not try the rate-limit yet, pending the outcome from the above topic. > Sarah Sharp Regards, Matthew. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
