On 8 March 2012 15:23, Xu, Andiry <[email protected]> wrote:
> I don't know why my email is mangled so I remove all the receivers.
> Please reply the mail adding Larry, Sarah and USB list.
>
>> -----Original Message-----
>> From: Andiry Xu [mailto:[email protected]]
>> Sent: Thursday, March 08, 2012 3:12 PM
>> To: jerome huang
>> Cc: Larry Finger; [email protected]; Sarah Sharp; linux-
>> [email protected]
>> Subject: Re: rt8192cu on USB3
>>
>> On 03/08/2012 02:35 PM, jerome huang wrote:
>> >
>> > I also tried to slow down between each write during firmware upload,
>> > and enlarge the ring size in xhci_endpoint_init(),
>> > but it seems that the trbs in the ring are not processed and
>> > the incoming trb is always queued till ring full.
>> >
>>
>
> This is interesting thing. How do you find out the trbs in the ring are
> not processed? Do you see handle_tx_event() triggers and urbs are
> givenback in the irq handler?
>
> There is a new version of ring expansion patchset:
>
> http://www.spinics.net/lists/linux-usb/msg59391.html
>
> But I'm not sure if it helps in your case. if the trbs are continuously
> queued but without completion, ring expansion will loop until memory is
> depleted.
>
> Thanks,
> Andiry
>
>
Hi all,
I tried to print more information for firmware upload,
and handle_tx_event is triggered and urbs are givenback.
This time I found the first "no room on ep ring"
is before "Loading firmware file" (line 176)
and there is no error during firmware upload,
after firmware upload completion,
"no room on ep ring" appears continuously (line 264).
So the problem is not in firmware upload,
but in the other place after firmware upload?
Please let me know if you need other debug messages.
BR,
Jerome
On 9 March 2012 23:04, Larry Finger <[email protected]> wrote:
> On 03/09/2012 01:39 AM, jerome huang wrote:
>>
>>
>> Are other patches recommend besides b0302a?
>
>
> That is the main one. Others that you might consider, but they probably will
> not make any difference:
>
> 3eda95d rtlwifi: Remove extra debugging message accidentally left in
>
> 4e3c3b8 rtlwifi: Fix breakage in debug functions when built as a module
> ? ? ? ? ?This fixes a problem caused in commit 481b9606.
>
> ebecdcc rtlwifi: rtl8192c: Prevent sleeping from invalid context in
> rtl8192cu
>
> The patch below is currently under test. It is not likely to make any
> difference with your problem, but it changes USB reads a lot.
>
> Larry
>
> ========================================================================
>
> The current version of rtlwifi for USB operations uses kmalloc to
> acquire a 32-bit buffer for reading. When _usb_read_sync() is called
> with the rcu_lock held, the result is a "sleeping function called
> from invalid context" BUG. This is reported for two cases in
> https://bugzilla.kernel.org/show_bug.cgi?id=42775. The first case
> where the lock originates from within rtlwifi and could be fixed
> by rearranging the locking; however, the second originates from
> within mac80211. The kmalloc() call is removed from _usb_read_sync()
> by creating a ring buffer pointer in the private area and
> allocating the buffer data in the probe routine.
>
> Signed-off-by: Larry Finger <[email protected]>
> Cc: Stable <[email protected]> [This version good for 3.3+ - different
> patch for 3.2 - 2.6.39]
> ---
>
> Index: wireless-testing-new/drivers/net/wireless/rtlwifi/usb.c
> ===================================================================
> --- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/usb.c
> +++ wireless-testing-new/drivers/net/wireless/rtlwifi/usb.c
> @@ -124,46 +124,38 @@ static int _usbctrl_vendorreq_sync_read(
> ? ? ? ?return status;
> ?}
>
> -static u32 _usb_read_sync(struct usb_device *udev, u32 addr, u16 len)
> +static u32 _usb_read_sync(struct rtl_priv *rtlpriv, u32 addr, u16 len)
> ?{
> + ? ? ? struct device *dev = rtlpriv->io.dev;
> + ? ? ? struct usb_device *udev = to_usb_device(dev);
> ? ? ? ?u8 request;
> ? ? ? ?u16 wvalue;
> ? ? ? ?u16 index;
> - ? ? ? u32 *data;
> - ? ? ? u32 ret;
> + ? ? ? __le32 *data = &rtlpriv->usb_data[rtlpriv->usb_data_index];
>
> - ? ? ? data = kmalloc(sizeof(u32), GFP_KERNEL);
> - ? ? ? if (!data)
> - ? ? ? ? ? ? ? return -ENOMEM;
> ? ? ? ?request = REALTEK_USB_VENQT_CMD_REQ;
> ? ? ? ?index = REALTEK_USB_VENQT_CMD_IDX; /* n/a */
>
> ? ? ? ?wvalue = (u16)addr;
> ? ? ? ?_usbctrl_vendorreq_sync_read(udev, request, wvalue, index, data,
> len);
> - ? ? ? ret = le32_to_cpu(*data);
> - ? ? ? kfree(data);
> - ? ? ? return ret;
> + ? ? ? if (++rtlpriv->usb_data_index >= RTL_USB_MAX_RX_COUNT)
> + ? ? ? ? ? ? ? rtlpriv->usb_data_index = 0;
> + ? ? ? return le32_to_cpu(*data);
> ?}
>
> ?static u8 _usb_read8_sync(struct rtl_priv *rtlpriv, u32 addr)
> ?{
> - ? ? ? struct device *dev = rtlpriv->io.dev;
> -
> - ? ? ? return (u8)_usb_read_sync(to_usb_device(dev), addr, 1);
> + ? ? ? return (u8)_usb_read_sync(rtlpriv, addr, 1);
> ?}
>
> ?static u16 _usb_read16_sync(struct rtl_priv *rtlpriv, u32 addr)
> ?{
> - ? ? ? struct device *dev = rtlpriv->io.dev;
> -
> - ? ? ? return (u16)_usb_read_sync(to_usb_device(dev), addr, 2);
> + ? ? ? return (u16)_usb_read_sync(rtlpriv, addr, 2);
> ?}
>
> ?static u32 _usb_read32_sync(struct rtl_priv *rtlpriv, u32 addr)
> ?{
> - ? ? ? struct device *dev = rtlpriv->io.dev;
> -
> - ? ? ? return _usb_read_sync(to_usb_device(dev), addr, 4);
> + ? ? ? return _usb_read_sync(rtlpriv, addr, 4);
> ?}
>
> ?static void _usb_write_async(struct usb_device *udev, u32 addr, u32 val,
> @@ -951,6 +943,13 @@ int __devinit rtl_usb_probe(struct usb_i
> ? ? ? ? ? ? ? ?return -ENOMEM;
> ? ? ? ?}
> ? ? ? ?rtlpriv = hw->priv;
> + ? ? ? rtlpriv->usb_data = kzalloc(RTL_USB_MAX_RX_COUNT * sizeof(u32),
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? GFP_KERNEL);
> + ? ? ? if (!rtlpriv->usb_data) {
> + ? ? ? ? ? ? ? RT_ASSERT(false, "USB data buffer allocation failed\n");
> + ? ? ? ? ? ? ? return -ENOMEM;
> + ? ? ? }
> + ? ? ? rtlpriv->usb_data_index = 0;
> ? ? ? ?init_completion(&rtlpriv->firmware_loading_complete);
> ? ? ? ?SET_IEEE80211_DEV(hw, &intf->dev);
> ? ? ? ?udev = interface_to_usbdev(intf);
> @@ -1019,6 +1018,7 @@ void rtl_usb_disconnect(struct usb_inter
> ? ? ? ?/* rtl_deinit_rfkill(hw); */
> ? ? ? ?rtl_usb_deinit(hw);
> ? ? ? ?rtl_deinit_core(hw);
> + ? ? ? kfree(rtlpriv->usb_data);
> ? ? ? ?rtlpriv->cfg->ops->deinit_sw_leds(hw);
> ? ? ? ?rtlpriv->cfg->ops->deinit_sw_vars(hw);
> ? ? ? ?_rtl_usb_io_handler_release(hw);
> Index: wireless-testing-new/drivers/net/wireless/rtlwifi/wifi.h
> ===================================================================
> --- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/wifi.h
> +++ wireless-testing-new/drivers/net/wireless/rtlwifi/wifi.h
> @@ -67,7 +67,7 @@
> ?#define QOS_QUEUE_NUM ? ? ? ? ? ? ? ? ? ? ? ? ?4
> ?#define RTL_MAC80211_NUM_QUEUE ? ? ? ? ? ? ? ? 5
> ?#define REALTEK_USB_VENQT_MAX_BUF_SIZE ? ? ? ? 254
> -
> +#define RTL_USB_MAX_RX_COUNT ? ? ? ? ? ? ? ? ? 100
> ?#define QBSS_LOAD_SIZE ? ? ? ? ? ? ? ? ? ? ? ? 5
> ?#define MAX_WMMELE_LENGTH ? ? ? ? ? ? ? ? ? ? ?64
>
> @@ -1629,6 +1629,10 @@ struct rtl_priv {
> ? ? ? ? ? interface or hardware */
> ? ? ? ?unsigned long status;
>
> + ? ? ? /* data buffer pointer for USB reads */
> + ? ? ? __le32 *usb_data;
> + ? ? ? int usb_data_index;
> +
> ? ? ? ?/*This must be the last item so
> ? ? ? ? ? that it points to the data allocated
> ? ? ? ? ? beyond ?this structure like:
>
>
>
Thanks for your help, Larry,
will let you know the result.
BR,
Jerome
On 03/23/2012 03:34 PM, Sarah Sharp wrote:
> On Thu, Mar 22, 2012 at 09:24:31PM -0500, Larry Finger wrote:
>> On 03/22/2012 05:31 PM, Sarah Sharp wrote:
>>
>>> Larry, if the driver doesn't cancel an URB that the device doesn't
>>> respond to, then it will just be left on the endpoint ring. If the
>>> driver then tries to queue new transfers to that same endpoint, but the
>>> device keeps NAKing the uncancelled transfer, then the endpoint ring
>>> would fill up with unanswered transfers.
>>>
>>> Perhaps some userspace or kernel portion is forgetting to cancel URBs
>>> before moving onto the next thing? You said you moved to asynchronous
>>> transfers, so maybe the problem lies there?
>>
>> The writes have always been asynchronous and reads are synchronous.
>> The only change was to convert the firmware uploading writes from
>> 32-bits at a time into block writes of 1000+ 32-bit words.
>
> Yeah, that's going to cause the out-of-room warning under xHCI. That
> should be fixed in the 3.4-rc1 kernel though.
>
>> Would xhci be worse that ohci or ehci in terms of the device not
>> responding to URBs? We only see problems with USB3.0 hubs, never
>> with 2.0 or 1.1.
>
> That's because EHCI handles arbitrarily large transfers, and xHCI didn't
> until now.
>
>> I am looking into changing the writes to be synchronous. That should
>> clear up any problems.
>
> Yeah, your problem probably was in the bulk large transfer, not the
> unfinished canceled URBs. I would suggest getting your reporters to
> just try 3.4-rc1 and see if it helps before doing too much work to debug
> this.
Interesting in that I switched to the large bulk transfers AFTER the problems
with xHCI were reported. I guess my attempts to fix the problem only made it worse.
Larry
On 9 March 2012 01:56, Larry Finger <[email protected]> wrote:
> On 03/08/2012 05:26 AM, jerome huang wrote:
>>
>>
>> I found a interesting thing.
>>
>> Here is my original test steps:
>> 1. plugin 8192 => ?at this step, modules will be inserted
>> 2. ifconfig wlan0 up => ?at this step, firmware will be uploaded
>> 3. iwlist wlan0 scanning => ?check if wlan0 works
>>
>> The original problem occurs at last step,
>> there is "always" no ap list result.
>>
>> And I found a way to make it work "always":
>> 1. plugin 8192
>> 2. ifconfig wlan0 up
>> 3. ifconfig wlan0 down
>> 4. ifconfig wlan0 up
>> 5. iwlist wlan0 scanning
>> If I up->down->up sequentially, (without scanning after first up),
>> and then scanning(step 5),
>> it works!
>>
>> Does this mean the firmware is not transfered or written correctly?
>
>
> I did a bit of testing with debug level 4. For kernels 3.2 and older, the
> firmware file is read by the kernel when the driver is loaded using the
> synchronous method. I confirm that it is not loaded into the device until
> the interface is brought up. The upload mechanism is supposed to be waiting
> while the firmware is uploaded, but that may not be happening.
>
> When you did the original 3-step process, was there any delay between steps
> 2 and 3? Does anything change if you wait for 30 sec between steps 2 and 3?
>
> with kernels 3.3 and later, there is a major change in the firmware loading
> in that an asynchronous method is used. The probe routine run when the
> driver is loaded places a firmware read request, but does not wait. The
> interface startup is delayed until the callback routine is entered. This
> change will not affect when the firmware is loaded into the device.
>
> Larry
It still got no any result if I wait for 30 sec (or longer) between
(original) step 2 and 3.
I double confirmed that it always does not work for steps: plugin ->
up -> scanning
and always works for steps: plugin -> up -> down -> up -> scanning.
And sometimes it works for next down->up->scanning, sometimes it doesn't.
Is the change of firmware loading in kernel 3.3 made by rtlwifi only,
or ring expansion in xhci is also necessary?
BR,
Jerome
>
>
> The only changes are in the rtlwifi drivers. I don't have a USB 3 device,
> thus I have no idea what might work there. I wrote something incorrect
> earlier. The new code is not in mainline 3.3, but it is in the
> wireless-testing git tree. If you want to try this, and don't want to get
> the whole tree, the new code is in the bleeding-edge compat-wireless
> package. Otherwise, I could send you the patches.
>
> Larry
>
>
Are other patches recommend besides b0302a?
Jerome
On 03/08/2012 05:26 AM, jerome huang wrote:
>
> I found a interesting thing.
>
> Here is my original test steps:
> 1. plugin 8192 => at this step, modules will be inserted
> 2. ifconfig wlan0 up => at this step, firmware will be uploaded
> 3. iwlist wlan0 scanning => check if wlan0 works
>
> The original problem occurs at last step,
> there is "always" no ap list result.
>
> And I found a way to make it work "always":
> 1. plugin 8192
> 2. ifconfig wlan0 up
> 3. ifconfig wlan0 down
> 4. ifconfig wlan0 up
> 5. iwlist wlan0 scanning
> If I up->down->up sequentially, (without scanning after first up),
> and then scanning(step 5),
> it works!
>
> Does this mean the firmware is not transfered or written correctly?
I did a bit of testing with debug level 4. For kernels 3.2 and older, the
firmware file is read by the kernel when the driver is loaded using the
synchronous method. I confirm that it is not loaded into the device until the
interface is brought up. The upload mechanism is supposed to be waiting while
the firmware is uploaded, but that may not be happening.
When you did the original 3-step process, was there any delay between steps 2
and 3? Does anything change if you wait for 30 sec between steps 2 and 3?
with kernels 3.3 and later, there is a major change in the firmware loading in
that an asynchronous method is used. The probe routine run when the driver is
loaded places a firmware read request, but does not wait. The interface startup
is delayed until the callback routine is entered. This change will not affect
when the firmware is loaded into the device.
Larry
On 03/23/2012 09:16 PM, Richard Farina wrote:
> Given that I can replicate this issue using several different drivers,
> should I test using 3.4_rc1 kernel to see if the usb is fixed or using
> compat-wireless based on 3.4_rc1 to see if the drivers are fixed? Or both?
You should test 3.4-rc1 first. According to what Sarah wrote, that should fix
many of the problems. If rtl8192cu still has the problem then, I have a
potential fix. At the moment, there is nothing in compat-wireless to help this
problem.
Larry
On 03/23/12 16:34, Sarah Sharp wrote:
> On Thu, Mar 22, 2012 at 09:24:31PM -0500, Larry Finger wrote:
>> On 03/22/2012 05:31 PM, Sarah Sharp wrote:
>>
>>> Larry, if the driver doesn't cancel an URB that the device doesn't
>>> respond to, then it will just be left on the endpoint ring. If the
>>> driver then tries to queue new transfers to that same endpoint, but the
>>> device keeps NAKing the uncancelled transfer, then the endpoint ring
>>> would fill up with unanswered transfers.
>>>
>>> Perhaps some userspace or kernel portion is forgetting to cancel URBs
>>> before moving onto the next thing? You said you moved to asynchronous
>>> transfers, so maybe the problem lies there?
>> The writes have always been asynchronous and reads are synchronous.
>> The only change was to convert the firmware uploading writes from
>> 32-bits at a time into block writes of 1000+ 32-bit words.
> Yeah, that's going to cause the out-of-room warning under xHCI. That
> should be fixed in the 3.4-rc1 kernel though.
Given that I can replicate this issue using several different drivers,
should I test using 3.4_rc1 kernel to see if the usb is fixed or using
compat-wireless based on 3.4_rc1 to see if the drivers are fixed? Or both?
Thanks,
Rick
>
>> Would xhci be worse that ohci or ehci in terms of the device not
>> responding to URBs? We only see problems with USB3.0 hubs, never
>> with 2.0 or 1.1.
> That's because EHCI handles arbitrarily large transfers, and xHCI didn't
> until now.
>
>> I am looking into changing the writes to be synchronous. That should
>> clear up any problems.
> Yeah, your problem probably was in the bulk large transfer, not the
> unfinished canceled URBs. I would suggest getting your reporters to
> just try 3.4-rc1 and see if it helps before doing too much work to debug
> this.
>
> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On 8 March 2012 18:32, jerome huang <[email protected]> wrote:
> On 8 March 2012 15:23, Xu, Andiry <[email protected]> wrote:
>> I don't know why my email is mangled so I remove all the receivers.
>> Please reply the mail adding Larry, Sarah and USB list.
>>
>>> -----Original Message-----
>>> From: Andiry Xu [mailto:[email protected]]
>>> Sent: Thursday, March 08, 2012 3:12 PM
>>> To: jerome huang
>>> Cc: Larry Finger; [email protected]; Sarah Sharp; linux-
>>> [email protected]
>>> Subject: Re: rt8192cu on USB3
>>>
>>> On 03/08/2012 02:35 PM, jerome huang wrote:
>>> >
>>> > I also tried to slow down between each write during firmware upload,
>>> > and enlarge the ring size in xhci_endpoint_init(),
>>> > but it seems that the trbs in the ring are not processed and
>>> > the incoming trb is always queued till ring full.
>>> >
>>>
>>
>> This is interesting thing. How do you find out the trbs in the ring are
>> not processed? Do you see handle_tx_event() triggers and urbs are
>> givenback in the irq handler?
>>
>> There is a new version of ring expansion patchset:
>>
>> http://www.spinics.net/lists/linux-usb/msg59391.html
>>
>> But I'm not sure if it helps in your case. if the trbs are continuously
>> queued but without completion, ring expansion will loop until memory is
>> depleted.
>>
>> Thanks,
>> Andiry
>>
>>
>
> Hi all,
> I tried to print more information for firmware upload,
> and handle_tx_event is triggered and urbs are givenback.
>
> This time I found the first "no room on ep ring"
> is before "Loading firmware file" (line 176)
> and there is no error during firmware upload,
> after firmware upload completion,
> "no room on ep ring" appears continuously (line 264).
>
> So the problem is not in firmware upload,
> but in the other place after firmware upload?
>
> Please let me know if you need other debug messages.
>
> BR,
> Jerome
Hi all,
I found a interesting thing.
Here is my original test steps:
1. plugin 8192 => at this step, modules will be inserted
2. ifconfig wlan0 up => at this step, firmware will be uploaded
3. iwlist wlan0 scanning => check if wlan0 works
The original problem occurs at last step,
there is "always" no ap list result.
And I found a way to make it work "always":
1. plugin 8192
2. ifconfig wlan0 up
3. ifconfig wlan0 down
4. ifconfig wlan0 up
5. iwlist wlan0 scanning
If I up->down->up sequentially, (without scanning after first up),
and then scanning(step 5),
it works!
Does this mean the firmware is not transfered or written correctly?
BR,
Jerome
On 03/22/2012 05:31 PM, Sarah Sharp wrote:
> Larry, if the driver doesn't cancel an URB that the device doesn't
> respond to, then it will just be left on the endpoint ring. If the
> driver then tries to queue new transfers to that same endpoint, but the
> device keeps NAKing the uncancelled transfer, then the endpoint ring
> would fill up with unanswered transfers.
>
> Perhaps some userspace or kernel portion is forgetting to cancel URBs
> before moving onto the next thing? You said you moved to asynchronous
> transfers, so maybe the problem lies there?
The writes have always been asynchronous and reads are synchronous. The only
change was to convert the firmware uploading writes from 32-bits at a time into
block writes of 1000+ 32-bit words.
Would xhci be worse that ohci or ehci in terms of the device not responding to
URBs? We only see problems with USB3.0 hubs, never with 2.0 or 1.1.
I am looking into changing the writes to be synchronous. That should clear up
any problems.
Larry
On Thu, Mar 22, 2012 at 09:24:31PM -0500, Larry Finger wrote:
> On 03/22/2012 05:31 PM, Sarah Sharp wrote:
>
> >Larry, if the driver doesn't cancel an URB that the device doesn't
> >respond to, then it will just be left on the endpoint ring. If the
> >driver then tries to queue new transfers to that same endpoint, but the
> >device keeps NAKing the uncancelled transfer, then the endpoint ring
> >would fill up with unanswered transfers.
> >
> >Perhaps some userspace or kernel portion is forgetting to cancel URBs
> >before moving onto the next thing? You said you moved to asynchronous
> >transfers, so maybe the problem lies there?
>
> The writes have always been asynchronous and reads are synchronous.
> The only change was to convert the firmware uploading writes from
> 32-bits at a time into block writes of 1000+ 32-bit words.
Yeah, that's going to cause the out-of-room warning under xHCI. That
should be fixed in the 3.4-rc1 kernel though.
> Would xhci be worse that ohci or ehci in terms of the device not
> responding to URBs? We only see problems with USB3.0 hubs, never
> with 2.0 or 1.1.
That's because EHCI handles arbitrarily large transfers, and xHCI didn't
until now.
> I am looking into changing the writes to be synchronous. That should
> clear up any problems.
Yeah, your problem probably was in the bulk large transfer, not the
unfinished canceled URBs. I would suggest getting your reporters to
just try 3.4-rc1 and see if it helps before doing too much work to debug
this.
Sarah Sharp
On 03/08/2012 09:28 PM, jerome huang wrote:
>
> It still got no any result if I wait for 30 sec (or longer) between
> (original) step 2 and 3.
> I double confirmed that it always does not work for steps: plugin ->
> up -> scanning
> and always works for steps: plugin -> up -> down -> up -> scanning.
>
> And sometimes it works for next down->up->scanning, sometimes it doesn't.
>
> Is the change of firmware loading in kernel 3.3 made by rtlwifi only,
> or ring expansion in xhci is also necessary?
The only changes are in the rtlwifi drivers. I don't have a USB 3 device, thus I
have no idea what might work there. I wrote something incorrect earlier. The new
code is not in mainline 3.3, but it is in the wireless-testing git tree. If you
want to try this, and don't want to get the whole tree, the new code is in the
bleeding-edge compat-wireless package. Otherwise, I could send you the patches.
Larry
Larry
On Thu, Mar 08, 2012 at 09:59:07PM -0600, Larry Finger wrote:
> On 03/08/2012 09:28 PM, jerome huang wrote:
> >
> >It still got no any result if I wait for 30 sec (or longer) between
> >(original) step 2 and 3.
> >I double confirmed that it always does not work for steps: plugin ->
> >up -> scanning
> >and always works for steps: plugin -> up -> down -> up -> scanning.
> >
> >And sometimes it works for next down->up->scanning, sometimes it doesn't.
> >
> >Is the change of firmware loading in kernel 3.3 made by rtlwifi only,
> >or ring expansion in xhci is also necessary?
>
> The only changes are in the rtlwifi drivers. I don't have a USB 3
> device, thus I have no idea what might work there. I wrote something
> incorrect earlier. The new code is not in mainline 3.3, but it is in
> the wireless-testing git tree. If you want to try this, and don't
> want to get the whole tree, the new code is in the bleeding-edge
> compat-wireless package. Otherwise, I could send you the patches.
Larry, if the driver doesn't cancel an URB that the device doesn't
respond to, then it will just be left on the endpoint ring. If the
driver then tries to queue new transfers to that same endpoint, but the
device keeps NAKing the uncancelled transfer, then the endpoint ring
would fill up with unanswered transfers.
Perhaps some userspace or kernel portion is forgetting to cancel URBs
before moving onto the next thing? You said you moved to asynchronous
transfers, so maybe the problem lies there?
Jerome, the xHCI ring expansion patches have been merged for 3.4, so you
can test with Linus' latest tree and see if they help. If the ring
expands indefinitely, then there's probably an issue with the rtlwifi
drivers.
Sarah Sharp
On 03/09/2012 01:39 AM, jerome huang wrote:
>
> Are other patches recommend besides b0302a?
That is the main one. Others that you might consider, but they probably will not
make any difference:
3eda95d rtlwifi: Remove extra debugging message accidentally left in
4e3c3b8 rtlwifi: Fix breakage in debug functions when built as a module
This fixes a problem caused in commit 481b9606.
ebecdcc rtlwifi: rtl8192c: Prevent sleeping from invalid context in rtl8192cu
The patch below is currently under test. It is not likely to make any difference
with your problem, but it changes USB reads a lot.
Larry
========================================================================
The current version of rtlwifi for USB operations uses kmalloc to
acquire a 32-bit buffer for reading. When _usb_read_sync() is called
with the rcu_lock held, the result is a "sleeping function called
from invalid context" BUG. This is reported for two cases in
https://bugzilla.kernel.org/show_bug.cgi?id=42775. The first case
where the lock originates from within rtlwifi and could be fixed
by rearranging the locking; however, the second originates from
within mac80211. The kmalloc() call is removed from _usb_read_sync()
by creating a ring buffer pointer in the private area and
allocating the buffer data in the probe routine.
Signed-off-by: Larry Finger <[email protected]>
Cc: Stable <[email protected]> [This version good for 3.3+ - different
patch for 3.2 - 2.6.39]
---
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/usb.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/usb.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/usb.c
@@ -124,46 +124,38 @@ static int _usbctrl_vendorreq_sync_read(
return status;
}
-static u32 _usb_read_sync(struct usb_device *udev, u32 addr, u16 len)
+static u32 _usb_read_sync(struct rtl_priv *rtlpriv, u32 addr, u16 len)
{
+ struct device *dev = rtlpriv->io.dev;
+ struct usb_device *udev = to_usb_device(dev);
u8 request;
u16 wvalue;
u16 index;
- u32 *data;
- u32 ret;
+ __le32 *data = &rtlpriv->usb_data[rtlpriv->usb_data_index];
- data = kmalloc(sizeof(u32), GFP_KERNEL);
- if (!data)
- return -ENOMEM;
request = REALTEK_USB_VENQT_CMD_REQ;
index = REALTEK_USB_VENQT_CMD_IDX; /* n/a */
wvalue = (u16)addr;
_usbctrl_vendorreq_sync_read(udev, request, wvalue, index, data, len);
- ret = le32_to_cpu(*data);
- kfree(data);
- return ret;
+ if (++rtlpriv->usb_data_index >= RTL_USB_MAX_RX_COUNT)
+ rtlpriv->usb_data_index = 0;
+ return le32_to_cpu(*data);
}
static u8 _usb_read8_sync(struct rtl_priv *rtlpriv, u32 addr)
{
- struct device *dev = rtlpriv->io.dev;
-
- return (u8)_usb_read_sync(to_usb_device(dev), addr, 1);
+ return (u8)_usb_read_sync(rtlpriv, addr, 1);
}
static u16 _usb_read16_sync(struct rtl_priv *rtlpriv, u32 addr)
{
- struct device *dev = rtlpriv->io.dev;
-
- return (u16)_usb_read_sync(to_usb_device(dev), addr, 2);
+ return (u16)_usb_read_sync(rtlpriv, addr, 2);
}
static u32 _usb_read32_sync(struct rtl_priv *rtlpriv, u32 addr)
{
- struct device *dev = rtlpriv->io.dev;
-
- return _usb_read_sync(to_usb_device(dev), addr, 4);
+ return _usb_read_sync(rtlpriv, addr, 4);
}
static void _usb_write_async(struct usb_device *udev, u32 addr, u32 val,
@@ -951,6 +943,13 @@ int __devinit rtl_usb_probe(struct usb_i
return -ENOMEM;
}
rtlpriv = hw->priv;
+ rtlpriv->usb_data = kzalloc(RTL_USB_MAX_RX_COUNT * sizeof(u32),
+ GFP_KERNEL);
+ if (!rtlpriv->usb_data) {
+ RT_ASSERT(false, "USB data buffer allocation failed\n");
+ return -ENOMEM;
+ }
+ rtlpriv->usb_data_index = 0;
init_completion(&rtlpriv->firmware_loading_complete);
SET_IEEE80211_DEV(hw, &intf->dev);
udev = interface_to_usbdev(intf);
@@ -1019,6 +1018,7 @@ void rtl_usb_disconnect(struct usb_inter
/* rtl_deinit_rfkill(hw); */
rtl_usb_deinit(hw);
rtl_deinit_core(hw);
+ kfree(rtlpriv->usb_data);
rtlpriv->cfg->ops->deinit_sw_leds(hw);
rtlpriv->cfg->ops->deinit_sw_vars(hw);
_rtl_usb_io_handler_release(hw);
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/wifi.h
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/wifi.h
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/wifi.h
@@ -67,7 +67,7 @@
#define QOS_QUEUE_NUM 4
#define RTL_MAC80211_NUM_QUEUE 5
#define REALTEK_USB_VENQT_MAX_BUF_SIZE 254
-
+#define RTL_USB_MAX_RX_COUNT 100
#define QBSS_LOAD_SIZE 5
#define MAX_WMMELE_LENGTH 64
@@ -1629,6 +1629,10 @@ struct rtl_priv {
interface or hardware */
unsigned long status;
+ /* data buffer pointer for USB reads */
+ __le32 *usb_data;
+ int usb_data_index;
+
/*This must be the last item so
that it points to the data allocated
beyond this structure like:
Ping. Richard, have you had a chance to see if 3.4-rc1 fixes your
issues with rtl8192cu?
Sarah Sharp
On Fri, Mar 23, 2012 at 11:59:00PM -0500, Larry Finger wrote:
> On 03/23/2012 09:16 PM, Richard Farina wrote:
>
> >Given that I can replicate this issue using several different drivers,
> >should I test using 3.4_rc1 kernel to see if the usb is fixed or using
> >compat-wireless based on 3.4_rc1 to see if the drivers are fixed? Or both?
>
> You should test 3.4-rc1 first. According to what Sarah wrote, that
> should fix many of the problems. If rtl8192cu still has the problem
> then, I have a potential fix. At the moment, there is nothing in
> compat-wireless to help this problem.
>
> Larry