some questions about ehci period scheduling
hi all: when I trace linux ehci driver source code. I have some questions 1. in itd_slot_ok, why we have to uframe %= period; and use this uframe to calculate the bandwidth? suppose start passed to itd_slot_ok is 537, period, usb->interval, is 8. that mean we want to know whether bandwidth of microframe 537 is enough. Not want to know whether 537%8 =1 the bandwidth of microframe 1 is enough. 2. Below is part of message excerpted from usb mon log: db1e2000 81051026 S Zi:1:002:6 -115:8:5327 1 -18:0:132 132 < db1e2000 81058043 C Zi:1:002:6 0:8:5391:0 1 0:0:4 132 = 2efd82fd 0cfe 84feb3ff 98fec4fb 08ffdaf8 060059fb 8b01d2ff db02de01 why these 2 ep->start_frame are different, 5327 in "-115:8:5327" and 5391 in "0:8:5391:0"? The log is captured with the same urb, for submitting and completing. That mean ep->start_frame=urb->start_frame in submit and complete should be the same, right? appreciate your help in advance, -- 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: External HDD does not work with 3.11-rc2
On 31 July 2013 15:14, Philipp Dreimann wrote: > On Tue, Jul 30, 2013 at 9:28 PM, Alan Stern wrote: >> On Tue, 30 Jul 2013, Sarah Sharp wrote: >> >>> On Tue, Jul 30, 2013 at 12:52:40PM -0400, Alan Stern wrote: >>> > Sarah, the usbmon trace shows that after doing a successful port reset >>> > and clearing a bunch of port features, the system tells the port to go >>> > into the SS.disabled state for no apparent reason: >>> > >>> > 88014649f3c0 1804119918 S Co:4:001:0 s 23 03 0004 0002 0 >>> > 88014649f3c0 1804119924 C Co:4:001:0 0 0 >>> > 88020a1dd000 1804170382 S Ci:4:001:0 s a3 00 0002 0004 4 < >>> > 88020a1dd000 1804170389 C Ci:4:001:0 0 4 = 03021000 >>> > 8801b7173300 1804221388 S Co:4:001:0 s 23 01 0014 0002 0 >>> > 8801b7173300 1804221397 C Co:4:001:0 0 0 >>> > 8801b7173300 1804221398 S Co:4:001:0 s 23 01 001d 0002 0 >>> > 8801b7173300 1804221403 C Co:4:001:0 0 0 >>> > 8801b7173300 1804221403 S Co:4:001:0 s 23 01 0019 0002 0 >>> > 8801b7173300 1804221407 C Co:4:001:0 0 0 >>> > 8801b7173300 1804221408 S Co:4:001:0 s 23 01 0010 0002 0 >>> > 8801b7173300 1804221412 C Co:4:001:0 0 0 >>> > 8801b7173300 1804221414 S Ci:4:001:0 s a3 00 0002 0004 4 < >>> > 8801b7173300 1804221417 C Ci:4:001:0 0 4 = 0302 >>> > 88014649f3c0 1804623388 S Co:4:001:0 s 23 03 0005 0402 0 >>> > 88020ceb1600 1804623409 C Ii:4:001:1 0:2048 1 = 04 >>> > 88020ceb1600 1804623410 S Ii:4:001:1 -115:2048 4 < >>> > 88014649f3c0 1804623415 C Co:4:001:0 0 0 >>> > >>> > Do you have any idea why it is doing this? >>> >>> If a warm reset failed, the USB core will put the port into SS.Disabled. >>> If enumeration fails in the right places, the port will also be >>> disabled. >> >> As far as I can tell from the usbmon trace, the reset succeeded. >> >>> dmesg with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING might help >>> me understand what's going on. > > A log with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING enabled > is attached to this mail. > Note that the issue only occures if the drive is connected to the usb3 > port of my docking station. (As described in > https://bugzilla.redhat.com/show_bug.cgi?id=984189 .) Are there any news about this issue? -- 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: some questions about ehci period scheduling
On Sat, 7 Sep 2013, vichy wrote: > hi all: > when I trace linux ehci driver source code. > I have some questions > 1. in itd_slot_ok, why we have to > uframe %= period; > and use this uframe to calculate the bandwidth? > > suppose start passed to itd_slot_ok is 537, period, usb->interval, is 8. > that mean we want to know whether bandwidth of microframe 537 is enough. > Not want to know whether 537%8 =1 > the bandwidth of microframe 1 is enough. In fact you need to know both. If an isochronous endpoint has interval 8 and it uses microframe 537, then it's also going to use microframes 545, 553, 561, ..., 8177, 8185, 1, 9, ..., 529. > 2. Below is part of message excerpted from usb mon log: > db1e2000 81051026 S Zi:1:002:6 -115:8:5327 1 -18:0:132 132 < > db1e2000 81058043 C Zi:1:002:6 0:8:5391:0 1 0:0:4 132 = 2efd82fd > 0cfe 84feb3ff 98fec4fb 08ffdaf8 060059fb 8b01d2ff db02de01 > > why these 2 ep->start_frame are different, 5327 in "-115:8:5327" and > 5391 in "0:8:5391:0"? > > The log is captured with the same urb, for submitting and completing. > That mean ep->start_frame=urb->start_frame in submit and complete > should be the same, right? No. The value in urb->start_frame during submission is meaningless. Usually it is left over from the last time urb was used. After the URB is submitted, the host controller driver stores the correct value in urb->start_frame, and usbmon shows the correct value during completion. Alan Stern -- 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 usb issues with Etron Technology, Inc. EJ168 USB 3.0 Host Controller
On Sat, 7 Sep 2013, joe M wrote: > Hello Sarah, Alan, > > Just wanted to check if you have any suggestions on how to go about > debugging this issue. Nothing that I haven't mentioned previously. > I get these messages "usb 6-1: device not accepting address 5, error > -62" when I connect my FS device to a USB 3.0 hub. I logged the > messages from the device and can see a USB Reset happening. But, > nothing else is happening after that. > > I attached a USB mouse to the USB3.0 port and it worked. I attach my > FS device to a USB 2.0 or USB 1.1 port and it works. You should note that when a device is attached to a USB-2 or USB-1.1 port, the computer does the following: Port reset Send a 64-byte Get-Device-Descriptor request to address 0 (the device will return only the first 8, 16, or 18 bytes of the descriptor, depending on the maxpacket size for ep0) Port reset Send a Set-Address request Send an 18-byte Get-Device-Descriptor request By contrast, when a device is attached to a USB-3 port, the computer does the following: Port reset Send a Set-Address request Send an 8-byte Get-Device-Descriptor request Send an 18-byte Get-Device-Descriptor request It's possible that your device works with the first event sequence and not the second. What happens if you do: echo 1 >/sys/module/usbcore/parameters/old_scheme_first before plugging the device into a USB-2/1.1 port? This will cause the system to use the second procedure above instead of the first. Alan Stern -- 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
"Virtual" Interrupts -- Need help please
I've posted a number of requests for aid on this and have gotten very little responses and none that were helpful. I have spent at least 24 hours of research time on this and just a little direction from somebody who knows this subsystem can help me immensely as the IRQ subsystem is new to me. This is for the MCP2210 driver (a USB to SPI/GPIO bridge) and my driver is the first of its class for the Linux kernel, giving me less to look at as an example. I intend to use standard drivers for whatever I have connected at the other end. For this to work, I need to supply interrupts for some of these drivers to work correctly. How do I do this? Every thing else on this driver is ready to go and my handler functions for this are empty and waiting for some code. So do i create an IRQ domain and then call generic_handle_irq() from my URB complete() function? If so, which type of IRQ Domain is appropriate for this? Unlike typical platform devices, these are dynamically added and removed throughout the life of the kernel, adding to the challenge. So, if I understand correctly, my base IRQ number needs to be dynamically generated. How should I manage this? Finally, if you have any example drivers that are doing something similar, that would be SO very helpful as well! I have some secondary (and less important) questions about how to integrate this with device drivers that want a DT / open firmware config (which I know almost nothing about at this time), but that can wait. Any help *greatly* appreciated and thank you in advance! Daniel PS: If interested, my current driver here: https://github.com/daniel-santos/mcp2210-linux. I haven't sought review yet because I want to finish it first. -- 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: "Virtual" Interrupts -- Need help please
On 09/07/2013 05:19 PM, Daniel Santos wrote: I've posted a number of requests for aid on this and have gotten very little responses and none that were helpful. I have spent at least 24 hours of research time on this and just a little direction from somebody who knows this subsystem can help me immensely as the IRQ subsystem is new to me. This is for the MCP2210 driver (a USB to SPI/GPIO bridge) and my driver is the first of its class for the Linux kernel, giving me less to look at as an example. I intend to use standard drivers for whatever I have connected at the other end. For this to work, I need to supply interrupts for some of these drivers to work correctly. How do I do this? Every thing else on this driver is ready to go and my handler functions for this are empty and waiting for some code. Not really. Have a look at https://github.com/groeck/diolan even though the SPI part there still isn't working and it is far from being acceptable upstream in its current form. It also doesn't support interrupts. It is modeled as mfd driver, which I think you might want to consider as well. So do i create an IRQ domain and then call generic_handle_irq() from my URB complete() function? If so, which type of IRQ Domain is appropriate for this? Unlike typical platform devices, these are dynamically added and removed throughout the life of the kernel, adding to the challenge. So, if I understand correctly, my base IRQ number needs to be dynamically generated. How should I manage this? Finally, if you have any example drivers that are doing something similar, that would be SO very helpful as well! There are several drivers in drivers/mfd solving the same problem, ie using irq domains to pass interrupts to client drivers. Look for irq_domain_add_simple(). drivers/mfd/tc3589x.c seems to be a good example. I have some secondary (and less important) questions about how to integrate this with device drivers that want a DT / open firmware config (which I know almost nothing about at this time), but that can wait. If you look into the mfd subsystem, you may notice that it handles at least some of the complexity of interrupt handling as well as devicetree integration. One more reason to use it. Guenter Any help *greatly* appreciated and thank you in advance! Daniel PS: If interested, my current driver here: https://github.com/daniel-santos/mcp2210-linux. I haven't sought review yet because I want to finish it first. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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
It is Utterly Privy
It is Private I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other better. However, I am contacting you for obvious reason which you will understand. I am sending this mail just to know if this email address is OK, reply me back so that I will send more details to you. I have a very important thing to discuss with you, I look forward to receiving your response at georgedani...@postino.net. Have a pleasant day. George Daniels -- 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 usb issues with Etron Technology, Inc. EJ168 USB 3.0 Host Controller
Hello Alan, >> Just wanted to check if you have any suggestions on how to go about >> debugging this issue. > > Nothing that I haven't mentioned previously. Thank you for your thoughts. I could not get a logic analyzer to figure out the signals on the lines. But, I could log the usb interrupts from the device though. > You should note that when a device is attached to a USB-2 or USB-1.1 > port, the computer does the following: > > Port reset > > Send a 64-byte Get-Device-Descriptor request to address 0 (the > device will return only the first 8, 16, or 18 bytes of the > descriptor, depending on the maxpacket size for ep0) > > Port reset > > Send a Set-Address request > > Send an 18-byte Get-Device-Descriptor request > > By contrast, when a device is attached to a USB-3 port, the computer > does the following: > > Port reset > > Send a Set-Address request > > Send an 8-byte Get-Device-Descriptor request > > Send an 18-byte Get-Device-Descriptor request > > It's possible that your device works with the first event sequence and > not the second. What happens if you do: > > echo 1 >/sys/module/usbcore/parameters/old_scheme_first > > before plugging the device into a USB-2/1.1 port? This will cause the > system to use the second procedure above instead of the first. Attached is the output when I have the old_scheme_first parameter set to 1/Y. The device is recognized fine with a non-usb 3.0 port. When I log from the device, I see just the Port reset. I do not see the Set-Address request (or, any other txn coming through) coming through to the device. Thanks again for your thoughts. If you can think of something else to check, please let me know. Sorry for the bother, Joe smart_sudo Password: master# echo 1 >/sys/module/usbcore/parameters/old_scheme_first master# cat /sys/module/usbcore/parameters/old_scheme_first Y master# exit - (0:i:~) - - - - - - - - - - - - - - - - - - - - - - - - - - - smart_sudo tail -f /var/log/syslog Sep 7 19:59:37 master kernel: [ 22.960313] usbhid 1-1.3:1.2: usb_probe_interface Sep 7 19:59:37 master kernel: [ 22.960316] usbhid 1-1.3:1.2: usb_probe_interface - got id Sep 7 19:59:37 master kernel: [ 22.962297] input: Razer BlackWidow Razer BlackWidow as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.2/input/input15 Sep 7 19:59:37 master kernel: [ 22.962406] ehci-pci :00:1a.0: reused qh 880220fd8880 schedule Sep 7 19:59:37 master kernel: [ 22.962410] usb 1-1.3: link qh8-0e01/880220fd8880 start 5 [1/2 us] Sep 7 19:59:37 master kernel: [ 22.962776] hid-generic 0003:1532:010E.0005: input,hidraw2: USB HID v1.11 Mouse [Razer BlackWidow Razer BlackWidow] on usb-:00:1a.0-1.3/input2 Sep 7 19:59:40 master dhcpcd[686]: eth0: sending IPv6 Router Solicitation Sep 7 19:59:42 master dhcpcd[686]: eth0: leased 192.168.0.11 for 3600 seconds Sep 7 19:59:44 master dhcpcd[686]: eth0: sending IPv6 Router Solicitation Sep 7 19:59:44 master dhcpcd[686]: eth0: no IPv6 Routers available Sep 7 20:02:08 master kernel: [ 173.816472] hub 1-1:1.0: state 7 ports 6 chg evt 0040 Sep 7 20:02:08 master kernel: [ 173.827379] usb 1-1.6: usb wakeup-resume Sep 7 20:02:08 master kernel: [ 173.827493] usb 1-1.6: finish resume Sep 7 20:02:08 master kernel: [ 173.827960] hub 1-1.6:1.0: hub_resume Sep 7 20:02:08 master kernel: [ 173.828679] hub 1-1.6:1.0: port 2: status 0101 change 0001 Sep 7 20:02:08 master kernel: [ 173.930457] ehci-pci :00:1a.0: reused qh 880225ad2800 schedule Sep 7 20:02:08 master kernel: [ 173.930465] usb 1-1.6: link qh256-0001/880225ad2800 start 4 [1/0 us] Sep 7 20:02:08 master kernel: [ 173.930474] hub 1-1:1.0: resume on port 6, status 0 Sep 7 20:02:08 master kernel: [ 173.930479] hub 1-1.6:1.0: state 7 ports 4 chg 0004 evt Sep 7 20:02:08 master kernel: [ 173.930768] hub 1-1.6:1.0: port 2, status 0101, change , 12 Mb/s Sep 7 20:02:08 master kernel: [ 173.941871] hub 1-1.6:1.0: port 2 not reset yet, waiting 10ms Sep 7 20:02:08 master kernel: [ 174.003929] usb 1-1.6.2: new full-speed USB device number 6 using ehci-pci Sep 7 20:02:08 master kernel: [ 174.015809] usb 1-1.6.2: ep0 maxpacket = 8 Sep 7 20:02:08 master kernel: [ 174.017843] usb 1-1.6.2: skipped 1 descriptor after interface Sep 7 20:02:08 master kernel: [ 174.018806] usb 1-1.6.2: skipped 1 descriptor after interface Sep 7 20:02:08 master kernel: [ 174.019807] usb 1-1.6.2: skipped 1 descriptor after interface Sep 7 20:02:08 master kernel: [ 174.020050] usb 1-1.6.2: default language 0x0409 Sep 7 20:02:08 master kernel: [ 174.020932] usb 1-1.6.2: udev 6, busnum 1, minor = 5 Sep 7 20:02:08 master kernel: [ 174.020935] usb 1-1.6.2: New USB device found, idVendor=03eb, idProduct=204d Sep 7 20:02:08 master kernel: [ 174.020937] usb 1-1.6.2: New USB device strings: Mfr=1, Product=2, SerialNum
Re: xhci usb issues with Etron Technology, Inc. EJ168 USB 3.0 Host Controller
On Sat, 7 Sep 2013, joe M wrote: > Hello Alan, > > >> Just wanted to check if you have any suggestions on how to go about > >> debugging this issue. > > > > Nothing that I haven't mentioned previously. > > Thank you for your thoughts. I could not get a logic analyzer to > figure out the signals on the lines. But, I could log the usb > interrupts from the device though. In the end, you may need to figure out a way to analyze those signals. > Attached is the output when I have the old_scheme_first parameter set > to 1/Y. The device is recognized fine with a non-usb 3.0 port. > > When I log from the device, I see just the Port reset. I do not see > the Set-Address request (or, any other txn coming through) coming > through to the device. So either the host controller didn't actually send the Set-Address command, or else the device didn't recognize it. I can't think of any way to tell which occurred without analyzing the bus signals (unless perhaps you can locate a bug in the device). Alan Stern -- 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
