RE: Not enough resource for old configuration after USB bus reset
Hi, I try two experiment, 1. Test it on general desktop, the device will enum as CDC_ECM( 1 control, 2 bulk, 1 interrupt), and CDC_ECM driver will use interupt to polling link status. 2. Test it on embedded system, the device will controlled by a custom driver ( 1 control, 2 bulk, 1 interrupt). The configure endpoint will allocate bandwith for interrupt endpoint. But the driver nevery use interrupt endpoint. So you had your system set up like described in #2, and you still ran out of bandwidth after a lot of device resets? The host on #2 is as the same as #1. The major difference is the usb interface driver, one is customize driver(#2), another one is CDC_ECM from gadget(#1). Best regards, Soar -- 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: Not enough resource for old configuration after USB bus reset
Maybe I can try this with the mouse. As far as I know, most HDD and pendrive do not use periodic tranfer. So they can not produce the issue. few emails back you said it had nothing to do with periodic transfers. -ECONFUSED I try two experiment, 1. Test it on general desktop, the device will enum as CDC_ECM( 1 control, 2 bulk, 1 interrupt), and CDC_ECM driver will use interupt to polling link status. 2. Test it on embedded system, the device will controlled by a custom driver ( 1 control, 2 bulk, 1 interrupt). The configure endpoint will allocate bandwith for interrupt endpoint. But the driver nevery use interrupt endpoint. In previous mail, I reply the experiment 2 as you suggest try not sending any periodic transfer. The real issue is related to xHC(hardware) allocate bandwidth to periodic endpoint. Hope this explanation clearify your question. Thanks.-- 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: Not enough resource for old configuration after USB bus reset
On Wed, Feb 27, 2013 at 07:46:35PM +0800, Soar Hung wrote: Maybe I can try this with the mouse. As far as I know, most HDD and pendrive do not use periodic tranfer. So they can not produce the issue. few emails back you said it had nothing to do with periodic transfers. -ECONFUSED I try two experiment, 1. Test it on general desktop, the device will enum as CDC_ECM( 1 control, 2 bulk, 1 interrupt), and CDC_ECM driver will use interupt to polling link status. 2. Test it on embedded system, the device will controlled by a custom driver ( 1 control, 2 bulk, 1 interrupt). The configure endpoint will allocate bandwith for interrupt endpoint. But the driver nevery use interrupt endpoint. In previous mail, I reply the experiment 2 as you suggest try not sending any periodic transfer. The real issue is related to xHC(hardware) allocate bandwidth to periodic endpoint. So you had your system set up like described in #2, and you still ran out of bandwidth after a lot of device resets? Sarah Sharp -- 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: Not enough resource for old configuration after USB bus reset
Hi, On Tue, Feb 26, 2013 at 01:04:50PM +0800, Soar Hung wrote: Hi all, thanks for your help. I just ran 10K resets with each of 3 different devices (USB3 HDD, USB2 pendrive and a mouse) and I didn't see the problem you're saying here. Tested with TUSB7340EVM on v3.8.0. Maybe I can try this with the mouse. As far as I know, most HDD and pendrive do not use periodic tranfer. So they can not produce the issue. few emails back you said it had nothing to do with periodic transfers. -ECONFUSED The lspci shows Texas Instruments Device 8241 (rev 02). Is this the same? 03:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller (rev 02) (prog-if 30 [XHCI]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 30 Region 0: Memory at f3ff (64-bit, non-prefetchable) [size=64K] Region 2: Memory at f3fee000 (64-bit, non-prefetchable) [size=8K] Capabilities: access denied Kernel driver in use: xhci_hcd -- balbi signature.asc Description: Digital signature
Re: Not enough resource for old configuration after USB bus reset
Hi, On Wed, Feb 20, 2013 at 11:53:26AM -0800, Sarah Sharp wrote: On Wed, Feb 20, 2013 at 10:14:46AM -0800, Sarah Sharp wrote: Are you sure the TI host and your host isn't neglecting to drop endpoint resources when the Reset Device command is handled? I double checked your test file on the latest Intel xHCI host, and it's up to over 4,000 successful resets of a USB mouse with a periodic IN endpoint. I tried it with a USB ethernet dongle, but after about a hundred resets, the device returned different device descriptors. The USB core treated it as a new device and assigned it a different address, which caused the script to fail since the /dev/bus/usb files went away. Was there a different device you would like me to test with? Basically, I think this is a host-specific bug. We can certainly work around it in the xHCI driver with a quirk for all hosts that have this resource tracking problem. We would issue a Configure Endpoint command to drop all endpoints before the Reset Device command. However, I would really suggest you fix your host controller. Can you send me the output of `sudo lspci -vvv` and `sudo lspci -vvv -n` when the TI host is attached to your system? I'll send you a patch with the workaround fix to test. We can also add a quirk for your host, if your host controller is already available with this issue, and you're planning on having the mainline kernel support your host controller. What's the actual issue here ? Can you explain to me Sarah ? This may be a known issue regarding this particular host controller and if it is, there might already be workarounds available. If the problem is related only to device reset, then it would have failed USB30CV Device Reset test which drives 500 Device Resets and checks that device reenumerates. I doubt that's the case though, since TI's TUSB7340 is built with a USB3 Certified IP. cheers -- balbi signature.asc Description: Digital signature
RE: Not enough resource for old configuration after USB bus reset
What's the actual issue here ? Can you explain to me Sarah ? This may be a known issue regarding this particular host controller and if it is, there might already be workarounds available. I copy the previous content and try to make it more clear. When calling usb_reset_and_verify_device, hcd issue a reset command. The reset device command make the endpoint state disabled without releaseing the bandwidth. After reset is done, the HCD try to reconfigure the device to previous active config by usb_hcd_alloc_bandwidth. The HCD does such thing by modifying drop and add flag in input context, and issue configure endpoint command to comoplete the operation. When executing drop_endpoint, the endpoint is already in the disabled state. This behavior is correct according to the spec. And the HC will not evaluate drop flag of disable endpoint,too. As a result, the HC can not drop the endpoint to release the bandwidth. Then add_endpoint to enable these endpoints. After all drop add flag are set, HCD sends a configure endpoint command to complete the change. Before the priodic bandiwdth is used up, the configure endpoint command can success. However, after reset several times, the configure endpoint command fail with command status not enough bandwidth. And the HC can not correctly configure any more periodic device. If the problem is related only to device reset, then it would have failed USB30CV Device Reset test which drives 500 Device Resets and checks that device reenumerates. I doubt that's the case though, since TI's TUSB7340 is built with a USB3 Certified IP. We have try two devices, both are USB-IF certified, on this host and they fail with same scenario. And these two devices can successfully reset several times on some other host.-- 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: Not enough resource for old configuration after USB bus reset
HI, On Mon, Feb 25, 2013 at 07:33:23PM +0800, Soar Hung wrote: What's the actual issue here ? Can you explain to me Sarah ? This may be a known issue regarding this particular host controller and if it is, there might already be workarounds available. I copy the previous content and try to make it more clear. When calling usb_reset_and_verify_device, hcd issue a reset command. The reset device command make the endpoint state disabled without releaseing the bandwidth. After reset is done, the HCD try to reconfigure the device to previous active config by usb_hcd_alloc_bandwidth. The HCD does such thing by modifying drop and add flag in input context, and issue configure endpoint command to comoplete the operation. When executing drop_endpoint, the endpoint is already in the disabled state. This behavior is correct according to the spec. And the HC will not evaluate drop flag of disable endpoint,too. fair enough. As a result, the HC can not drop the endpoint to release the bandwidth. But if the endpoint is already dropped, why hasn't bandwidth allocation being released too ? Sarah ? Then add_endpoint to enable these endpoints. After all drop add flag are set, HCD sends a configure endpoint command to complete the change. right. Before the priodic bandiwdth is used up, the configure endpoint command can success. However, after reset several times, the configure endpoint command fail with command status not enough bandwidth. And the HC can not correctly configure any more periodic device. this does sound like a known errata. Unfortunately there's no suggested for it. Just to make sure this is really the case, can you, somehow, make sure that no transfers are ever scheduled to any of the periodic endpoints and see if that solves the issue. If it turns own that this helps, then we're talking about a known errata. It will just take some time to figure out how to work around it provided there are no suggested workarounds on the errata description. I'll try to reproduce it here with a mouse (I happen to have a TUSB7340 too in my PC), if it fails the same way, I'll have a simple way to try, but meanwhile please check that preventing transfers from being scheduled to any periodic EP makes your test work. If the problem is related only to device reset, then it would have failed USB30CV Device Reset test which drives 500 Device Resets and checks that device reenumerates. I doubt that's the case though, since TI's TUSB7340 is built with a USB3 Certified IP. We have try two devices, both are USB-IF certified, on this host and they fail with same scenario. And these two devices can successfully reset several times on some other host. that's alright, I'm just wondering how come this wasn't caught during certification... perhaps certification lab didn't use a device with periodic endpoints to run the test. cheers -- balbi signature.asc Description: Digital signature
RE: Not enough resource for old configuration after USB bus reset
Felipe Balbi wrote: HI, On Mon, Feb 25, 2013 at 07:33:23PM +0800, Soar Hung wrote: What's the actual issue here ? Can you explain to me Sarah ? This may be a known issue regarding this particular host controller and if it is, there might already be workarounds available. I copy the previous content and try to make it more clear. When calling usb_reset_and_verify_device, hcd issue a reset command. The reset device command make the endpoint state disabled without releaseing the bandwidth. After reset is done, the HCD try to reconfigure the device to previous active config by usb_hcd_alloc_bandwidth. The HCD does such thing by modifying drop and add flag in input context, and issue configure endpoint command to comoplete the operation. When executing drop_endpoint, the endpoint is already in the disabled state. This behavior is correct according to the spec. And the HC will not evaluate drop flag of disable endpoint,too. fair enough. As a result, the HC can not drop the endpoint to release the bandwidth. But if the endpoint is already dropped, why hasn't bandwidth allocation being released too ? Sarah ? HCD fill the drop/add flag of input context, and issue configure command to tell HC evaluate the flag. The realease is done when HC evaluate drop flag. But HCD and HC will not do drop operation since it is disabled. Then add_endpoint to enable these endpoints. After all drop add flag are set, HCD sends a configure endpoint command to complete the change. right. Before the priodic bandiwdth is used up, the configure endpoint command can success. However, after reset several times, the configure endpoint command fail with command status not enough bandwidth. And the HC can not correctly configure any more periodic device. this does sound like a known errata. Unfortunately there's no suggested for it. Just to make sure this is really the case, can you, somehow, make sure that no transfers are ever scheduled to any of the periodic endpoints and see if that solves the issue. We found this issue on our embedded system. The driver is wrote with no periodic transfer. So it might not solve the issue. Thanks for the suggesstion. If it turns own that this helps, then we're talking about a known errata. It will just take some time to figure out how to work around it provided there are no suggested workarounds on the errata description. I'll try to reproduce it here with a mouse (I happen to have a TUSB7340 too in my PC), if it fails the same way, I'll have a simple way to try, but meanwhile please check that preventing transfers from being scheduled to any periodic EP makes your test work. I have do some trick on my embedded system HCD source. Make it always not set the periodic endpoint add flag (because we don't use it on the embedded system), And this provide us a work-around solution temporarily. But I know this is not correct method, I just want to bypass it. If the problem is related only to device reset, then it would have failed USB30CV Device Reset test which drives 500 Device Resets and checks that device reenumerates. I doubt that's the case though, since TI's TUSB7340 is built with a USB3 Certified IP. We have try two devices, both are USB-IF certified, on this host and they fail with same scenario. And these two devices can successfully reset several times on some other host. that's alright, I'm just wondering how come this wasn't caught during certification... perhaps certification lab didn't use a device with periodic endpoints to run the test. cheers Best regards, Soar -- 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: Not enough resource for old configuration after USB bus reset
Hi, On Mon, Feb 25, 2013 at 07:56:49PM +0800, Soar Hung wrote: Then add_endpoint to enable these endpoints. After all drop add flag are set, HCD sends a configure endpoint command to complete the change. right. Before the priodic bandiwdth is used up, the configure endpoint command can success. However, after reset several times, the configure endpoint command fail with command status not enough bandwidth. And the HC can not correctly configure any more periodic device. this does sound like a known errata. Unfortunately there's no suggested for it. Just to make sure this is really the case, can you, somehow, make sure that no transfers are ever scheduled to any of the periodic endpoints and see if that solves the issue. We found this issue on our embedded system. The driver is wrote with no periodic transfer. So it might not solve the issue. fair enough, I'll continue to try out on my end too. cheers -- balbi signature.asc Description: Digital signature
Re: Not enough resource for old configuration after USB bus reset
Hi, On Mon, Feb 25, 2013 at 02:03:56PM +0200, Felipe Balbi wrote: On Mon, Feb 25, 2013 at 07:56:49PM +0800, Soar Hung wrote: Then add_endpoint to enable these endpoints. After all drop add flag are set, HCD sends a configure endpoint command to complete the change. right. Before the priodic bandiwdth is used up, the configure endpoint command can success. However, after reset several times, the configure endpoint command fail with command status not enough bandwidth. And the HC can not correctly configure any more periodic device. this does sound like a known errata. Unfortunately there's no suggested for it. Just to make sure this is really the case, can you, somehow, make sure that no transfers are ever scheduled to any of the periodic endpoints and see if that solves the issue. We found this issue on our embedded system. The driver is wrote with no periodic transfer. So it might not solve the issue. fair enough, I'll continue to try out on my end too. I just ran 10K resets with each of 3 different devices (USB3 HDD, USB2 pendrive and a mouse) and I didn't see the problem you're saying here. Tested with TUSB7340EVM on v3.8.0. cheers -- balbi signature.asc Description: Digital signature
Re: Not enough resource for old configuration after USB bus reset
On Mon, Feb 25, 2013 at 01:42:44PM +0200, Felipe Balbi wrote: HI, On Mon, Feb 25, 2013 at 07:33:23PM +0800, Soar Hung wrote: What's the actual issue here ? Can you explain to me Sarah ? This may be a known issue regarding this particular host controller and if it is, there might already be workarounds available. I copy the previous content and try to make it more clear. When calling usb_reset_and_verify_device, hcd issue a reset command. The reset device command make the endpoint state disabled without releaseing the bandwidth. After reset is done, the HCD try to reconfigure the device to previous active config by usb_hcd_alloc_bandwidth. The HCD does such thing by modifying drop and add flag in input context, and issue configure endpoint command to comoplete the operation. When executing drop_endpoint, the endpoint is already in the disabled state. This behavior is correct according to the spec. And the HC will not evaluate drop flag of disable endpoint,too. fair enough. As a result, the HC can not drop the endpoint to release the bandwidth. But if the endpoint is already dropped, why hasn't bandwidth allocation being released too ? Sarah ? I think we're talking past each other. :) Soar, what bandwidth allocation resources are you talking about? In the xHC hardware, or in the xHCI driver? I've been talking about resources in the hardware only, but I want to confirm we're talking about the same thing. As I understand it, the Reset Device command should drop all bandwidth allocated within the xHC hardware. Then we go back and re-add the endpoints, setting only the add flag in the input context. As Soar mentioned, this is spec-compliant, but the host eventually gives an out-of-bandwidth completion code for the Configure Endpoint command. Then add_endpoint to enable these endpoints. After all drop add flag are set, HCD sends a configure endpoint command to complete the change. right. Before the priodic bandiwdth is used up, the configure endpoint command can success. However, after reset several times, the configure endpoint command fail with command status not enough bandwidth. And the HC can not correctly configure any more periodic device. this does sound like a known errata. Unfortunately there's no suggested for it. Just to make sure this is really the case, can you, somehow, make sure that no transfers are ever scheduled to any of the periodic endpoints and see if that solves the issue. If it turns own that this helps, then we're talking about a known errata. It will just take some time to figure out how to work around it provided there are no suggested workarounds on the errata description. I'll try to reproduce it here with a mouse (I happen to have a TUSB7340 too in my PC), if it fails the same way, I'll have a simple way to try, but meanwhile please check that preventing transfers from being scheduled to any periodic EP makes your test work. If the problem is related only to device reset, then it would have failed USB30CV Device Reset test which drives 500 Device Resets and checks that device reenumerates. I doubt that's the case though, since TI's TUSB7340 is built with a USB3 Certified IP. We have try two devices, both are USB-IF certified, on this host and they fail with same scenario. And these two devices can successfully reset several times on some other host. that's alright, I'm just wondering how come this wasn't caught during certification... perhaps certification lab didn't use a device with periodic endpoints to run the test. Or maybe they issue a Configure Endpoint command to drop all endpoints before they issue the Reset Device command? That was my proposed work-around. Sarah Sharp -- 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: Not enough resource for old configuration after USB bus reset
Hi, On Mon, Feb 25, 2013 at 09:32:51AM -0800, Sarah Sharp wrote: If the problem is related only to device reset, then it would have failed USB30CV Device Reset test which drives 500 Device Resets and checks that device reenumerates. I doubt that's the case though, since TI's TUSB7340 is built with a USB3 Certified IP. We have try two devices, both are USB-IF certified, on this host and they fail with same scenario. And these two devices can successfully reset several times on some other host. that's alright, I'm just wondering how come this wasn't caught during certification... perhaps certification lab didn't use a device with periodic endpoints to run the test. Or maybe they issue a Configure Endpoint command to drop all endpoints before they issue the Reset Device command? That was my proposed work-around. well, if it works, great :-) Funny that I couldn't reproduce it here though :-s -- balbi signature.asc Description: Digital signature
Re: Not enough resource for old configuration after USB bus reset
On Mon, Feb 25, 2013 at 04:38:06PM +0800, Soar Hung wrote: -Original Message- From: Lan Tianyu [mailto:lantianyu1...@gmail.com] Sent: Wednesday, February 20, 2013 4:14 PM To: Soar Hung Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org Subject: Re: Not enough resource for old configuration after USB bus reset 2013/2/19 Soar Hung soarh...@realtek.com: Hi all, I checkout the usb-next branch (on 2/18) and following the https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build the kernel. After reboot, the new kernel version is Linux dev 3.8.0-rc5-usbnext #1 SMP Mon Feb 18 18:04:02 CST 2013 i686 i686 i386 GNU/Linux. I try the same operation to produce the issue, and it also fails. Please attach the output of dmesg with CONFIG_USB_DEBUG and XHCI_DEBUG. With these two debug config on, the dmesg buffer even can not log one reset operation. You can increase your buffer size by setting CONFIG_LOG_BUF_SHIFT=21. What information do we want from these two debug config? Everything. I'd like to understand exactly what's happening at the xHCI driver level. I probably only need to see three reset cycles. Zip up the log file or use pastebin if you think the log file is too big. We currently know that the issue is fail at the configure endpoint command after bus reset. The failing reason is the reset operation make the endpoint state disabled, and HCD still try to drop the disabled endpoint. This cause the host can not manage its resouce correctly. As a result, the last configure command fail with not enough bandwidth. Are you saying the xHCI driver is trying to issue a Configure Endpoint command with the drop flag set for an endpoint that was removed by the Reset Device command? If so, I would like to see the log files so I can debug why that happened. Sarah Sharp -- 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: Not enough resource for old configuration after USB bus reset
Hi all, thanks for your help. I just ran 10K resets with each of 3 different devices (USB3 HDD, USB2 pendrive and a mouse) and I didn't see the problem you're saying here. Tested with TUSB7340EVM on v3.8.0. Maybe I can try this with the mouse. As far as I know, most HDD and pendrive do not use periodic tranfer. So they can not produce the issue. The lspci shows Texas Instruments Device 8241 (rev 02). Is this the same? Best regards, Soar -- 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: Not enough resource for old configuration after USB bus reset
I try the same operation to produce the issue, and it also fails. Please attach the output of dmesg with CONFIG_USB_DEBUG and XHCI_DEBUG. With these two debug config on, the dmesg buffer even can not log one reset operation. You can increase your buffer size by setting CONFIG_LOG_BUF_SHIFT=21. What information do we want from these two debug config? Everything. I'd like to understand exactly what's happening at the xHCI driver level. I probably only need to see three reset cycles. Zip up the log file or use pastebin if you think the log file is too big. I will append the dmesg log later. We currently know that the issue is fail at the configure endpoint command after bus reset. The failing reason is the reset operation make the endpoint state disabled, and HCD still try to drop the disabled endpoint. This cause the host can not manage its resouce correctly. As a result, the last configure command fail with not enough bandwidth. Are you saying the xHCI driver is trying to issue a Configure Endpoint command with the drop flag set for an endpoint that was removed by the Reset Device command? If so, I would like to see the log files so I can debug why that happened. No. the drop endpoint function will notice the ep state is disabled, And shows message like drop endponits with disabled endpoint, then skip the set drop flag. Soar -- 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: Not enough resource for old configuration after USB bus reset
Can you send me the output of `sudo lspci -vvv` and `sudo lspci -vvv -n` when the TI host is attached to your system? I'll send you a patch with the workaround fix to test. We can also add a quirk for your host, if your host controller is already available with this issue, and you're planning on having the mainline kernel support your host controller. Please check the following link Lspci -vvv http://pastebin.com/SBkncaBf Lspci -vvv -n http://pastebin.com/i464n0AT Thanks, Soar -- 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: Not enough resource for old configuration after USB bus reset
linux-usb-ow...@vger.kernel.org wrote: On Mon, Feb 25, 2013 at 01:42:44PM +0200, Felipe Balbi wrote: HI, On Mon, Feb 25, 2013 at 07:33:23PM +0800, Soar Hung wrote: What's the actual issue here ? Can you explain to me Sarah ? This may be a known issue regarding this particular host controller and if it is, there might already be workarounds available. I copy the previous content and try to make it more clear. When calling usb_reset_and_verify_device, hcd issue a reset command. The reset device command make the endpoint state disabled without releaseing the bandwidth. After reset is done, the HCD try to reconfigure the device to previous active config by usb_hcd_alloc_bandwidth. The HCD does such thing by modifying drop and add flag in input context, and issue configure endpoint command to comoplete the operation. When executing drop_endpoint, the endpoint is already in the disabled state. This behavior is correct according to the spec. And the HC will not evaluate drop flag of disable endpoint,too. As a result, the HC can not drop the endpoint to release the bandwidth. But if the endpoint is already dropped, why hasn't bandwidth allocation being released too ? Sarah ? I think we're talking past each other. :) Soar, what bandwidth allocation resources are you talking about? In the xHC hardware, or in the xHCI driver? I've been talking about resources in the hardware only, but I want to confirm we're talking about the same thing. As my understading, the bandwidth is managed by xHC(hardware), The HCD(driver) only use xHCI input context and command to tell xHC do something. As I understand it, the Reset Device command should drop all bandwidth allocated within the xHC hardware. Then we go back and re-add the endpoints, setting only the add flag in the input context. As Soar mentioned, this is spec-compliant, but the host eventually gives an out-of-bandwidth completion code for the Configure Endpoint command. Now I understand why this is QUIRK not a fix. Spec 4.6.11 says the xHC shall release bandwidth automatically when doing reset device command. Best regards, Soar -- 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: Not enough resource for old configuration after USB bus reset
I try the same operation to produce the issue, and it also fails. Please attach the output of dmesg with CONFIG_USB_DEBUG and XHCI_DEBUG. With these two debug config on, the dmesg buffer even can not log one reset operation. You can increase your buffer size by setting CONFIG_LOG_BUF_SHIFT=21. What information do we want from these two debug config? Everything. I'd like to understand exactly what's happening at the xHCI driver level. I probably only need to see three reset cycles. Zip up the log file or use pastebin if you think the log file is too big. I will append the dmesg log later. Please reference the following link First attach : http://pastebin.com/nN3SQuy0 Last few reset http://pastebin.com/L2GxaS5M Thanks, Soar -- 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: Not enough resource for old configuration after USB bus reset
2013/2/19 Soar Hung soarh...@realtek.com: Hi all, I checkout the usb-next branch (on 2/18) and following the https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build the kernel. After reboot, the new kernel version is Linux dev 3.8.0-rc5-usbnext #1 SMP Mon Feb 18 18:04:02 CST 2013 i686 i686 i386 GNU/Linux. I try the same operation to produce the issue, and it also fails. Please attach the output of dmesg with CONFIG_USB_DEBUG and XHCI_DEBUG. Thanks, Soar -Original Message- From: Lan Tianyu [mailto:lantianyu1...@gmail.com] Sent: Friday, February 08, 2013 12:57 AM To: Soar Hung Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org Subject: Re: Not enough resource for old configuration after USB bus reset 于 2013/2/7 16:59, Soar Hung 写道: Hi Tianyu, I can produce the issue on the Ubuntu 12.10 (linux 3.5), too. However, could you tell me more detail about what to do or give me some hint for google? Do you mean replacing the usb related source with source from 'usb next', rebuild the kernel, and test again? I think you can git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git and git checkout usb-next. Compile kernel and test it. Best regards, Soar -Original Message- From: Lan Tianyu [mailto:lantianyu1...@gmail.com] Sent: Thursday, February 07, 2013 4:18 PM To: Soar Hung Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org Subject: Re: Not enough resource for old configuration after USB bus reset 2013/2/4 Soar Hung soarh...@realtek.com: Hi Alan, Sarah, Thank you for your kindly help. Can I do something to provide some help? You found the issue on the 3.0.30+ kernel. Can you test it on the usb-next branch of usb tree? Sarah has fixed a lot of bugs since v3.0. Best regards, Soar -Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Friday, February 01, 2013 11:36 PM To: Soar Hung Cc: Sarah Sharp; linux-usb@vger.kernel.org Subject: RE: Not enough resource for old configuration after USB bus reset On Fri, 1 Feb 2013, [big5] x R wrote: Hi, According to xHCI spec Rev1 page 125, Endpoint context state diagram. When reset device, the endpoint state transit to disabled state. Do I make some mistake? I'll try to figure out the endopint state transitions during the reset flow, and update information later. Thanks for the direction. Ah, now I understand the problem. The device reset automatically disables the endpoints, so when usb_reset_and_verify_device calls usb_hcd_alloc_bandwidth, and that routine tries to drop the endpoints, it fails because the endpoints are already disabled. Sarah is going to to have to figure out the right way to fix this. She's the maintainer for xhci-hcd. Alan Stern -- Best regards Tianyu Lan --Please consider the environment before printing this e-mail. -- Best regards Tianyu Lan -- Best regards Tianyu Lan -- 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: Not enough resource for old configuration after USB bus reset
On Fri, Feb 01, 2013 at 02:09:24PM +0800, 洪崇耕 wrote:
Hi,
According to xHCI spec Rev1 page 125, Endpoint context state diagram.
When reset device, the endpoint state transit to disabled state.
Right. And the endpoint resources are supposed to be dropped by the
Reset Device command. Section 4.6.11 says the host should Free any
bandwidth allocated to the periodic endpoints and Free any internal
resources associated with the endpoint.
After the device is reset, the USB core re-instates the configuration,
with alternate setting 0 for all interfaces. The xHCI driver will issue
a Configure Endpoint command with the add flag set for those endpoints.
According to section 4.6.6, if that command is successful, the host
should set the endpoint output context state to running. Is your
host setting the endpoint context state to running?
Then the USB core attempts to re-instate any interfaces that weren't
originally at alt setting zero. That means dropping and adding
endpoints. The endpoint context state should be running at that point,
so the call to drop_endpoints should succeed. If that's true,
we shouldn't ever add an endpoint context twice.
(However, note that your test code doesn't change any alternate
interface settings before resetting the device. That means you're not
running into the case in the third paragraph. Unless you're resetting a
device with a driver bound to it, and the driver is re-installing a
different alternate interface setting.)
Are you sure the TI host and your host isn't neglecting to drop endpoint
resources when the Reset Device command is handled?
Sarah Sharp
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Thursday, January 31, 2013 12:22 AM
To: 洪崇耕
Cc: linux-usb@vger.kernel.org
Subject: RE: Not enough resource for old configuration after USB bus reset
On Wed, 30 Jan 2013, [big5] x R wrote:
Hi all,
We try to reproduce the problem on general desktop with ubuntu 12.04.1 and
12.10, and got some information below:
1. If we use xHci with Ti TUSB7340 chip, do bus reset or plug/unplug 1000+
times, the host fail to configure the device.
If we use xHci with Fresco chip, it operats without error.
2. If the usb device contains only Control/Bulk type endpoints, it's all
right.
If it contains interrupt/isoc (periodic) endpoint, it will fail with
bandwidth error.
I check the source and find that the bandwidth_error is the
TRB_completion_code of configure_endpoint command.
In addition, I try to study the usb_reset_and_verify_device and want to
consult the following question.
When reseting a device, hcd will invoke usb_hcd_alloc_bandwidth, this
function will drop the endpoints and add the endpoints.
When executing drop_endpoint, the function shows error message xHCI called
with disabled ep.
And I confirm that ep_state of end point context is in disabled state this
time.
Why is the endpoint already disabled? It shouldn't be.
Then usb_hcd_alloc_bandwidth invokes add_endpoint.
Last, sending a configure endpoint command to complete the change.
The xHCI spec says configure endpoint should ignore disabled endpoints
drop flag and do nothing.
So the source is correct according to spec.
But the overall behavior is adding the endpoint without dropping the old
endpoint.
Is this what we want? Don't we need dropping endpoints to release the
bandwidth and/or resource before the endpoints goes to disabled state
without freeing bandwidth?
Yes. It would work okay if the endpoint wasn't already disabled. Can you
figure out how the endpoint became disabled in the first place?
Alan Stern
N?妓緶r??y???匒淅炮v傂?)瑎{.n?+?極?{捱?傂n?r←屹??螐?刻俾ｐ 埂??嶭?(剝???摃j???m翯z嫡??僠fㄑ搬??坍?m
--
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: Not enough resource for old configuration after USB bus reset
On Wed, Feb 20, 2013 at 10:14:46AM -0800, Sarah Sharp wrote: Are you sure the TI host and your host isn't neglecting to drop endpoint resources when the Reset Device command is handled? I double checked your test file on the latest Intel xHCI host, and it's up to over 4,000 successful resets of a USB mouse with a periodic IN endpoint. I tried it with a USB ethernet dongle, but after about a hundred resets, the device returned different device descriptors. The USB core treated it as a new device and assigned it a different address, which caused the script to fail since the /dev/bus/usb files went away. Was there a different device you would like me to test with? Basically, I think this is a host-specific bug. We can certainly work around it in the xHCI driver with a quirk for all hosts that have this resource tracking problem. We would issue a Configure Endpoint command to drop all endpoints before the Reset Device command. However, I would really suggest you fix your host controller. Can you send me the output of `sudo lspci -vvv` and `sudo lspci -vvv -n` when the TI host is attached to your system? I'll send you a patch with the workaround fix to test. We can also add a quirk for your host, if your host controller is already available with this issue, and you're planning on having the mainline kernel support your host controller. Sarah Sharp -- 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: Not enough resource for old configuration after USB bus reset
On Wed, Feb 20, 2013 at 03:21:19PM -0500, Alan Stern wrote: On Wed, 20 Feb 2013, Sarah Sharp wrote: Basically, I think this is a host-specific bug. We can certainly work around it in the xHCI driver with a quirk for all hosts that have this resource tracking problem. We would issue a Configure Endpoint command to drop all endpoints before the Reset Device command. However, I would really suggest you fix your host controller. It might not hurt to do this anyway, as a sort of defensive programming. After all, device resets are not a hot path. I'll agree that it's not a hot path. I'm just concerned that if we add too much defensive behavior, we'll end up triggering different host controller quirks. So I would rather modify behavior for particular host controllers. I reserve the right to change my mind about that, of course. :) I might agree with you when I start running out of bits in xhci-quirks. Sarah Sharp -- 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: Not enough resource for old configuration after USB bus reset
Hi all, I checkout the usb-next branch (on 2/18) and following the https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build the kernel. After reboot, the new kernel version is Linux dev 3.8.0-rc5-usbnext #1 SMP Mon Feb 18 18:04:02 CST 2013 i686 i686 i386 GNU/Linux. I try the same operation to produce the issue, and it also fails. Thanks, Soar -Original Message- From: Lan Tianyu [mailto:lantianyu1...@gmail.com] Sent: Friday, February 08, 2013 12:57 AM To: Soar Hung Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org Subject: Re: Not enough resource for old configuration after USB bus reset 于 2013/2/7 16:59, Soar Hung 写道: Hi Tianyu, I can produce the issue on the Ubuntu 12.10 (linux 3.5), too. However, could you tell me more detail about what to do or give me some hint for google? Do you mean replacing the usb related source with source from 'usb next', rebuild the kernel, and test again? I think you can git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git and git checkout usb-next. Compile kernel and test it. Best regards, Soar -Original Message- From: Lan Tianyu [mailto:lantianyu1...@gmail.com] Sent: Thursday, February 07, 2013 4:18 PM To: Soar Hung Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org Subject: Re: Not enough resource for old configuration after USB bus reset 2013/2/4 Soar Hung soarh...@realtek.com: Hi Alan, Sarah, Thank you for your kindly help. Can I do something to provide some help? You found the issue on the 3.0.30+ kernel. Can you test it on the usb-next branch of usb tree? Sarah has fixed a lot of bugs since v3.0. Best regards, Soar -Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Friday, February 01, 2013 11:36 PM To: Soar Hung Cc: Sarah Sharp; linux-usb@vger.kernel.org Subject: RE: Not enough resource for old configuration after USB bus reset On Fri, 1 Feb 2013, [big5] x R wrote: Hi, According to xHCI spec Rev1 page 125, Endpoint context state diagram. When reset device, the endpoint state transit to disabled state. Do I make some mistake? I'll try to figure out the endopint state transitions during the reset flow, and update information later. Thanks for the direction. Ah, now I understand the problem. The device reset automatically disables the endpoints, so when usb_reset_and_verify_device calls usb_hcd_alloc_bandwidth, and that routine tries to drop the endpoints, it fails because the endpoints are already disabled. Sarah is going to to have to figure out the right way to fix this. She's the maintainer for xhci-hcd. Alan Stern -- Best regards Tianyu Lan --Please consider the environment before printing this e-mail. -- Best regards Tianyu Lan -- 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: Not enough resource for old configuration after USB bus reset
2013/2/4 Soar Hung soarh...@realtek.com: Hi Alan, Sarah, Thank you for your kindly help. Can I do something to provide some help? You found the issue on the 3.0.30+ kernel. Can you test it on the usb-next branch of usb tree? Sarah has fixed a lot of bugs since v3.0. Best regards, Soar -Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Friday, February 01, 2013 11:36 PM To: Soar Hung Cc: Sarah Sharp; linux-usb@vger.kernel.org Subject: RE: Not enough resource for old configuration after USB bus reset On Fri, 1 Feb 2013, [big5] x R wrote: Hi, According to xHCI spec Rev1 page 125, Endpoint context state diagram. When reset device, the endpoint state transit to disabled state. Do I make some mistake? I'll try to figure out the endopint state transitions during the reset flow, and update information later. Thanks for the direction. Ah, now I understand the problem. The device reset automatically disables the endpoints, so when usb_reset_and_verify_device calls usb_hcd_alloc_bandwidth, and that routine tries to drop the endpoints, it fails because the endpoints are already disabled. Sarah is going to to have to figure out the right way to fix this. She's the maintainer for xhci-hcd. Alan Stern -- Best regards Tianyu Lan -- 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: Not enough resource for old configuration after USB bus reset
Hi Tianyu,
I can produce the issue on the Ubuntu 12.10 (linux 3.5), too.
However, could you tell me more detail about what to do or give me some hint
for google?
Do you mean replacing the usb related source with source from 'usb next',
rebuild the kernel, and test again?
Best regards,
Soar
-Original Message-
From: Lan Tianyu [mailto:lantianyu1...@gmail.com]
Sent: Thursday, February 07, 2013 4:18 PM
To: Soar Hung
Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org
Subject: Re: Not enough resource for old configuration after USB bus reset
2013/2/4 Soar Hung soarh...@realtek.com:
Hi Alan, Sarah,
Thank you for your kindly help.
Can I do something to provide some help?
You found the issue on the 3.0.30+ kernel. Can you test it on the usb-next
branch of usb tree? Sarah has fixed a lot of bugs since v3.0.
Best regards,
Soar
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Friday, February 01, 2013 11:36 PM
To: Soar Hung
Cc: Sarah Sharp; linux-usb@vger.kernel.org
Subject: RE: Not enough resource for old configuration after USB bus
reset
On Fri, 1 Feb 2013, [big5] x R wrote:
Hi,
According to xHCI spec Rev1 page 125, Endpoint context state diagram.
When reset device, the endpoint state transit to disabled state.
Do I make some mistake?
I'll try to figure out the endopint state transitions during the reset flow,
and update information later.
Thanks for the direction.
Ah, now I understand the problem. The device reset automatically disables
the endpoints, so when usb_reset_and_verify_device calls
usb_hcd_alloc_bandwidth, and that routine tries to drop the endpoints, it
fails because the endpoints are already disabled.
Sarah is going to to have to figure out the right way to fix this.
She's the maintainer for xhci-hcd.
Alan Stern
--
Best regards
Tianyu Lan
--Please consider the environment before printing this e-mail.
N�妓緶r��y���匒淅炮カv傂�)瑎{.n�+�極�{捱〇�傂n�r←屹��螐�刻俾ｐ 埂��嶭�(剝���摃j���m翯z嫡��僠fㄑ搬��坍�m�
Re: Not enough resource for old configuration after USB bus reset
于 2013/2/7 16:59, Soar Hung 写道: Hi Tianyu, I can produce the issue on the Ubuntu 12.10 (linux 3.5), too. However, could you tell me more detail about what to do or give me some hint for google? Do you mean replacing the usb related source with source from 'usb next', rebuild the kernel, and test again? I think you can git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git and git checkout usb-next. Compile kernel and test it. Best regards, Soar -Original Message- From: Lan Tianyu [mailto:lantianyu1...@gmail.com] Sent: Thursday, February 07, 2013 4:18 PM To: Soar Hung Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org Subject: Re: Not enough resource for old configuration after USB bus reset 2013/2/4 Soar Hung soarh...@realtek.com: Hi Alan, Sarah, Thank you for your kindly help. Can I do something to provide some help? You found the issue on the 3.0.30+ kernel. Can you test it on the usb-next branch of usb tree? Sarah has fixed a lot of bugs since v3.0. Best regards, Soar -Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Friday, February 01, 2013 11:36 PM To: Soar Hung Cc: Sarah Sharp; linux-usb@vger.kernel.org Subject: RE: Not enough resource for old configuration after USB bus reset On Fri, 1 Feb 2013, [big5] x R wrote: Hi, According to xHCI spec Rev1 page 125, Endpoint context state diagram. When reset device, the endpoint state transit to disabled state. Do I make some mistake? I'll try to figure out the endopint state transitions during the reset flow, and update information later. Thanks for the direction. Ah, now I understand the problem. The device reset automatically disables the endpoints, so when usb_reset_and_verify_device calls usb_hcd_alloc_bandwidth, and that routine tries to drop the endpoints, it fails because the endpoints are already disabled. Sarah is going to to have to figure out the right way to fix this. She's the maintainer for xhci-hcd. Alan Stern -- Best regards Tianyu Lan --Please consider the environment before printing this e-mail. -- Best regards Tianyu Lan -- 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: Not enough resource for old configuration after USB bus reset
On Mon, 4 Feb 2013, Soar Hung wrote: Hi Alan, Sarah, Thank you for your kindly help. Can I do something to provide some help? For now, I think you may just have to wait until Sarah gets back from LinuxConf Australia. 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: Not enough resource for old configuration after USB bus reset
On Fri, 1 Feb 2013, [big5] �x�R�� wrote: Hi, According to xHCI spec Rev1 page 125, Endpoint context state diagram. When reset device, the endpoint state transit to disabled state. Do I make some mistake? I'll try to figure out the endopint state transitions during the reset flow, and update information later. Thanks for the direction. Ah, now I understand the problem. The device reset automatically disables the endpoints, so when usb_reset_and_verify_device calls usb_hcd_alloc_bandwidth, and that routine tries to drop the endpoints, it fails because the endpoints are already disabled. Sarah is going to to have to figure out the right way to fix this. She's the maintainer for xhci-hcd. 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: Not enough resource for old configuration after USB bus reset
Hi,
According to xHCI spec Rev1 page 125, Endpoint context state diagram.
When reset device, the endpoint state transit to disabled state.
Do I make some mistake?
I'll try to figure out the endopint state transitions during the reset flow,
and update information later.
Thanks for the direction.
Soar
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Thursday, January 31, 2013 12:22 AM
To: 洪崇耕
Cc: linux-usb@vger.kernel.org
Subject: RE: Not enough resource for old configuration after USB bus reset
On Wed, 30 Jan 2013, [big5] x R wrote:
Hi all,
We try to reproduce the problem on general desktop with ubuntu 12.04.1 and
12.10, and got some information below:
1. If we use xHci with Ti TUSB7340 chip, do bus reset or plug/unplug 1000+
times, the host fail to configure the device.
If we use xHci with Fresco chip, it operats without error.
2. If the usb device contains only Control/Bulk type endpoints, it's all
right.
If it contains interrupt/isoc (periodic) endpoint, it will fail with
bandwidth error.
I check the source and find that the bandwidth_error is the
TRB_completion_code of configure_endpoint command.
In addition, I try to study the usb_reset_and_verify_device and want to
consult the following question.
When reseting a device, hcd will invoke usb_hcd_alloc_bandwidth, this
function will drop the endpoints and add the endpoints.
When executing drop_endpoint, the function shows error message xHCI called
with disabled ep.
And I confirm that ep_state of end point context is in disabled state this
time.
Why is the endpoint already disabled? It shouldn't be.
Then usb_hcd_alloc_bandwidth invokes add_endpoint.
Last, sending a configure endpoint command to complete the change.
The xHCI spec says configure endpoint should ignore disabled endpoints drop
flag and do nothing.
So the source is correct according to spec.
But the overall behavior is adding the endpoint without dropping the old
endpoint.
Is this what we want? Don't we need dropping endpoints to release the
bandwidth and/or resource before the endpoints goes to disabled state without
freeing bandwidth?
Yes. It would work okay if the endpoint wasn't already disabled. Can you
figure out how the endpoint became disabled in the first place?
Alan Stern
N�妓緶r��y���匒淅炮カv傂�)瑎{.n�+�極�{捱〇�傂n�r←屹��螐�刻俾ｐ 埂��嶭�(剝���摃j���m翯z嫡��僠fㄑ搬��坍�m�
RE: Not enough resource for old configuration after USB bus reset
Hi all,
We try to reproduce the problem on general desktop with ubuntu 12.04.1 and
12.10, and got some information below:
1. If we use xHci with Ti TUSB7340 chip, do bus reset or plug/unplug 1000+
times, the host fail to configure the device.
If we use xHci with Fresco chip, it operats without error.
2. If the usb device contains only Control/Bulk type endpoints, it's all right.
If it contains interrupt/isoc (periodic) endpoint, it will fail with bandwidth
error.
I check the source and find that the bandwidth_error is the TRB_completion_code
of configure_endpoint command.
In addition, I try to study the usb_reset_and_verify_device and want to consult
the following question.
When reseting a device, hcd will invoke usb_hcd_alloc_bandwidth,
this function will drop the endpoints and add the endpoints.
When executing drop_endpoint, the function shows error message xHCI called with
disabled ep.
And I confirm that ep_state of end point context is in disabled state this time.
Then usb_hcd_alloc_bandwidth invokes add_endpoint.
Last, sending a configure endpoint command to complete the change.
The xHCI spec says configure endpoint should ignore disabled endpoints drop
flag and do nothing.
So the source is correct according to spec.
But the overall behavior is adding the endpoint without dropping the old
endpoint.
Is this what we want? Don't we need dropping endpoints to release the bandwidth
and/or resource
before the endpoints goes to disabled state without freeing bandwidth?
To produce the problem, following these steps
1. prepare a linux and TI host
2. compile the source modify from
http://marc.info/?l=linux-usbm=121459435621262q=p3
/* usbreset -- send a USB port reset to a USB device */
#include stdio.h
#include unistd.h
#include fcntl.h
#include errno.h
#include sys/ioctl.h
#include linux/usbdevice_fs.h
int main(int argc, char **argv)
{
const char *filename;
int fd;
int rc;
int reset_cnt = 0;
if (argc != 2) {
fprintf(stderr, Usage: usbreset device-filename\n);
return 1;
}
filename = argv[1];
fd = open(filename, O_WRONLY);
if (fd 0) {
perror(Error opening output file);
return 1;
}
while(1)
{
printf(%d -th Resetting USB device %s\n, reset_cnt++,
filename);
rc = ioctl(fd, USBDEVFS_RESET, 0);
if (rc 0) {
perror(Error in ioctl);
return 1;
}
printf(Reset successful\n);
}
close(fd);
return 0;
}
$ gcc usbreset.c -o usbreset
$ sudo ./usbreset /dev/bus/usb/BUS NUMBER/DEVICE NUMBER
Best regards,
Soar
-Original Message-
From: Peter Stuge [mailto:pe...@stuge.se]
Sent: Monday, January 21, 2013 12:27 PM
To: 洪崇耕
Cc: linux-usb@vger.kernel.org
Subject: Re: Not enough resource for old configuration after USB bus reset
Soar Hung wrote:
We ported the Linux and related drivers to our embedded system(a
customized board), and using TUSB7340 as our host controller.
We also write a usb interface driver for the tested device, the
enumeration and bulk in/out transfers work fine.
But we encounter problem
..
Does anybody has the same experience or some guide and would kindly
share with us?
It's basically impossible for anyone to help you in any way unless
you either share the complete and full kernel source code that you are using,
or reproduce the error with a combination of hardware and software that others
who will do the debugging also have access to.
//Peter
--Please consider the environment before printing this e-mail.
Not enough resource for old configuration after USB bus reset
Hi everybody,
We ported the Linux and related drivers to our embedded
system(a customized board), and using TUSB7340 as our
host controller.
We also write a usb interface driver for the tested device,
the enumeration and bulk in/out transfers work fine.
But we encounter problem when we keep doing the bus reset to
the same device, the HC will fail to complete the recovering
old configuration after 128th usb bus reset and shows the
message not enough bandwidth.
When we repeat the same operation to another similar device,
HC fails at 1020th usb bus reset.
In addition to the bus reset, if we plug and unplug the device
repeatedly, the host also fails to complete the set configuration.
Below are logs:
(ep1 and ep2 are bulk endpoint,
the kernel version is 3.0.30+,
during the test, only one device is attached.)
1 Bus reset
usb 1-2: reset high speed USB device number 2 using xhci_hcd
xhci_hcd :01:00.0: WARN: short transfer on control ep
xhci_hcd :01:00.0: xHCI xhci_drop_endpoint called with disabled ep 81fb90e0
xhci_hcd :01:00.0: xHCI xhci_drop_endpoint called with disabled ep 81fb910c
xhci_hcd :01:00.0: xHCI xhci_drop_endpoint called with disabled ep 81fb9138
usb 1-2: ep 0x81 - rounding interval to 32768 microframes, ep desc says 0 micros
usb 1-2: ep 0x2 - rounding interval to 32768 microframes, ep desc says 0 microfs
[FT] skel_post_reset
[FT]usb_reset_device, result 0
...
2~127 are the same with 1
...
[FT] skel_pre_reset
128 Bus reset
usb 1-2: reset high speed USB device number 2 using xhci_hcd
xhci_hcd :01:00.0: WARN: short transfer on control ep
xhci_hcd :01:00.0: xHCI xhci_drop_endpoint called with disabled ep 81fb90e0
xhci_hcd :01:00.0: xHCI xhci_drop_endpoint called with disabled ep 81fb910c
xhci_hcd :01:00.0: xHCI xhci_drop_endpoint called with disabled ep 81fb9138
usb 1-2: ep 0x81 - rounding interval to 32768 microframes, ep desc says 0 micros
usb 1-2: ep 0x2 - rounding interval to 32768 microframes, ep desc says 0 microfs
usb 1-2: Not enough bandwidth for new device state.
usb 1-2: Busted HC? Not enough HCD resources for old configuration.
[FT] skel_post_reset
[FT]usb_reset_device, result -19
usb 1-2: USB disconnect, device number 2
[FT] skel_disconnect
skeleton 1-2:1.0: [FT] USB Skeleton #192 now disconnected
xhci_hcd :01:00.0: xHCI xhci_drop_endpoint called with disabled ep 81fb90e0
xhci_hcd :01:00.0: xHCI xhci_drop_endpoint called with disabled ep 81fb910c
xhci_hcd :01:00.0: xHCI xhci_drop_endpoint called with disabled ep 81fb9138
[USB_CORE] generic_disconnect
usb 1-2: new high speed USB device number 3 using xhci_hcd
xhci_hcd :01:00.0: WARN: short transfer on control ep
xhci_hcd :01:00.0: WARN: short transfer on control ep
xhci_hcd :01:00.0: WARN: short transfer on control ep
xhci_hcd :01:00.0: WARN: short transfer on control ep
[USB_CORE] generic_probe, force select config #1
usb 1-2: ep 0x81 - rounding interval to 32768 microframes, ep desc says 0 micros
usb 1-2: ep 0x2 - rounding interval to 32768 microframes, ep desc says 0 microfs
usb 1-2: Not enough bandwidth for new device state.
usb 1-2: can't set config #1, error -28
Below are part of sources (modify from linux kernel usb skeleton.c)
We register a char device to system, and wrtie a user-space application use
ioctl to call the _usbft_bus_reset().
static int skel_pre_reset(struct usb_interface *intf)
{
struct usb_skel *dev = usb_get_intfdata(intf);
printk(KERN_INFO [FT] skel_pre_reset\n);
mutex_lock(dev-io_mutex);
return 0;
}
static int skel_post_reset(struct usb_interface *intf)
{
struct usb_skel *dev = usb_get_intfdata(intf);
printk(KERN_INFO [FT] skel_post_reset\n);
mutex_unlock(dev-io_mutex);
return 0;
}
static long _usbft_bus_reset(struct file *filp)
{
struct usb_skel *dev;
long result = 0;
printk(KERN_DEBUG [FT] Bus Reset\n);
dev = filp-private_data;
result = usb_lock_device_for_reset(dev-udev, NULL);
printk(KERN_DEBUG [FT]usb_lock_device_for_reset, result %ld\n,
result);
if(result != 0)
{
return result;
}
result = usb_reset_device(dev-udev);
printk(KERN_INFO [FT]usb_reset_device, result %ld\n, result);
// release device lock
printk(KERN_DEBUG [FT]device_unlock\n);
device_unlock((dev-udev-dev));
return result;
}
Does anybody has the same experience or some guide and
would kindly share with us?
Thanks for your reading and helping.
--
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: Not enough resource for old configuration after USB bus reset
Soar Hung wrote: We ported the Linux and related drivers to our embedded system(a customized board), and using TUSB7340 as our host controller. We also write a usb interface driver for the tested device, the enumeration and bulk in/out transfers work fine. But we encounter problem .. Does anybody has the same experience or some guide and would kindly share with us? It's basically impossible for anyone to help you in any way unless you either share the complete and full kernel source code that you are using, or reproduce the error with a combination of hardware and software that others who will do the debugging also have access to. //Peter -- 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
