Re: XHCI, "brain-dead scanner", and microframe rounding
Aww, that's too bad. Let me know if you'd like me to test a modified version when you get the time. --Mike Mammarella On May 21, 2015, at 4:18 AM, Mathias Nyman wrote: > Hi > > The fix went upstream, but caused regression for other users, and had to be > reverted. > The cause of the regression was found but the new version was never properly > tested and > got left behind as more urgent issues arrived. > > I still need to attend a few other issues before taking up this again > > -Mathias > > On 21.05.2015 13:38, Hans-Peter Jansen wrote: >> Dear Mathias, >> >> just a heads up: retesting with 4.0.4 revealed, that this issue isn't fixed >> for my scanner still. To recap: driving the scanner through a ehci port is >> fine, and fails miserably with xhci. >> >> OK: >> >> T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 4 >> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 >> P: Vendor=1d6b ProdID=0002 Rev=04.00 >> S: Manufacturer=Linux 4.0.4-2.g4f5e0d5-desktop ehci_hcd >> S: Product=EHCI Host Controller >> S: SerialNumber=:06:04.2 >> C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA >> I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub >> >> T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 >> D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 >> P: Vendor=04b8 ProdID=0119 Rev=01.00 >> S: Manufacturer=EPSON >> S: Product=EPSON Scanner >> C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=2mA >> I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) >> >> NOT OK: >> >> T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh=14 >> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 >> P: Vendor=1d6b ProdID=0002 Rev=04.00 >> S: Manufacturer=Linux 4.0.4-2.g4f5e0d5-desktop xhci-hcd >> S: Product=xHCI Host Controller >> S: SerialNumber=:00:14.0 >> C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA >> I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub >> >> T: Bus=06 Lev=01 Prnt=01 Port=10 Cnt=02 Dev#= 10 Spd=480 MxCh= 0 >> D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 >> P: Vendor=04b8 ProdID=0119 Rev=01.00 >> S: Manufacturer=EPSON >> S: Product=EPSON Scanner >> C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=2mA >> I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbfs >> >> Additional notes: >> >> xsane scanner discovery takes ages (20-30 secs) to find the scanner in the >> failing case. After selecting the correct device, it takes another delay of >> 20-30 secs. for presenting the error dialog: error during device I/O. The >> same >> procedure with ehci takes about a second until the device selection is >> shown, >> and another 0.5 secs later it presents the fully functional scanning UI. >> >> This behavior persists since Linux 3.16.x (where I setup this box). >> >> Please let me know, if I can be of any help for you for resolving this >> issue. >> I find it a little sad, that at the dawn of USB 3.1, we still fight with >> such >> issues on the linux USB 3.0 front. Don't forget the many frustrated users >> observing this, that will not speak up. >> >> Cheers, >> Pete >> >> On Donnerstag, 29. Januar 2015 18:42:05 Mathias Nyman wrote: >>> On 27.01.2015 14:12, Gunter Königsmann wrote: >>>> That's very good news indeed. >>>> >>>> Will re-run the tests on my scanner and looking forward to the fix >>>> entering mainline. In the meantime I can acknowledge that with the fix my >>>> computer accepts USB memory sticks that normally didn't work. >>>> >>>> Kind regards, >>>> >>>>Gunter. >>> >>> Did some cleaning of the patch, and noticed it still had a few bits wrong, >>> but apparently it worked anyway. >>> >>> I added the fixes on top of the ep_reset_halt_test branch. >>> >>> Can any of you with a failing scanner test that it still works? >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git >>> and the ep_reset_halt_test branch, >>> >>> Thanks >>> >>> -Mathias >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in >> the body of a message to majord...@vger.kernel.org >> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI, "brain-dead scanner", and microframe rounding
On Jan 29, 2015, at 8:42 AM, Mathias Nyman wrote: > On 27.01.2015 14:12, Gunter Königsmann wrote: >> That's very good news indeed. >> >> Will re-run the tests on my scanner and looking forward to the fix entering >> mainline. In the meantime I can acknowledge that with the fix my computer >> accepts USB memory sticks that normally didn't work. >> >> Kind regards, >> >>Gunter. > > Did some cleaning of the patch, and noticed it still had a few bits wrong, > but apparently it worked anyway. > > I added the fixes on top of the ep_reset_halt_test branch. > > Can any of you with a failing scanner test that it still works? > > git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git > and the ep_reset_halt_test branch, > > Thanks > > -Mathias Looks like it still works at 9fc99b08. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI, "brain-dead scanner", and microframe rounding
On Jan 22, 2015, at 7:23 AM, Mathias Nyman wrote: >> >> I was doing this on your ep_reset_halt_test branch, which has a lot of >> MATTU messages scrolling by, but I'm pretty sure that the microframe >> rounding message was not present when running with either of these >> changes. So that may be a red herring after all... >> > > I wrote a new hack to test, its in the ep_reset_halt_test branch (forced > update). > > It re-configures the endpoint every time a usb device driver clears a halt to > make the toggle and sequence stay in sync between xhci and the device. > > I'm coding in the dark here, the scanner I test on has always worked so I > need your > help in testing this. > > Code is in the same place, the ep_reset_halt_test branch: > git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git > ep_reset_halt_test > > A dmesg log with xhci debugging of a failing case with this hack would be > appreciated > echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control > > (Unless, ofcourse I blindly got it right at the first try and everthing works > flawlessly:) ... which appears to have been the case, actually. I love it when code works the first time. :) Here's the dmesg log in case there's anything you need to know in there: http://spark.crystalorb.net/mikem/dmesg.log I plug in the scanner at about 425 seconds, and start the scan around 477. This is awesome! I'm not familiar with how long this sort of fix usually takes to show up in official kernels; when might that happen? I'd be interested to try and get it picked up by distribution kernel packages (if the patch applies cleanly) so I can start using them again. Thanks so much for working on this! Mike-- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI, "brain-dead scanner", and microframe rounding
On Mon, 15 Sep 2014, Mathias Nyman wrote:
On 09/14/2014 01:52 AM, Mike Mammarella wrote:
On Sat, 26 Jul 2014, Mike Mammarella wrote:
On Fri, 4 Jul 2014, Mathias Nyman wrote:
On 07/01/2014 09:07 AM, Mike Mammarella wrote:
Hi
Can you add xhci debugging by enabling CONFIG_DYNAMIC_DEBUG, and run
`echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control`
as root,
and send me the output of dmesg.
Without debugging info it's hard to guess what's going on.
The microframe rounding look a bit suspicious:
[12864.453456] usb 3-4: ep 0x81 - rounding interval to 128 microframes, ep desc
says 255 microframes
xhci specs says it needs the interval rounded to nearest 2^(X) value, which
would be 256, not 128. I'll take a look at that.
An other possibility is that it's related to how xhci handles halted endpoints.
I got some untested code to fix this, It needs a lot of cleanup but can be
tested.
If you are able to test my ep_reset_halt_test branch (with xhci debugging) I'd
be interested to know if it helps.
Code is at:
git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git ep_reset_halt_test
-Mathias
Thanks! I've built a kernel from fb58633e with CONFIG_DYNAMIC_DEBUG enabled.
(I also had to mount debugfs, it turns out.) The scanner does not work in
this configuration. I've posted the logs here:
http://spark.crystalorb.net/mikem/dmesg.log
http://spark.crystalorb.net/mikem/scanadf.log
dmesg seems to have much more information than what showed up on the
console (which showed only MATTU messages); it may be relevant when
sifting through that output that the root file system is also on USB.
Thanks,
Took a quick look, but can't find any obvious reason why it fails.
I'll be out of office next week, but I'll try to take a better look again when
I return
usbmon traces of this could give some hint on what is happening
-Mathias
Sorry for the delay getting back to you - I've captured traces with EHCI
(works) and XHCI (fails). In both cases the scanner is device 10 on bus 1. The
kernel is the Debian 3.14.12 kernel (so, in particular, not your
ep_reset_halt_test branch), in case that's important for these traces.
http://spark.crystalorb.net/mikem/usbmon-success.log
http://spark.crystalorb.net/mikem/usbmon-failure.log
I appreciate your help looking into this!
Mike
Hi, just curious if these traces were useful? Is there any other information I
could collect that would help?
Thanks!
Mike
I haven't had time to dig into the usbmon traces, but I just got another report
from Gunter K?ningsmann about similar scanner problem, and I just noticed
that in both cases we round the interval for high speed bulk _IN_ endpoint,
which should not have interval set at all.
The interval value should be ignored by host, but maybe setting it still could
cause some issues.
I don't have high hopes for this patch, but it's worth a shot.
Can you try this out and see if it makes any difference?
-Mathias
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8936211..7f21b77 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1291,7 +1291,8 @@ static unsigned int xhci_get_endpoint_interval(struct
usb_device *udev,
/* Max NAK rate */
if (usb_endpoint_xfer_control(&ep->desc) ||
usb_endpoint_xfer_bulk(&ep->desc)) {
- interval = xhci_parse_microframe_interval(udev, ep);
+ if (!usb_endpoint_dir_in(&ep->desc))
+ interval = xhci_parse_microframe_interval(udev,
ep);
break;
}
/* Fall through - SS and HS isoc/int have same decoding */
As Gunter noted, that doesn't seem to have any effect. For kicks I also
tried the change below (I suppose it's probably not correct to fall
though in this case, though), but it also didn't make any difference:
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8056d90..a88a23a 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1291,8 +1291,10 @@ static unsigned int xhci_get_endpoint_interval(struct
usb_device *udev,
/* Max NAK rate */
if (usb_endpoint_xfer_control(&ep->desc) ||
usb_endpoint_xfer_bulk(&ep->desc)) {
- interval = xhci_parse_microframe_interval(udev, ep);
- break;
+ if (!usb_endpoint_dir_in(&ep->desc)) {
+ interval = xhci_parse_microframe_interval(udev,
ep);
+ break;
+ }
}
/* Fall through - SS and HS isoc/int have same decoding */
I was doing this on your ep_reset_halt_test branch, which has a lot of
MATTU m
Re: XHCI, "brain-dead scanner", and microframe rounding
On Sat, 26 Jul 2014, Mike Mammarella wrote: On Fri, 4 Jul 2014, Mathias Nyman wrote: On 07/01/2014 09:07 AM, Mike Mammarella wrote: Hi Can you add xhci debugging by enabling CONFIG_DYNAMIC_DEBUG, and run `echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control` as root, and send me the output of dmesg. Without debugging info it's hard to guess what's going on. The microframe rounding look a bit suspicious: [12864.453456] usb 3-4: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes xhci specs says it needs the interval rounded to nearest 2^(X) value, which would be 256, not 128. I'll take a look at that. An other possibility is that it's related to how xhci handles halted endpoints. I got some untested code to fix this, It needs a lot of cleanup but can be tested. If you are able to test my ep_reset_halt_test branch (with xhci debugging) I'd be interested to know if it helps. Code is at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git ep_reset_halt_test -Mathias Thanks! I've built a kernel from fb58633e with CONFIG_DYNAMIC_DEBUG enabled. (I also had to mount debugfs, it turns out.) The scanner does not work in this configuration. I've posted the logs here: http://spark.crystalorb.net/mikem/dmesg.log http://spark.crystalorb.net/mikem/scanadf.log dmesg seems to have much more information than what showed up on the console (which showed only MATTU messages); it may be relevant when sifting through that output that the root file system is also on USB. Thanks, Took a quick look, but can't find any obvious reason why it fails. I'll be out of office next week, but I'll try to take a better look again when I return usbmon traces of this could give some hint on what is happening -Mathias Sorry for the delay getting back to you - I've captured traces with EHCI (works) and XHCI (fails). In both cases the scanner is device 10 on bus 1. The kernel is the Debian 3.14.12 kernel (so, in particular, not your ep_reset_halt_test branch), in case that's important for these traces. http://spark.crystalorb.net/mikem/usbmon-success.log http://spark.crystalorb.net/mikem/usbmon-failure.log I appreciate your help looking into this! Mike Hi, just curious if these traces were useful? Is there any other information I could collect that would help? Thanks! Mike -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI, "brain-dead scanner", and microframe rounding
On Fri, 4 Jul 2014, Mathias Nyman wrote: On 07/01/2014 09:07 AM, Mike Mammarella wrote: Hi Can you add xhci debugging by enabling CONFIG_DYNAMIC_DEBUG, and run `echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control` as root, and send me the output of dmesg. Without debugging info it's hard to guess what's going on. The microframe rounding look a bit suspicious: [12864.453456] usb 3-4: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes xhci specs says it needs the interval rounded to nearest 2^(X) value, which would be 256, not 128. I'll take a look at that. An other possibility is that it's related to how xhci handles halted endpoints. I got some untested code to fix this, It needs a lot of cleanup but can be tested. If you are able to test my ep_reset_halt_test branch (with xhci debugging) I'd be interested to know if it helps. Code is at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git ep_reset_halt_test -Mathias Thanks! I've built a kernel from fb58633e with CONFIG_DYNAMIC_DEBUG enabled. (I also had to mount debugfs, it turns out.) The scanner does not work in this configuration. I've posted the logs here: http://spark.crystalorb.net/mikem/dmesg.log http://spark.crystalorb.net/mikem/scanadf.log dmesg seems to have much more information than what showed up on the console (which showed only MATTU messages); it may be relevant when sifting through that output that the root file system is also on USB. Thanks, Took a quick look, but can't find any obvious reason why it fails. I'll be out of office next week, but I'll try to take a better look again when I return usbmon traces of this could give some hint on what is happening -Mathias Sorry for the delay getting back to you - I've captured traces with EHCI (works) and XHCI (fails). In both cases the scanner is device 10 on bus 1. The kernel is the Debian 3.14.12 kernel (so, in particular, not your ep_reset_halt_test branch), in case that's important for these traces. http://spark.crystalorb.net/mikem/usbmon-success.log http://spark.crystalorb.net/mikem/usbmon-failure.log I appreciate your help looking into this! Mike -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI, "brain-dead scanner", and microframe rounding
Hi Can you add xhci debugging by enabling CONFIG_DYNAMIC_DEBUG, and run `echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control` as root, and send me the output of dmesg. Without debugging info it's hard to guess what's going on. The microframe rounding look a bit suspicious: [12864.453456] usb 3-4: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes xhci specs says it needs the interval rounded to nearest 2^(X) value, which would be 256, not 128. I'll take a look at that. An other possibility is that it's related to how xhci handles halted endpoints. I got some untested code to fix this, It needs a lot of cleanup but can be tested. If you are able to test my ep_reset_halt_test branch (with xhci debugging) I'd be interested to know if it helps. Code is at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git ep_reset_halt_test -Mathias Thanks! I've built a kernel from fb58633e with CONFIG_DYNAMIC_DEBUG enabled. (I also had to mount debugfs, it turns out.) The scanner does not work in this configuration. I've posted the logs here: http://spark.crystalorb.net/mikem/dmesg.log http://spark.crystalorb.net/mikem/scanadf.log dmesg seems to have much more information than what showed up on the console (which showed only MATTU messages); it may be relevant when sifting through that output that the root file system is also on USB. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
