Forgot to mention, I put a new log here with the latest behavior with the patch: http://www.mhcomputing.net/tmp/xhci-bug/dmesg-usb-3-port-quirk-patch-plugin.txt.gz Regards, Matthew. On Wed, Jul 25, 2012 at 10:24:26PM -0700, Matthew Hall wrote: > 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 -- 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
