* rt8192cu on USB3 @ 2012-03-08 2:03 jerome huang 2012-03-08 2:16 ` jerome huang 0 siblings, 1 reply; 21+ messages in thread From: jerome huang @ 2012-03-08 2:03 UTC (permalink / raw) To: linux-wireless Hi, I found a problem just like in the older discussion "Question about error from xhci-hcd", there was a xhci error "no room on ep ring" when plugin rtl8192cu on USB3. (it works on USB2) After applying Larry's patch "rtlwifi: rtl8192cu: Change firmware upload to use block writes", I still get the same error "no room on ep ring". But under the same compat-wireless version, rt8712 works on USB3. Does anyone still encounter this problem after applying this patch? or do I miss something/patches? BR, Jerome ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-08 2:03 rt8192cu on USB3 jerome huang @ 2012-03-08 2:16 ` jerome huang 2012-03-08 2:35 ` Larry Finger 0 siblings, 1 reply; 21+ messages in thread From: jerome huang @ 2012-03-08 2:16 UTC (permalink / raw) To: linux-wireless log: [53614.238023] Compat-wireless backport release: compat-wireless-v3.2-1-s [53614.244729] Backport based on linux-stable.git v3.2 [53614.368074] alg: No test for arc4 (arc4-generic) [53614.402781] cfg80211: Calling CRDA to update world regulatory domain [53614.498603] rtl8192cu 3-3:1.0: usb_probe_interface [53614.503552] rtl8192cu 3-3:1.0: usb_probe_interface - got id [53614.509920] rtl8192cu: rtl8192cu: Chip version 0x11 [53615.359336] rtl8192cu: MAC address: 08:10:74:f1:a1:0f [53615.364575] rtl8192cu: Board Type 0 [53615.400583] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1 [53615.408918] usbcore: registered new interface driver rtl8192cu [53652.483311] rtl8192cu: MAC auto ON okay! [53652.887348] rtl8192cu: Tx queue select: 0x05 [53652.921326] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin And I'm sure the function rtl_block_fw_writeN is used for firmware uploading. On 8 March 2012 10:03, jerome huang <jerome.syno@gmail.com> wrote: > Hi, > > I found a problem just like in the older discussion "Question about > error from xhci-hcd", > there was a xhci error "no room on ep ring" when plugin rtl8192cu on USB3. > (it works on USB2) > > After applying Larry's patch "rtlwifi: rtl8192cu: Change firmware > upload to use block writes", > I still get the same error "no room on ep ring". > > But under the same compat-wireless version, > rt8712 works on USB3. > > Does anyone still encounter this problem after applying this patch? > or do I miss something/patches? > > BR, > Jerome ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-08 2:16 ` jerome huang @ 2012-03-08 2:35 ` Larry Finger 2012-03-08 6:35 ` jerome huang 0 siblings, 1 reply; 21+ messages in thread From: Larry Finger @ 2012-03-08 2:35 UTC (permalink / raw) To: jerome huang; +Cc: linux-wireless On 03/07/2012 08:16 PM, jerome huang wrote: > log: > [53614.238023] Compat-wireless backport release: compat-wireless-v3.2-1-s > [53614.244729] Backport based on linux-stable.git v3.2 > [53614.368074] alg: No test for arc4 (arc4-generic) > [53614.402781] cfg80211: Calling CRDA to update world regulatory domain > [53614.498603] rtl8192cu 3-3:1.0: usb_probe_interface > [53614.503552] rtl8192cu 3-3:1.0: usb_probe_interface - got id > [53614.509920] rtl8192cu: rtl8192cu: Chip version 0x11 > [53615.359336] rtl8192cu: MAC address: 08:10:74:f1:a1:0f > [53615.364575] rtl8192cu: Board Type 0 > [53615.400583] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1 > [53615.408918] usbcore: registered new interface driver rtl8192cu > [53652.483311] rtl8192cu: MAC auto ON okay! > [53652.887348] rtl8192cu: Tx queue select: 0x05 > [53652.921326] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin > > And I'm sure the function rtl_block_fw_writeN is used for firmware uploading. > > On 8 March 2012 10:03, jerome huang<jerome.syno@gmail.com> wrote: >> Hi, >> >> I found a problem just like in the older discussion "Question about >> error from xhci-hcd", >> there was a xhci error "no room on ep ring" when plugin rtl8192cu on USB3. >> (it works on USB2) >> >> After applying Larry's patch "rtlwifi: rtl8192cu: Change firmware >> upload to use block writes", >> I still get the same error "no room on ep ring". >> >> But under the same compat-wireless version, >> rt8712 works on USB3. >> >> Does anyone still encounter this problem after applying this patch? >> or do I miss something/patches? This problem is in the USB system, not in the wireless driver. Keep me as a Cc, but send mail to Sarah Sharp <sarah.a.sharp@linux.intel.com> and linux-usb@vger.kernel.org. They will tell you what debugging is needed. The patch was an attempt to minimize the number of writes needed to upload the firmware, but it had no effect; however, it was still a good change. I'm confused about one statement you made. There is no rt8712 driver, but there is one named r8712u; however, it controls a completely different device than rtl8192cu. Do you have both devices? Larry ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-08 2:35 ` Larry Finger @ 2012-03-08 6:35 ` jerome huang 2012-03-08 7:06 ` Andiry Xu 2012-03-08 7:11 ` Andiry Xu 0 siblings, 2 replies; 21+ messages in thread From: jerome huang @ 2012-03-08 6:35 UTC (permalink / raw) To: Larry Finger; +Cc: linux-wireless, Sarah Sharp, linux-usb On 8 March 2012 10:35, Larry Finger <Larry.Finger@lwfinger.net> wrote: > On 03/07/2012 08:16 PM, jerome huang wrote: >> >> log: >> [53614.238023] Compat-wireless backport release: compat-wireless-v3.2-1-s >> [53614.244729] Backport based on linux-stable.git v3.2 >> [53614.368074] alg: No test for arc4 (arc4-generic) >> [53614.402781] cfg80211: Calling CRDA to update world regulatory domain >> [53614.498603] rtl8192cu 3-3:1.0: usb_probe_interface >> [53614.503552] rtl8192cu 3-3:1.0: usb_probe_interface - got id >> [53614.509920] rtl8192cu: rtl8192cu: Chip version 0x11 >> [53615.359336] rtl8192cu: MAC address: 08:10:74:f1:a1:0f >> [53615.364575] rtl8192cu: Board Type 0 >> [53615.400583] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1 >> [53615.408918] usbcore: registered new interface driver rtl8192cu >> [53652.483311] rtl8192cu: MAC auto ON okay! >> [53652.887348] rtl8192cu: Tx queue select: 0x05 >> [53652.921326] rtl8192c_common: Loading firmware file >> rtlwifi/rtl8192cufw.bin >> >> And I'm sure the function rtl_block_fw_writeN is used for firmware >> uploading. >> >> On 8 March 2012 10:03, jerome huang<jerome.syno@gmail.com> wrote: >>> >>> Hi, >>> >>> I found a problem just like in the older discussion "Question about >>> error from xhci-hcd", >>> there was a xhci error "no room on ep ring" when plugin rtl8192cu on >>> USB3. >>> (it works on USB2) >>> >>> After applying Larry's patch "rtlwifi: rtl8192cu: Change firmware >>> upload to use block writes", >>> I still get the same error "no room on ep ring". >>> >>> But under the same compat-wireless version, >>> rt8712 works on USB3. >>> >>> Does anyone still encounter this problem after applying this patch? >>> or do I miss something/patches? > > > This problem is in the USB system, not in the wireless driver. Keep me as a > Cc, but send mail to Sarah Sharp <sarah.a.sharp@linux.intel.com> and > linux-usb@vger.kernel.org. They will tell you what debugging is needed. > > The patch was an attempt to minimize the number of writes needed to upload > the firmware, but it had no effect; however, it was still a good change. > > I'm confused about one statement you made. There is no rt8712 driver, but > there is one named r8712u; however, it controls a completely different > device than rtl8192cu. Do you have both devices? > > Larry Hi Larry, thanks for your help, and sorry for my typo, I have one rtl8192cu and one "r8712u". Just test 8712 to check if xhci works. 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. BR, Jerome ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-08 6:35 ` jerome huang @ 2012-03-08 7:06 ` Andiry Xu 2012-03-08 7:11 ` Andiry Xu 1 sibling, 0 replies; 21+ messages in thread From: Andiry Xu @ 2012-03-08 7:06 UTC (permalink / raw) To: jerome huang; +Cc: Larry Finger, linux-wireless, Sarah Sharp, linux-usb FILE QUARANTINED ---------------- The original contents of this file have been replaced with this message because of its characteristics. File name: "Body of Message" Virus name: "EngineError" ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-08 6:35 ` jerome huang 2012-03-08 7:06 ` Andiry Xu @ 2012-03-08 7:11 ` Andiry Xu [not found] ` <2A76B9D36150BE4293842BC2FE8FF165016A31@SCYBEXDAG04.amd.com> 1 sibling, 1 reply; 21+ messages in thread From: Andiry Xu @ 2012-03-08 7:11 UTC (permalink / raw) To: jerome huang; +Cc: Larry Finger, linux-wireless, Sarah Sharp, linux-usb FILE QUARANTINED ---------------- The original contents of this file have been replaced with this message because of its characteristics. File name: "Body of Message" Virus name: "EngineError" ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <2A76B9D36150BE4293842BC2FE8FF165016A31@SCYBEXDAG04.amd.com>]
* Re: rt8192cu on USB3 [not found] ` <2A76B9D36150BE4293842BC2FE8FF165016A31@SCYBEXDAG04.amd.com> @ 2012-03-08 10:32 ` jerome huang 2012-03-08 11:26 ` jerome huang 0 siblings, 1 reply; 21+ messages in thread From: jerome huang @ 2012-03-08 10:32 UTC (permalink / raw) To: Xu, Andiry; +Cc: Larry Finger, Sarah Sharp, linux-usb, linux-wireless [-- Attachment #1: Type: text/plain, Size: 1745 bytes --] On 8 March 2012 15:23, Xu, Andiry <Andiry.Xu@amd.com> 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:andiry.xu@amd.com] >> Sent: Thursday, March 08, 2012 3:12 PM >> To: jerome huang >> Cc: Larry Finger; linux-wireless@vger.kernel.org; Sarah Sharp; linux- >> usb@vger.kernel.org >> 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: > > 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 [-- Attachment #2: session1.log --] [-- Type: application/octet-stream, Size: 24864 bytes --] [ 83.286967] xhci_hcd 0000:04:00.0: Slot 1 output ctx = 0x3cf9c000 (dma) [ 83.293903] xhci_hcd 0000:04:00.0: Slot 1 input ctx = 0x3cab7000 (dma) [ 83.300762] xhci_hcd 0000:04:00.0: Allocating ring at ffff88003c9f99c0 [ 83.307604] xhci_hcd 0000:04:00.0: Allocating priv segment structure at ffff88003bae6dc0 [ 83.316094] xhci_hcd 0000:04:00.0: // Allocating segment at ffff88003d47c800 (virtual) 0x3d47c800 (DMA) [ 83.325946] xhci_hcd 0000:04:00.0: Linking segment 0x3d47c800 to segment 0x3d47c800 (DMA) [ 83.334510] xhci_hcd 0000:04:00.0: Wrote link toggle flag to segment ffff88003bae6dc0 (virtual), 0x3d47c800 (DMA) [ 83.345262] xhci_hcd 0000:04:00.0: Set slot id 1 dcbaa entry ffff88003cbcc008 to 0x3cf9c000 [ 83.354023] xhci_hcd 0000:04:00.0: set port reset, actual port 2 status = 0x331 [ 83.361767] xhci_hcd 0000:04:00.0: set port reset map, actual port 0 status = 0x2a0 [ 83.369886] xhci_hcd 0000:04:00.0: set port reset, actual port 2 status = 0x331 [ 83.377629] xhci_hcd 0000:04:00.0: set port reset map, actual port 0 status = 0x2a0 [ 83.404313] xhci_hcd 0000:04:00.0: Port Status Change Event for port 3 [ 84.437188] xhci_hcd 0000:04:00.0: clear port reset change, actual port 2 status = 0xe03. status_map = 0x2a0 [ 84.447562] xhci_hcd 0000:04:00.0: clear port reset change, actual port 2 status = 0xe03 [ 84.461448] usb 3-3: new high speed USB device using xhci_hcd and address 0 [ 84.468741] xhci_hcd 0000:04:00.0: Set root hub portnum to 3 [ 84.474674] xhci_hcd 0000:04:00.0: udev->tt = (null) [ 84.479890] xhci_hcd 0000:04:00.0: udev->ttport = 0x0 [ 84.485374] xhci_hcd 0000:04:00.0: Successful Address Device command [ 84.492048] xhci_hcd 0000:04:00.0: Op regs DCBAA ptr = 0x0000003cbcc000 [ 84.498976] xhci_hcd 0000:04:00.0: Slot ID 1 dcbaa entry @ffff88003cbcc008 = 0x0000003cf9c000 [ 84.507924] xhci_hcd 0000:04:00.0: Output Context DMA address = 0x3cf9c000 [ 84.515129] xhci_hcd 0000:04:00.0: Slot ID 1 Input Context: [ 84.520977] xhci_hcd 0000:04:00.0: Slot ID 1 Output Context: [ 84.526903] xhci_hcd 0000:04:00.0: Device address = 2 [ 84.553136] xhci_hcd 0000:04:00.0: WARN: short transfer on control ep [ 84.559878] xhci_hcd 0000:04:00.0: Waiting for status stage event [ 84.571125] xhci_hcd 0000:04:00.0: WARN: short transfer on control ep [ 84.577862] xhci_hcd 0000:04:00.0: Waiting for status stage event [ 84.584492] xhci_hcd 0000:04:00.0: WARN: short transfer on control ep [ 84.591228] xhci_hcd 0000:04:00.0: Waiting for status stage event [ 84.597990] xhci_hcd 0000:04:00.0: WARN: short transfer on control ep [ 84.604735] xhci_hcd 0000:04:00.0: Waiting for status stage event [ 84.611260] usb 3-3: udev 2, busnum 3, minor = 257 [ 84.616282] usb 3-3: New USB device found, idVendor=0bda, idProduct=8178 [ 84.623288] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 84.630755] usb 3-3: Product: 802.11n WLAN Adapter [ 84.635781] usb 3-3: Manufacturer: Realtek [ 84.640083] usb 3-3: SerialNumber: 00e04c000001 [ 84.645152] usb 3-3: usb_probe_device [ 84.649005] usb 3-3: configuration #1 chosen from 1 choice [ 84.654790] xhci_hcd 0000:04:00.0: usb_endpoint_xfer_isoc:0. [ 84.660707] xhci_hcd 0000:04:00.0: Allocating ring at ffff88003eae9e40 [ 84.667592] xhci_hcd 0000:04:00.0: Allocating priv segment structure at ffff88003ba0a2a0 [ 84.676091] xhci_hcd 0000:04:00.0: // Allocating segment at ffff88003b8fc000 (virtual) 0x3b8fc000 (DMA) [ 84.685909] xhci_hcd 0000:04:00.0: Linking segment 0x3b8fc000 to segment 0x3b8fc000 (DMA) [ 84.694474] xhci_hcd 0000:04:00.0: Wrote link toggle flag to segment ffff88003ba0a2a0 (virtual), 0x3b8fc000 (DMA) [ 84.705227] xhci_hcd 0000:04:00.0: add ep 0x81, slot id 1, new drop flags = 0x0, new add flags = 0x8, new slot info = 0x18300000 [ 84.717345] xhci_hcd 0000:04:00.0: usb_endpoint_xfer_isoc:0. [ 84.723277] xhci_hcd 0000:04:00.0: Allocating ring at ffff88003eae99c0 [ 84.730131] xhci_hcd 0000:04:00.0: Allocating priv segment structure at ffff88003ba0a660 [ 84.738699] xhci_hcd 0000:04:00.0: // Allocating segment at ffff88003b8fc400 (virtual) 0x3b8fc400 (DMA) [ 84.748536] xhci_hcd 0000:04:00.0: Linking segment 0x3b8fc400 to segment 0x3b8fc400 (DMA) [ 84.757124] xhci_hcd 0000:04:00.0: Wrote link toggle flag to segment ffff88003ba0a660 (virtual), 0x3b8fc400 (DMA) [ 84.767859] xhci_hcd 0000:04:00.0: add ep 0x2, slot id 1, new drop flags = 0x0, new add flags = 0x18, new slot info = 0x20300000 [ 84.779968] xhci_hcd 0000:04:00.0: usb_endpoint_xfer_isoc:0. [ 84.785919] xhci_hcd 0000:04:00.0: Allocating ring at ffff88003bb35ec0 [ 84.792763] xhci_hcd 0000:04:00.0: Allocating priv segment structure at ffff88003ba0a260 [ 84.801244] xhci_hcd 0000:04:00.0: // Allocating segment at ffff88003b8fc800 (virtual) 0x3b8fc800 (DMA) [ 84.811089] xhci_hcd 0000:04:00.0: Linking segment 0x3b8fc800 to segment 0x3b8fc800 (DMA) [ 84.819661] xhci_hcd 0000:04:00.0: Wrote link toggle flag to segment ffff88003ba0a260 (virtual), 0x3b8fc800 (DMA) [ 84.830430] xhci_hcd 0000:04:00.0: add ep 0x3, slot id 1, new drop flags = 0x0, new add flags = 0x58, new slot info = 0x30300000 [ 84.842549] xhci_hcd 0000:04:00.0: usb_endpoint_xfer_isoc:0. [ 84.848484] xhci_hcd 0000:04:00.0: Allocating ring at ffff88003bb35bc0 [ 84.855345] xhci_hcd 0000:04:00.0: Allocating priv segment structure at ffff88003c41f2c0 [ 84.863835] xhci_hcd 0000:04:00.0: // Allocating segment at ffff88003cdab000 (virtual) 0x3cdab000 (DMA) [ 84.873687] xhci_hcd 0000:04:00.0: Linking segment 0x3cdab000 to segment 0x3cdab000 (DMA) [ 84.882271] xhci_hcd 0000:04:00.0: Wrote link toggle flag to segment ffff88003c41f2c0 (virtual), 0x3cdab000 (DMA) [ 84.893031] xhci_hcd 0000:04:00.0: add ep 0x84, slot id 1, new drop flags = 0x0, new add flags = 0x258, new slot info = 0x48300000 [ 84.905314] xhci_hcd 0000:04:00.0: xhci_check_bandwidth called for udev ffff88003ce9d800 [ 84.914256] xhci_hcd 0000:04:00.0: Completed config ep cmd [ 84.920211] xhci_hcd 0000:04:00.0: Endpoint 0x81 not halted, refusing to reset. [ 84.927926] xhci_hcd 0000:04:00.0: Endpoint 0x2 not halted, refusing to reset. [ 84.935515] xhci_hcd 0000:04:00.0: Endpoint 0x3 not halted, refusing to reset. [ 84.943126] xhci_hcd 0000:04:00.0: Endpoint 0x84 not halted, refusing to reset. [ 84.950784] usb 3-3: adding 3-3:1.0 (config #1, interface 0) [ 86.168339] Compat-wireless backport release: compat-wireless-v3.2-1-s [ 86.175171] Backport based on linux-stable.git v3.2 [ 86.240498] alg: No test for arc4 (arc4-generic) [ 86.289111] cfg80211: Calling CRDA to update world regulatory domain [ 86.415027] rtl8192cu 3-3:1.0: usb_probe_interface [ 86.420055] rtl8192cu 3-3:1.0: usb_probe_interface - got id [ 86.426636] rtl8192cu: rtl8192cu: Chip version 0x11 [ 86.435562] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.451684] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.467671] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.483660] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.499652] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.515642] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.531636] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.547627] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.563616] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.579611] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.595599] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.611589] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.627584] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.643698] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.659815] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.675806] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.691924] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.707917] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.723905] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.739900] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.755886] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.771878] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.787873] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.803985] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.819979] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.836094] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.852087] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.868077] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.884067] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.900063] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.916049] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.932040] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.948038] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.964024] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 86.980018] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 86.996135] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 87.012122] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 87.028118] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 87.044232] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 87.060224] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 87.076214] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 87.092204] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 87.108198] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 87.124312] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 87.140305] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 87.156296] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 87.172285] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 87.188282] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 87.204269] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 87.220260] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 87.236254] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 87.252242] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 87.268236] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 87.279305] rtl8192cu: MAC address: 08:10:74:f1:a1:0f [ 87.284603] rtl8192cu: Board Type 0 [ 87.323297] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1 [ 87.331858] usbcore: registered new interface driver rtl8192cu > > ifconfig wlan0 up [ 107.092673] rtl8192cu: MAC auto ON okay! [ 107.096804] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.112796] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.128415] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.144397] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.160019] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.176007] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.191628] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.207612] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.223234] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.239223] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.254844] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.270828] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.286451] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.302438] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.318059] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.334043] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.349666] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.365656] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.381275] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.397260] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.412883] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.428869] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.444491] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.460475] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.476097] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.489867] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.499458] rtl8192cu: Tx queue select: 0x05 [ 107.509577] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.517732] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 107.525572] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.533680] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cufw.bin [ 107.541306] IS_CHIP_VER_B true. [ 107.544943] _rtl92c_fw_block_write. size:4096. [ 107.549630] _usb_writeN_sync. len:234. [ 107.554298] _usb_writeN_sync. len:234. [ 107.558915] _usb_writeN_sync. len:234. [ 107.563538] _usb_writeN_sync. len:234. [ 107.568163] _usb_writeN_sync. len:234. [ 107.572785] _usb_writeN_sync. len:234. [ 107.577403] _usb_writeN_sync. len:234. [ 107.581341] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.590150] _usb_writeN_sync. len:234. [ 107.594771] _usb_writeN_sync. len:234. [ 107.599390] _usb_writeN_sync. len:234. [ 107.604016] _usb_writeN_sync. len:234. [ 107.608636] _usb_writeN_sync. len:234. [ 107.613259] _usb_writeN_sync. len:234. [ 107.617880] _usb_writeN_sync. len:234. [ 107.622506] _usb_writeN_sync. len:234. [ 107.627126] _usb_writeN_sync. len:234. [ 107.631751] _usb_writeN_sync. len:234. [ 107.636374] _usb_writeN_sync. len:118. [ 107.640743] _rtl92c_fw_block_write. end. [ 107.645249] _rtl92c_fw_block_write. size:4096. [ 107.649904] _usb_writeN_sync. len:234. [ 107.654616] _usb_writeN_sync. len:234. [ 107.659241] _usb_writeN_sync. len:234. [ 107.663858] _usb_writeN_sync. len:234. [ 107.668480] _usb_writeN_sync. len:234. [ 107.673101] _usb_writeN_sync. len:234. [ 107.677726] _usb_writeN_sync. len:234. [ 107.682346] _usb_writeN_sync. len:234. [ 107.686285] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.695097] _usb_writeN_sync. len:234. [ 107.699717] _usb_writeN_sync. len:234. [ 107.704342] _usb_writeN_sync. len:234. [ 107.708964] _usb_writeN_sync. len:234. [ 107.713588] _usb_writeN_sync. len:234. [ 107.718332] _usb_writeN_sync. len:234. [ 107.722973] _usb_writeN_sync. len:234. [ 107.727702] _usb_writeN_sync. len:234. [ 107.732328] _usb_writeN_sync. len:234. [ 107.736949] _usb_writeN_sync. len:118. [ 107.741321] _rtl92c_fw_block_write. end. [ 107.745823] _rtl92c_fw_block_write. size:4096. [ 107.750483] _usb_writeN_sync. len:234. [ 107.755198] _usb_writeN_sync. len:234. [ 107.759823] _usb_writeN_sync. len:234. [ 107.764559] _usb_writeN_sync. len:234. [ 107.769183] _usb_writeN_sync. len:234. [ 107.773928] _usb_writeN_sync. len:234. [ 107.778556] _usb_writeN_sync. len:234. [ 107.783174] _usb_writeN_sync. len:234. [ 107.787799] _usb_writeN_sync. len:234. [ 107.791755] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.800663] _usb_writeN_sync. len:234. [ 107.805286] _usb_writeN_sync. len:234. [ 107.809904] _usb_writeN_sync. len:234. [ 107.814525] _usb_writeN_sync. len:234. [ 107.819149] _usb_writeN_sync. len:234. [ 107.823770] _usb_writeN_sync. len:234. [ 107.828392] _usb_writeN_sync. len:234. [ 107.833014] _usb_writeN_sync. len:234. [ 107.837641] _usb_writeN_sync. len:118. [ 107.842016] _rtl92c_fw_block_write. end. [ 107.846523] _rtl92c_fw_block_write. size:3694. [ 107.851198] _usb_writeN_sync. len:234. [ 107.855886] _usb_writeN_sync. len:234. [ 107.860505] _usb_writeN_sync. len:234. [ 107.865131] _usb_writeN_sync. len:234. [ 107.869752] _usb_writeN_sync. len:234. [ 107.874375] _usb_writeN_sync. len:234. [ 107.878995] _usb_writeN_sync. len:234. [ 107.883620] _usb_writeN_sync. len:234. [ 107.888241] _usb_writeN_sync. len:234. [ 107.892869] _usb_writeN_sync. len:234. [ 107.896816] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.905730] _usb_writeN_sync. len:234. [ 107.910481] _usb_writeN_sync. len:234. [ 107.915098] _usb_writeN_sync. len:234. [ 107.919719] _usb_writeN_sync. len:234. [ 107.924344] _usb_writeN_sync. len:234. [ 107.928962] _usb_writeN_sync. len:184. [ 107.933460] _rtl92c_fw_block_write. end. [ 107.945205] Firmware is ready to run! [ 107.949094] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.957287] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 107.963271] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 107.971473] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 107.977367] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 107.985588] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 107.991478] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.004852] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.013071] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.018958] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.027187] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.033061] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.041293] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.047174] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.055410] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.061268] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.069481] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.075430] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.083628] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.089502] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.097735] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.103705] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.111882] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.117759] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.133371] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.144943] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.153191] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.159081] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.167308] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.173167] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.181384] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.187334] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.195533] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.201416] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.209633] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.215529] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.223774] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.229649] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.245311] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.255398] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.263671] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.269556] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.277768] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.283666] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.291869] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.297739] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.305955] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.311844] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.320078] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.326044] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.537902] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.546519] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.552402] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.568008] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.585898] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.601857] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.614154] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.626031] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.641961] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.650557] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.657441] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.669010] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.677225] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.683213] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.699178] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.707323] xhci_hcd 0000:04:00.0: ERROR no room on ep ring [ 108.715169] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.726359] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.742404] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.758395] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.776279] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.893703] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.908064] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.922937] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.933259] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 108.951411] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 108.964987] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 110.904357] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 110.922220] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 [ 114.902441] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 1 [ 114.920300] xhci_hcd 0000:04:00.0: Toggle cycle state for ring ffff88003c9f99c0 = 0 > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-08 10:32 ` jerome huang @ 2012-03-08 11:26 ` jerome huang 2012-03-08 17:56 ` Larry Finger 0 siblings, 1 reply; 21+ messages in thread From: jerome huang @ 2012-03-08 11:26 UTC (permalink / raw) To: Xu, Andiry; +Cc: Larry Finger, Sarah Sharp, linux-usb, linux-wireless On 8 March 2012 18:32, jerome huang <jerome.syno@gmail.com> wrote: > On 8 March 2012 15:23, Xu, Andiry <Andiry.Xu@amd.com> 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:andiry.xu@amd.com] >>> Sent: Thursday, March 08, 2012 3:12 PM >>> To: jerome huang >>> Cc: Larry Finger; linux-wireless@vger.kernel.org; Sarah Sharp; linux- >>> usb@vger.kernel.org >>> 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: >> >> 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-08 11:26 ` jerome huang @ 2012-03-08 17:56 ` Larry Finger 2012-03-09 3:28 ` jerome huang 0 siblings, 1 reply; 21+ messages in thread From: Larry Finger @ 2012-03-08 17:56 UTC (permalink / raw) To: jerome huang; +Cc: Xu, Andiry, Sarah Sharp, linux-usb, linux-wireless 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-08 17:56 ` Larry Finger @ 2012-03-09 3:28 ` jerome huang 2012-03-09 3:59 ` Larry Finger 0 siblings, 1 reply; 21+ messages in thread From: jerome huang @ 2012-03-09 3:28 UTC (permalink / raw) To: Larry Finger; +Cc: Xu, Andiry, Sarah Sharp, linux-usb, linux-wireless On 9 March 2012 01:56, Larry Finger <Larry.Finger@lwfinger.net> 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-09 3:28 ` jerome huang @ 2012-03-09 3:59 ` Larry Finger 2012-03-09 7:39 ` jerome huang 2012-03-22 22:31 ` Sarah Sharp 0 siblings, 2 replies; 21+ messages in thread From: Larry Finger @ 2012-03-09 3:59 UTC (permalink / raw) To: jerome huang; +Cc: Xu, Andiry, Sarah Sharp, linux-usb, linux-wireless 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-09 3:59 ` Larry Finger @ 2012-03-09 7:39 ` jerome huang 2012-03-09 15:04 ` Larry Finger 2012-03-22 22:31 ` Sarah Sharp 1 sibling, 1 reply; 21+ messages in thread From: jerome huang @ 2012-03-09 7:39 UTC (permalink / raw) To: Larry Finger; +Cc: Xu, Andiry, Sarah Sharp, linux-usb, linux-wireless > > > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-09 7:39 ` jerome huang @ 2012-03-09 15:04 ` Larry Finger 2012-03-09 16:02 ` jerome huang 0 siblings, 1 reply; 21+ messages in thread From: Larry Finger @ 2012-03-09 15:04 UTC (permalink / raw) To: jerome huang; +Cc: Xu, Andiry, Sarah Sharp, linux-usb, linux-wireless 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 <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [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: ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-09 15:04 ` Larry Finger @ 2012-03-09 16:02 ` jerome huang 0 siblings, 0 replies; 21+ messages in thread From: jerome huang @ 2012-03-09 16:02 UTC (permalink / raw) To: Larry Finger; +Cc: Xu, Andiry, Sarah Sharp, linux-usb, linux-wireless On 9 March 2012 23:04, Larry Finger <Larry.Finger@lwfinger.net> 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 <Larry.Finger@lwfinger.net> > Cc: Stable <stable@vger.kernel.org> [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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-09 3:59 ` Larry Finger 2012-03-09 7:39 ` jerome huang @ 2012-03-22 22:31 ` Sarah Sharp 2012-03-23 2:24 ` Larry Finger 1 sibling, 1 reply; 21+ messages in thread From: Sarah Sharp @ 2012-03-22 22:31 UTC (permalink / raw) To: Larry Finger; +Cc: jerome huang, Xu, Andiry, linux-usb, linux-wireless 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-22 22:31 ` Sarah Sharp @ 2012-03-23 2:24 ` Larry Finger 2012-03-23 20:34 ` Sarah Sharp 0 siblings, 1 reply; 21+ messages in thread From: Larry Finger @ 2012-03-23 2:24 UTC (permalink / raw) To: Sarah Sharp; +Cc: jerome huang, Xu, Andiry, linux-usb, linux-wireless 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-23 2:24 ` Larry Finger @ 2012-03-23 20:34 ` Sarah Sharp 2012-03-24 2:16 ` Richard Farina 2012-03-24 4:55 ` Larry Finger 0 siblings, 2 replies; 21+ messages in thread From: Sarah Sharp @ 2012-03-23 20:34 UTC (permalink / raw) To: Larry Finger; +Cc: jerome huang, Xu, Andiry, linux-usb, linux-wireless 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-23 20:34 ` Sarah Sharp @ 2012-03-24 2:16 ` Richard Farina 2012-03-24 4:59 ` Larry Finger 2012-03-24 4:55 ` Larry Finger 1 sibling, 1 reply; 21+ messages in thread From: Richard Farina @ 2012-03-24 2:16 UTC (permalink / raw) To: Sarah Sharp Cc: Larry Finger, jerome huang, Xu, Andiry, linux-usb, linux-wireless 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-24 2:16 ` Richard Farina @ 2012-03-24 4:59 ` Larry Finger 2012-04-05 22:49 ` Sarah Sharp 0 siblings, 1 reply; 21+ messages in thread From: Larry Finger @ 2012-03-24 4:59 UTC (permalink / raw) To: Richard Farina Cc: Sarah Sharp, jerome huang, Xu, Andiry, linux-usb, linux-wireless 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-24 4:59 ` Larry Finger @ 2012-04-05 22:49 ` Sarah Sharp 0 siblings, 0 replies; 21+ messages in thread From: Sarah Sharp @ 2012-04-05 22:49 UTC (permalink / raw) To: Richard Farina Cc: Larry Finger, jerome huang, Xu, Andiry, linux-usb, linux-wireless 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: rt8192cu on USB3 2012-03-23 20:34 ` Sarah Sharp 2012-03-24 2:16 ` Richard Farina @ 2012-03-24 4:55 ` Larry Finger 1 sibling, 0 replies; 21+ messages in thread From: Larry Finger @ 2012-03-24 4:55 UTC (permalink / raw) To: Sarah Sharp; +Cc: jerome huang, Xu, Andiry, linux-usb, linux-wireless 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2012-04-05 22:49 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-08 2:03 rt8192cu on USB3 jerome huang
2012-03-08 2:16 ` jerome huang
2012-03-08 2:35 ` Larry Finger
2012-03-08 6:35 ` jerome huang
2012-03-08 7:06 ` Andiry Xu
2012-03-08 7:11 ` Andiry Xu
[not found] ` <2A76B9D36150BE4293842BC2FE8FF165016A31@SCYBEXDAG04.amd.com>
2012-03-08 10:32 ` jerome huang
2012-03-08 11:26 ` jerome huang
2012-03-08 17:56 ` Larry Finger
2012-03-09 3:28 ` jerome huang
2012-03-09 3:59 ` Larry Finger
2012-03-09 7:39 ` jerome huang
2012-03-09 15:04 ` Larry Finger
2012-03-09 16:02 ` jerome huang
2012-03-22 22:31 ` Sarah Sharp
2012-03-23 2:24 ` Larry Finger
2012-03-23 20:34 ` Sarah Sharp
2012-03-24 2:16 ` Richard Farina
2012-03-24 4:59 ` Larry Finger
2012-04-05 22:49 ` Sarah Sharp
2012-03-24 4:55 ` Larry Finger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).