The content of this topic has been archived between 23 Mar 2017 and 6 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
I thought it was that the router did not have enough amps to power usb and wifi.
So I added a 42amp psu to the router. Same problem. So then I added usb 1.0 belkin hub with a 4amp psu. Still same prob.
Then I added a belkin usb 2.0 hub with a 5amp psu. Still the problem of hanging persists.
So im at a loss with this one but there is no need for the router to be drawing power from the usb when its got powered usb hubs in it.
If I am using the same "Octopus" hub as in this topic (https://forum.openwrt.org/viewtopic.php … 06#p155706), I don't have the problem, I can even connect 2 Arduino boards at the same time and they work perfectly for over a day.
So it is not a power supply wattage problem, but more like the power supply dipping or a low-level conflict when the Wifi radio does something, thus hanging the USB.
Adding larger decoupling capacitors did not solve things.
The "Octopus" hub above is based on the GL850G USB hub chip and is a passive hub.
My feeling is the same as @squonk... there is some power instability issues introduced by the wifi which are smoothed out when using a passive (non-powered) USB hub... I have never seen any issues with my USB devices when using a passive hub. I am using a FE1.1 based (by Terminus) 2.0 4 Port Hub controller.
My point is: TP-link could make it perfect work with the same hardware. This can prove that it's no problem with the power or electrolytic.It must can solve this with sofeware.
My point is: TP-link could make it perfect work with the same hardware. This can prove that it's no problem with the power or electrolytic.It must can solve this with sofeware.
No, we cannot say that TP-Link can make it perfectly work with the same hardware, as we are not sure that the problem doesn't occur with TP-Link's firmware too, as we have no way to stress it with the exact same tests.
And the fact that the problem also occurs on the Alfa AP121U and other devices suggests that it is not something related to TP-Link only.
Maybe using the original firmware (TP-Link and others) to continuously send data through a 3G USB modem might produce something that comes close to our test, but there may quite well be some reconnection mechanism built inside the firmware too, so this is something to verify, too.
Streaming sound is not a good test, as it looks like the problem does not show (or it was unnoticed) when using USB isochronous data.
However, from the sources that TP-Link delivered under GPL (and that are older than the latest firmwares: 12/12/2011), there is apparently no special provision for correcting such a problem.
(Last edited by Squonk on 7 Nov 2012, 08:22)
Try to watch the register 0xb8116c84 and 0xb8116c88,check the value before and after wlan reset,and restore the value back when do wlan reset to workaround this "wlan vs usb" bug.There are many hang check in ath9k driver,and also current the ath9k driver is not stable enough for use,it's wlan reset very often,though nbd fix some deeply bug in the recently svn change,we still need dig the ath9k source code,the ath9k is not stable enough to do the AA formal release...
I get some info from atheros SDK,but i'm not test it and don't make sure it's work for this topic.
Hello @mips.
You seem to be quite knowledgeable about mips and the ar9k processors. Your input is much appreciated. I am trying to understand your post. It looks like there is some information here that might help us address the problems with the USB on most (all?) comercial routers based on the AR9331 processor.
The registers you refer to here (0xb8116c84 and 0xb8116c88) are these for the wlan or for the USB interface? What are these registers? do they contain status information?
it seems that the ath9k kernel code does a lot of checking and resetting the state of the wlan registers. Your suggestion is to go through the code looking for every wlan reset and before doing the reset check the status of registers 0xb8116c84 and 0xb8116c88 and before the reset, record the values, and then restore them after the wlan reset. Is this correct?
You also state that the linux ath9k drivers are deeply flawed and that its not sable enough for sable enough for stable release. I am curious to hear more about this. Are you specifically referring to the wlan operation or are there other deeper and unrelated issues?
could you give an example of the reset code you are referring to? Could you also give an example of what you mean by testing and setting the registers?
I am trying to get a clear understanding of you suggestions so that we can try to implement them. I am happy to go through the code making the changes to test. We have a number of routers here (about 15 from different manufacturers) that all exhibit the issue. I am happy to experiment with any code changes you suggest.
Thank you for your input..
--luis
(Last edited by lsoltero on 7 Nov 2012, 14:18)
Maybe using the original firmware (TP-Link and others) to continuously send data through a 3G USB modem might produce something that comes close to our test, but there may quite well be some reconnection mechanism built inside the firmware too, so this is something to verify, too.
I have been using TP-link routers now for 4 months + with 3G (DC-HSDPA+) as my main internet TP-Links FW are verry buggy for 3g wan. With lots of problems. This is why I moved over to WRT over the last 4 weeks of playing with the routers I have the same problem on both routers. But the USB only drops when uploading on speedtest.net It is fine on any other upload.
It drops on any flash app the uploads...?
Even over wifi on mobiles iOS and android speedtest apps make the router drop the usb port. BUT ONLY when up load starts.
I download files from news groups fine, And download from torrents fine on it. I have speeds of up to 16mbit at the min (making new antenna over the next fue days) The GF is allways streaming from the net. On average I use around 20-70gig a month.
Im going to put a usb HDD on it later this week and see how acting as a FTP server works with it.
What ever this is I do hope we can find a fix.
Hi @mips
On my router, I don't have WLAN problems, only the USB will hang, but only when WLAN is activated. And in this case, WLAN continues to work perfectly, and I don't have any problem with it.
It is only the problem that the USB is stuck until you disconnect/reconnect the device, or you use a passive USB hub in the middle to solve the issue.
hope you don't mind me throwing a totally uneducated thought in:
on unpowered hubs, is there some sort of data cache for "brown outs" in the supply? Just a wildly uninformed thought.
Hi @Squonk:
The ath9k driver is not stable in some case,just like the long run and the high throughput or complex wifi environment...Though you feel the WLAN continues to work perfectly,but the wlan part of the ar9331 may reset many times,you can add a "printk" in the "ar933x_wmac_reset" function,check if you can see some log when the usb hang.
About the ar933x_wmac_reset function,refer here:
https://github.com/mirrors/openwrt/blob … eset.patch
About the ath9k stable issue,refer here:
https://dev.openwrt.org/ticket/9654
Hi @lsoltero:
Because the NDA,I can not do some thing...so sorry!
So please dump the register 0xb8116c84 and 0xb8116c88 before usb hang,and dump them after usb hang and show here.If there are some different,maybe the tips get from the atheros SDK can have a try on this bug.
If this is a chip level bug,so only the atheros know how to fix it.So maybe atheros SDK based firmware don't have this bug,if every atheros SDK based firmware also have this bug,maybe we have no hope to fix it...
About the ath9k driver,many people report the stable issue,it's can run and use,but should fix more to be a product.
@mips: I use the latest SVN from the AA Beta 2 branch, so I already have this patch applied.
As you asked, I added a
pr_err("ar933x: WMAC reset called");... just upon entering the ar9331x_wmac_reset() function and will perform the same test again. I will let you know.
while you are at it could you add a
pr_err("ar933x reg dump: 0x%x, 0x%x", __raw_readl(0xb8116c84), __raw_readl(0xb8116c88));
so that we can see the values of the registers @mips is referring to in his post before and after a USB hang.
--luis
hope you don't mind me throwing a totally uneducated thought in:
on unpowered hubs, is there some sort of data cache for "brown outs" in the supply? Just a wildly uninformed thought.
Been over this befor....
I thought it was that the router did not have enough amps to power usb and wifi.
So I added a 42amp psu to the router. Same problem. So then I added usb 1.0 belkin hub with a 4amp psu. Still same prob.
Then I added a belkin usb 2.0 hub with a 5amp psu. Still the problem of hanging persists.So im at a loss with this one but there is no need for the router to be drawing power from the usb when its got powered usb hubs in it.
Wish to point out the router was runing on a 42 Amp 12v PSU made to run 10 meter band radio amplifier. so 100% no chance its a underpowered problem.
@mips:
The USB problem happened after almost 1 hour running OK.
I have no way to directly print the registers before/after the crash, so I inserted the following lines at the beginning of the ar933x_wmac_reset() function:
pr_err("ar933x: WMAC reset called");
pr_err("ar933x reg dump: 0x%x, 0x%x", __raw_readl((const volatile void *) 0xb8116c84), __raw_readl((const volatile void *) 0xb8116c88));]I then toggled the radio off/on using the LuCI web interface:
[ 937.490000] ath: phy0: Could not stop RX, we could be confusing the DMA engine when we start RX up
[ 937.510000] ath: phy0: Failed to stop TX DMA, queues=0x001!
[ 937.510000] ar933x: WMAC reset called
[ 937.520000] ar933x reg dump: 0xdeadbeef, 0xdeadbeef
[ 938.130000] wlan0: authenticate with 00:24:d4:d0:be:08
[ 938.140000] wlan0: send auth to 00:24:d4:d0:be:08 (try 1/3)
[ 938.150000] wlan0: authenticated
[ 938.150000] ath9k ar933x_wmac: wlan0: disabling HT/VHT due to WEP/TKIP use
[ 938.170000] wlan0: associate with 00:24:d4:d0:be:08 (try 1/3)
[ 938.170000] wlan0: RX AssocResp from 00:24:d4:d0:be:08 (capab=0x411 status=0 aid=2)
[ 938.180000] wlan0: associated
I then inserted the Arduino Leonardo board that sends a counter every second while flashing its"D13" LED:
[ 944.250000] usb 1-1: new full-speed USB device number 4 using ehci-platform
[ 944.400000] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
[ 952.000000] usb 1-1: USB disconnect, device number 4
[ 952.290000] usb 1-1: new full-speed USB device number 5 using ehci-platform
[ 952.450000] cdc_acm 1-1:1.0: This device cannot do calls on its own. It is not a modem.
[ 952.450000] cdc_acm 1-1:1.0: ttyACM0: USB ACM deviceThe problem occurred after 3512 seconds, but there is no call to ar933x_wmac_reset() when this happens, and the network graph looks good:
Then, to get a register dump, I stopped/restarted the radio again:
[ 4525.190000] wlan0: deauthenticating from 00:24:d4:d0:be:08 by local choice (reason=3)
[ 4533.750000] ath: phy0: Failed to stop TX DMA, queues=0x001!
[ 4533.760000] ar933x: WMAC reset called
[ 4533.760000] ar933x reg dump: 0xdeadbeef, 0xdeadbeef
[ 4534.370000] wlan0: authenticate with 00:24:d4:d0:be:08
[ 4534.380000] wlan0: send auth to 00:24:d4:d0:be:08 (try 1/3)
[ 4534.390000] wlan0: authenticated
[ 4534.390000] ath9k ar933x_wmac: wlan0: disabling HT/VHT due to WEP/TKIP use
[ 4534.410000] wlan0: associate with 00:24:d4:d0:be:08 (try 1/3)
[ 4534.410000] wlan0: RX AssocResp from 00:24:d4:d0:be:08 (capab=0x411 status=0 aid=2)
[ 4534.420000] wlan0: associated
The WLAN was still working correctly, and it looks like there is no reset during this hour of testing.
Let me know if I can do some other tests, but I have no easy way to trigger something automatically when this happens.
@Squonk:
I don't know why the 0xb8116c84 and 0xb8116c88,from the ds it's don't have any info about these address.
Can you add a "while and sleep" kernel thread to dump the 0xbb000184 and 0xbb000188,check the value before and after usb hang.Or you can add a kernel timer when the ath9k driver init,dump the 0xbb000184 and 0xbb000188 value and update the timer to do the next dump.
the 0xbb000184 is the "Port/Status Control" register,but ds don't say anything about the 0xbb000188 register.
hello @mips,
i am trying to understand your postings.
You state that you dont have any information on 0xb8116c84 and 0xb8116c88. However in a previous post
https://forum.openwrt.org/viewtopic.php … 31#p182631
you stated that these were the addresses that should be monitored.
can you confirm that the correct addresses to monitor are 0xbb000184 and 0xbb000188? These make more sense than the previous since they are in line with the AR9331 base register.
Where did the code for this posting
https://forum.openwrt.org/viewtopic.php … 27#p182727
come from? have looked through the source tree for WAR_USB_DISABLE... and not found any entries for this.
it would be good to know that sources you are looking at and where this WAR_USB_DISABLE_PLL_LOCK_DETECT is called.
this looks important.
thanks,
--luis
@Squonk:
I don't know why the 0xb8116c84 and 0xb8116c88,from the ds it's don't have any info about these address.
Can you add a "while and sleep" kernel thread to dump the 0xbb000184 and 0xbb000188,check the value before and after usb hang.Or you can add a kernel timer when the ath9k driver init,dump the 0xbb000184 and 0xbb000188 value and update the timer to do the next dump.
the 0xbb000184 is the "Port/Status Control" register,but ds don't say anything about the 0xbb000188 register.
@mips:
Yes, I will add a kernel thread to monitor these registers.
However, I will not be able to do that before next week, so if someone else can perform the test, the hardware and software setup required to reproduce the crash is pretty simple, anyway.
Please, don't take any risk with what you say, we know it is very difficult to have information and not be able to say anything 
(Last edited by Squonk on 8 Nov 2012, 19:41)
sorry folks... i have been out of the office all day... i will add the kernel thread to dump the register settings every second and then reproduce the error and report back.. probably sometime tomorrow.
--luis
@Squonk:
Thanks for your reminding,I edit it and only keep the core part ...
@lsoltero:
Sorry for making you confuse...the 0xb8116c84 and 0xb8116c88 are get from the code.but it's not a valid access from the datasheet.So reference the code and datasheet,I guess we can try the 0xbb000184 and 0xbb000188,but just guess ...
@mips:
OK. thank you for that... I had intended to get to this today but was unable to... I will try tomorrow capturing the status of all the registers you mention and post my results here.
--luis
so i modified the code to dump the following registers...
pr_err("ar933x reg dump: 0x%x, 0x%x, 0x%x, 0x%x", __raw_readl((const volatile void *) 0xbb000184), __raw_readl((const volatile void *) 0xbb000188),
__raw_readl((const volatile void *) 0xb8116c84), __raw_readl((const volatile void *) 0xb8116c88));
[ 38.570000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 39.580000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 40.590000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 41.600000] ar933x reg dump: 0x10001801, 0x0, 0x84100095, 0xf01b6c
[ 41.820000] usb 1-1: new full-speed USB device number 2 using ehci-platform
[ 41.980000] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
the registers changed when the USB device was plugged in...
PPPD was then started.
[ 42.610000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 43.620000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 44.650000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 45.670000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 46.720000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 47.740000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 48.750000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
but there was no change in the values of the registers when the interface hung...
the USB was then removed... the registers changed.
root@Optimizer:/#
[ 302.290000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 303.300000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 303.600000] usb 1-1: USB disconnect, device number 2
[ 303.610000] cdc_acm 1-1:1.0: acm_ctrl_irq - usb_submit_urb failed: -19
[ 304.310000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 305.320000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
the USB was then plugged back in...
[ 382.080000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 383.090000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 384.100000] ar933x reg dump: 0x10001801, 0x0, 0x84100095, 0xf01b6c
[ 384.330000] usb 1-1: new full-speed USB device number 3 using ehci-platform
[ 384.490000] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
[ 385.110000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 386.120000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 387.130000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
and the dialing repeated
[ 643.670000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 644.680000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 645.690000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 646.700000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 647.710000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 648.720000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
i do notice that when the usb is being used (and its working the registers do change often)
598.220000] ar933x reg dump: 0x10001405, 0x0, 0x84100095, 0xf01b6c
[ 599.230000] ar933x reg dump: 0x10001405, 0x0, 0x84100095, 0xf01b6c
[ 600.240000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 601.250000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 602.260000] ar933x reg dump: 0x10001405, 0x0, 0x84100095, 0xf01b6c
[ 603.270000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 604.280000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 605.290000] ar933x reg dump: 0x10001405, 0x0, 0x84100095, 0xf01b6c
[ 606.300000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 607.310000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 608.320000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 609.330000] ar933x reg dump: 0x10001405, 0x0, 0x84100095, 0xf01b6c
[ 610.340000] ar933x reg dump: 0x10001405, 0x0, 0x84100095, 0xf01b6c
[ 611.350000] ar933x reg dump: 0x10001405, 0x0, 0x84100095, 0xf01b6c
[ 612.360000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 613.370000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 614.380000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
i did get this when i unplugged the hung device this time...
760.830000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 761.840000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 762.850000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
[ 763.380000] usb 1-1: USB disconnect, device number 3
[ 763.380000] cdc_acm 1-1:1.0: acm_ctrl_irq - usb_submit_urb failed: -19
[ 763.860000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 763.960000] ------------[ cut here ]------------
[ 763.960000] WARNING: at drivers/tty/tty_io.c:1357 0x801849e4()
[ 763.970000] Modules linked in: pl2303 ftdi_sio usbserial snd_usb_audio snd_usbmidi_lib cdc_acm ath79_wdt ohci_hcd ledtrig_usbdev ledtrig_netdev nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat xt_conntrack xt_CT xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ehci_hcd ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables tty0tty(O) snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_rawmidi snd_seq_device snd_hwdep snd_page_alloc snd soundcore ppp_async ppp_generic slhc ath9k(O) ath9k_common(O) ath9k_hw(O) ath(O) mac80211(O) usbcore usb_common nls_base crc_ccitt cfg80211(O) compat(O) input_core arc4 aes_generic crypto_algapi ledtrig_timer ledtrig_default_on leds_gpio gpio_button_hotplug(O)
[ 764.040000] Call Trace:[<802618ac>] 0x802618ac
[ 764.040000] [<802618ac>] 0x802618ac
[ 764.050000] [<800719fc>] 0x800719fc
[ 764.050000] [<801849e4>] 0x801849e4
[ 764.050000] [<80071a40>] 0x80071a40
[ 764.060000] [<80182c9c>] 0x80182c9c
[ 764.060000] [<801849e4>] 0x801849e4
[ 764.060000] [<800e0b4c>] 0x800e0b4c
[ 764.070000] [<800aa288>] 0x800aa288
[ 764.070000] [<800db20c>] 0x800db20c
[ 764.080000] [<800e0d8c>] 0x800e0d8c
[ 764.080000] [<800db0f8>] 0x800db0f8
[ 764.080000] [<800d5838>] 0x800d5838
[ 764.090000] [<800e43ec>] 0x800e43ec
[ 764.090000] [<800e462c>] 0x800e462c
[ 764.090000] [<8009e828>] 0x8009e828
[ 764.100000] [<800e4a10>] 0x800e4a10
[ 764.100000] [<800eedd4>] 0x800eedd4
[ 764.100000] [<800e1478>] 0x800e1478
[ 764.110000] [<800d68a0>] 0x800d68a0
[ 764.110000] [<80264f54>] 0x80264f54
[ 764.110000] [<8006a204>] 0x8006a204
[ 764.120000]
[ 764.120000] ---[ end trace 069ae56fe57b7b73 ]---
[ 764.870000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 765.880000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 766.890000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 767.900000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 768.910000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 769.920000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 770.930000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 771.940000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 772.950000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
[ 773.960000] ar933x reg dump: 0x1c001000, 0x0, 0x84100095, 0xf01b6c
here is an example of where the registers did not change between working and not working...
ep 8 16:00:22 Optimizer local2.info chat[3558]: ^M
Sep 8 16:00:22 Optimizer local2.info chat[3558]: OK
Sep 8 16:00:22 Optimizer local2.info chat[3558]: -- got it
Sep 8 16:00:22 Optimizer local2.info chat[3558]: send (AT E0 V1 &D2 &C1 W2 S95=47 S0=0 +cbst=71,0,1^M)
Sep 8 16:00:22 Optimizer kern.err kernel: [ 1000.200000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
Sep 8 16:00:23 Optimizer local2.info chat[3558]: timeout set to 60 seconds
Sep 8 16:00:23 Optimizer local2.info chat[3558]: expect (OK)
Sep 8 16:00:23 Optimizer local2.info chat[3558]: ^M
Sep 8 16:00:23 Optimizer local2.info chat[3558]: AT E0 V1 &D2 &C1 W2 S95=47 S0=0 +cbst=71,0,1^M^M
Sep 8 16:00:23 Optimizer local2.info chat[3558]: OK
Sep 8 16:00:23 Optimizer local2.info chat[3558]: -- got it
Sep 8 16:00:23 Optimizer local2.info chat[3558]: send (ATDT008816000025^M)
Sep 8 16:00:23 Optimizer local2.info chat[3558]: expect (CONNECT)
Sep 8 16:00:23 Optimizer local2.info chat[3558]: ^M
Sep 8 16:00:24 Optimizer kern.err kernel: [ 1001.210000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
Sep 8 16:00:25 Optimizer kern.err kernel: [ 1002.220000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
Sep 8 16:00:26 Optimizer kern.err kernel: [ 1003.230000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
Sep 8 16:00:27 Optimizer kern.err kernel: [ 1004.240000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
Sep 8 16:00:28 Optimizer kern.err kernel: [ 1005.250000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
Sep 8 16:00:29 Optimizer kern.err kernel: [ 1006.260000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
Sep 8 16:00:30 Optimizer kern.err kernel: [ 1007.270000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
Sep 8 16:00:31 Optimizer kern.err kernel: [ 1008.280000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
Sep 8 16:00:32 Optimizer kern.err kernel: [ 1009.290000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
Sep 8 16:00:33 Optimizer kern.err kernel: [ 1010.300000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
Sep 8 16:00:34 Optimizer kern.err kernel: [ 1011.310000] ar933x reg dump: 0x10001805, 0x0, 0x84100095, 0xf01b6c
so... not sure at this time if there is a correlation between the register values and working/non working USB devices.
anyone have any ideas?
--luis
I will also mention that like @Squonk I am not seeing ar933x_wmac_reset(void) called once on boot up and when the WLAN is reset. Otherwise this function is not being called.
--luis