2016-02-28 01:06:36

by alexander nekrasov

[permalink] [raw]
Subject: carl1970: stops working at random periods on Ubuntu 15.05

I'm using TP-LINK TL-WN821N and encountering very annoying behaviour -
adapter 'hangs' at random period of time - sometimes it is 1 hour,
sometimes 2. After it hangs Network manager does not see any wireless
networks and the only way to make it work is to reboot system (also
tried unplugging/plugging adapter and removing/adding module but it
did not work)

Heres lsusb -v:
Bus 004 Device 004: ID 0cf3:1002 Atheros Communications, Inc. TP-Link
TL-WN821N v2 / TL-WN822N v1 802.11n [Atheros AR9170]

And here what i have in syslog right before the hang:
Feb 28 01:23:45 evren kernel: [ 3590.458890] ------------[ cut here
]------------
Feb 28 01:23:45 evren kernel: [ 3590.458919] WARNING: CPU: 0 PID: 3749
at /build/linux-PoTihC/linux-4.2.0/drivers/net/wireless/ath/carl9170/main.c:1012
carl9170_op_configure_filter+0x191/0x1a0 [carl9170]()
Feb 28 01:23:45 evren kernel: [ 3590.458925] Modules linked in: drbg
ansi_cprng ctr ccm binfmt_misc fglrx(POE) arc4 snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_codec_hdmi carl9170 snd_hda_intel
snd_hda_codec snd_hda_core ath mac80211 snd_hwdep snd_pcm snd_seq_midi
snd_seq_midi_event cfg80211 kvm_amd kvm snd_rawmidi snd_seq input_leds
joydev snd_seq_device snd_timer edac_core serio_raw edac_mce_amd snd
soundcore k10temp asus_atk0110 amd_iommu_v2 8250_fintek i2c_piix4
shpchp mac_hid cuse parport_pc ppdev lp parport autofs4 pata_acpi
hid_generic usbhid hid r8169 psmouse pata_jmicron firewire_ohci mii
firewire_core pata_atiixp crc_itu_t ahci libahci wmi
Feb 28 01:23:45 evren kernel: [ 3590.459018] CPU: 0 PID: 3749 Comm:
kworker/u16:0 Tainted: P W OE 4.2.0-30-generic #36-Ubuntu
Feb 28 01:23:45 evren kernel: [ 3590.459024] Hardware name: System
manufacturer System Product Name/M4A89GTD-PRO/USB3, BIOS 3029
07/05/2012
Feb 28 01:23:45 evren kernel: [ 3590.459063] Workqueue: phy1
ieee80211_reconfig_filter [mac80211]
Feb 28 01:23:45 evren kernel: [ 3590.459068] 0000000000000000
00000000d9cf9215 ffff8800b240fce8 ffffffff817ebf13
Feb 28 01:23:45 evren kernel: [ 3590.459075] 0000000000000000
0000000000000000 ffff8800b240fd28 ffffffff8107b9d6
Feb 28 01:23:45 evren kernel: [ 3590.459082] 8000000000000001
ffff8800c88b5440 ffff8800b240fdac 8000000000000001
Feb 28 01:23:45 evren kernel: [ 3590.459089] Call Trace:
Feb 28 01:23:45 evren kernel: [ 3590.459102] [<ffffffff817ebf13>]
dump_stack+0x45/0x57
Feb 28 01:23:45 evren kernel: [ 3590.459112] [<ffffffff8107b9d6>]
warn_slowpath_common+0x86/0xc0
Feb 28 01:23:45 evren kernel: [ 3590.459120] [<ffffffff8107bb0a>]
warn_slowpath_null+0x1a/0x20
Feb 28 01:23:45 evren kernel: [ 3590.459130] [<ffffffffc0426c71>]
carl9170_op_configure_filter+0x191/0x1a0 [carl9170]
Feb 28 01:23:45 evren kernel: [ 3590.459163] [<ffffffffc0373939>]
ieee80211_configure_filter+0x149/0x2a0 [mac80211]
Feb 28 01:23:45 evren kernel: [ 3590.459196] [<ffffffffc0373aa5>]
ieee80211_reconfig_filter+0x15/0x20 [mac80211]
Feb 28 01:23:45 evren kernel: [ 3590.459205] [<ffffffff810947aa>]
process_one_work+0x1aa/0x440
Feb 28 01:23:45 evren kernel: [ 3590.459213] [<ffffffff81094a8b>]
worker_thread+0x4b/0x4c0
Feb 28 01:23:45 evren kernel: [ 3590.459221] [<ffffffff81094a40>] ?
process_one_work+0x440/0x440
Feb 28 01:23:45 evren kernel: [ 3590.459228] [<ffffffff8109ae28>]
kthread+0xd8/0xf0
Feb 28 01:23:45 evren kernel: [ 3590.459236] [<ffffffff8109ad50>] ?
kthread_create_on_node+0x1f0/0x1f0
Feb 28 01:23:45 evren kernel: [ 3590.459243] [<ffffffff817f319f>]
ret_from_fork+0x3f/0x70
Feb 28 01:23:45 evren kernel: [ 3590.459249] [<ffffffff8109ad50>] ?
kthread_create_on_node+0x1f0/0x1f0
Feb 28 01:23:45 evren kernel: [ 3590.459255] ---[ end trace
fe0c60ee5cb8db9a ]---
Feb 28 01:23:46 evren kernel: [ 3591.459129] ------------[ cut here
]------------

Following messages are also relevant to adapter failure but i guess it
will be to long to post it here.

Also after unplugging/pluggin i see following:
Feb 28 01:46:44 evren kernel: [ 4970.256337] usb 4-1.4: USB
disconnect, device number 13
Feb 28 01:46:52 evren kernel: [ 4977.878803] usb 4-1.4: new high-speed
USB device number 14 using ehci-pci
Feb 28 01:46:52 evren kernel: [ 4978.023152] usb 4-1.4: New USB device
found, idVendor=0cf3, idProduct=1002
Feb 28 01:46:52 evren kernel: [ 4978.023166] usb 4-1.4: New USB device
strings: Mfr=16, Product=32, SerialNumber=48
Feb 28 01:46:52 evren kernel: [ 4978.023173] usb 4-1.4: Product: USB2.0 WLAN
Feb 28 01:46:52 evren kernel: [ 4978.023179] usb 4-1.4: Manufacturer: ATHER
Feb 28 01:46:52 evren kernel: [ 4978.023185] usb 4-1.4: SerialNumber: 12345
Feb 28 01:46:52 evren kernel: [ 4978.098854] usb 4-1.4: reset
high-speed USB device number 14 using ehci-pci
Feb 28 01:46:52 evren kernel: [ 4978.232174] usb 4-1.4: driver API:
1.9.7 2012-12-15 [1-1]
Feb 28 01:46:52 evren kernel: [ 4978.232187] usb 4-1.4: firmware API:
1.9.6 2012-07-07
Feb 28 01:46:52 evren kernel: [ 4978.569953] ath: EEPROM regdomain: 0x809c
Feb 28 01:46:52 evren kernel: [ 4978.569962] ath: EEPROM indicates we
should expect a country code
Feb 28 01:46:52 evren kernel: [ 4978.569967] ath: doing EEPROM
country->regdmn map search
Feb 28 01:46:52 evren kernel: [ 4978.569971] ath: country maps to
regdmn code: 0x52
Feb 28 01:46:52 evren kernel: [ 4978.569975] ath: Country alpha2 being used: CN
Feb 28 01:46:52 evren kernel: [ 4978.569980] ath: Regpair used: 0x52
Feb 28 01:46:52 evren kernel: [ 4978.570407] ieee80211 phy1: Selected
rate control algorithm 'minstrel_ht'
Feb 28 01:46:25 evren wpa_supplicant[835]: message repeated 3 times: [
wlan0: CTRL-EVENT-SCAN-FAILED ret=-19 retry=1]
Feb 28 01:46:52 evren NetworkManager[691]: <info> (wlan0): using
nl80211 for WiFi device control
Feb 28 01:46:52 evren NetworkManager[691]: <info> (wlan0): driver
supports Access Point (AP) mode
Feb 28 01:46:52 evren kernel: [ 4978.576459] input: phy1 WPS Button as
/devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.4/4-1.4:1.0/ieee80211/phy1/input31
Feb 28 01:46:52 evren NetworkManager[691]: <info> rfkill8: found WiFi
radio killswitch (at
/sys/devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.4/4-1.4:1.0/ieee80211/phy1/rfkill8)
(driver carl9170)
Feb 28 01:46:52 evren systemd[1]: Starting Load/Save RF Kill Switch
Status of rfkill8...
Feb 28 01:46:52 evren systemd[1]: Started Load/Save RF Kill Switch
Status of rfkill8.
Feb 28 01:46:53 evren kernel: [ 4978.752536] IPv6:
ADDRCONF(NETDEV_UP): wlan0: link is not ready
Feb 28 01:46:53 evren kernel: [ 4978.753087] usb 4-1.4: no command
feedback received (-90).
Feb 28 01:46:53 evren kernel: [ 4978.753098] usb 4-1.4: restart device (6)
Feb 28 01:46:53 evren NetworkManager[691]: <info> devices added
(path: /sys/devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.4/4-1.4:1.0/net/wlan0,
iface: wlan0)
Feb 28 01:46:53 evren NetworkManager[691]: <info> device added (path:
/sys/devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.4/4-1.4:1.0/net/wlan0,
iface: wlan0): no ifupdown configuration found.
Feb 28 01:46:53 evren wpa_supplicant[835]: wlan0:
CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=CN
Feb 28 01:46:53 evren NetworkManager[691]: <info> (wlan0): supplicant
interface state: disabled -> inactive
Feb 28 01:46:54 evren kernel: [ 4979.891093] usb 4-1.4: device
restarted successfully.
Feb 28 01:46:54 evren kernel: [ 4979.899273] ieee80211 phy1: Hardware
restart was requested
Feb 28 01:46:54 evren avahi-daemon[681]: Withdrawing workstation
service for wlan0.
Feb 28 01:46:54 evren ModemManager[642]: <info> (net/wlan0): released
by modem /sys/devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.4
Feb 28 01:46:54 evren NetworkManager[691]: <info> devices removed
(path: /sys/devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.4/4-1.4:1.0/net/wlan0,
iface: wlan0)
Feb 28 01:46:54 evren NetworkManager[691]: <info> radio killswitch
/sys/devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.4/4-1.4:1.0/ieee80211/phy1/rfkill8
disappeared
Feb 28 01:46:54 evren systemd[1]: Stopping Load/Save RF Kill Switch
Status of rfkill8...
Feb 28 01:46:54 evren NetworkManager[691]: <info> (wlan0): supplicant
interface state: inactive -> disabled
Feb 28 01:46:54 evren systemd[1]: Stopped Load/Save RF Kill Switch
Status of rfkill8.
Feb 28 01:46:55 evren ModemManager[642]: <info> Couldn't find support
for device at '/sys/devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1.4':
not supported by any plugin

Cab smb help me to solve this issue?


2016-02-28 12:27:54

by Christian Lamparter

[permalink] [raw]
Subject: Re: carl1970: stops working at random periods on Ubuntu 15.05

Hello,

On Sunday, February 28, 2016 03:06:35 AM alexander nekrasov wrote:
> I'm using TP-LINK TL-WN821N and encountering very annoying behaviour -
> adapter 'hangs' at random period of time - sometimes it is 1 hour,
> sometimes 2. After it hangs Network manager does not see any wireless
> networks and the only way to make it work is to reboot system (also
> tried unplugging/plugging adapter and removing/adding module but it
> did not work)
Did it get hot? Or Have you tried unloading/reloading the ohci/ehci/xhci?
The used USB-PHY FUSB200 (in the AR9170) is known to misbehave. If you
want to read more about the implications and possible solution, you can
visit the ath9k_htc firmware community. They have written a wiki entry
which describes the issues in detail [0].

> Heres lsusb -v:
> Bus 004 Device 004: ID 0cf3:1002 Atheros Communications, Inc. TP-Link
> TL-WN821N v2 / TL-WN822N v1 802.11n [Atheros AR9170]
>
> And here what i have in syslog right before the hang:
> Following messages are also relevant to adapter failure but i guess it
> will be to long to post it here.
>
> Feb 28 01:46:53 evren kernel: [ 4978.753087] usb 4-1.4: no command
> feedback received (-90).
> Feb 28 01:46:53 evren kernel: [ 4978.753098] usb 4-1.4: restart device (6)
> Feb 28 01:46:54 evren kernel: [ 4979.891093] usb 4-1.4: device
> restarted successfully.
> Feb 28 01:46:54 evren kernel: [ 4979.899273] ieee80211 phy1: Hardware
> restart was requested
Commands are issued on the devices end point #4.... And the response the
driver is waiting for doesn't get through. If you want to debug this,
you'll need to look at the usb data stream and check which party (host
controller (ehci/ohci), device (AR9170) or cable?) is at fault.

Regards,
Christian

[0] <https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues>

2016-03-19 21:03:12

by alexander nekrasov

[permalink] [raw]
Subject: Re: carl1970: stops working at random periods on Ubuntu 15.05

I've tried device on another computer booting from flashdrive with
Ubuntu 13.10 (kernel 3.8 as far as I remember) and bind/unbind work
OK. Then i booted on my computer from the same flash and everything
worked OK. So it seems its kernel/usb-system/driver issue. Another
thing that makes me think so is that only reboot helps to restore
device - if it would be device - plugging/unplugging would be enought

On 12 March 2016 at 22:59, Christian Lamparter <[email protected]> wrote:
> On Friday, March 11, 2016 09:12:40 AM alexander nekrasov wrote:
>> Thanks for an answer, Christian! Adapter is getting hot sometimes
>> indeed. Also my adapter is usb2.0 but it was on extender with another
>> usb1.1 device. I plugged it into motherboards port directly but issue
>> still continue to happens. I also tried reload host controller but it
>> did not help.
> In that case, this might be a problem with the host controller on your
> motherboard. I say "might", because it could also be that the ar9170
> device is damaged or that something else is going on. Can you test the
> device on a different PC and test if it fails in the same way?
>
> Other than that, there's not much you can do (easily). If you want
> to investigate the issue further, you would need probe the FUSB200
> in the device. The only place you can do that is within the firmware
> as the USB subsystem is breaking down. The firmware can be downloaded
> from [0]. The register to look at is 0x1E110C (AR9170_USB_REG_DMA_STATUS).
>
> There are a few error bits that can be checked.
>
> Bit 24: Error when the upstream DMA access the data bus.
> Bit 25: Error when the upstream DMA access the command bus.
> Bit 26: Error when the downstream DMA access the data bus.
> Bit 27: Error when the downstream DMA access the command bus.
> Bit 28: Error when the CPU access the data bus.
> Bit 29: Error when the CPU access the command bus.
>
> If any of those bits are set, it's probably time to issue a
> firmware reboot (set fw.reboot to 1 or directly call "reboot();").
>
> That said, I don't have high hopes. In your logs, the carl9170
> driver is already trying to reset the device... and failing since
> it is unable to communicate with the device.
>
>> However I discovered strange behavior. Here is my
>> scenario:
>> 1. boot system
>> 2. check device is displayed by 'lsusb' and 'lsusb -t'
>> 3. unbind and bind root hub where device is plugged into
>> 4. this time 'lsusb' does list device and 'lsusb -t' does not
>>
>> Is it ok?
>>
>> After unbind/bind device definitely is not working - there is led
>> indicator and it is off. Should I 'enable' device after binding root
>> hub with another command?
>
> I would suggest you also contact the linux-usb mailing list [1].
> They may be able to debug why the host controller is not responding
> to the bind and unbind.
>
> [0] <https://wireless.wiki.kernel.org/en/users/drivers/carl9170.fw>
> [1] <http://www.linux-usb.org/mailing.html>

2016-03-11 07:12:41

by alexander nekrasov

[permalink] [raw]
Subject: Re: carl1970: stops working at random periods on Ubuntu 15.05

Thanks for an answer, Christian! Adapter is getting hot sometimes
indeed. Also my adapter is usb2.0 but it was on extender with another
usb1.1 device. I plugged it into motherboards port directly but issue
still continue to happens. I also tried reload host controller but it
did not help. However I discovered strange behavior. Here is my
scenario:
1. boot system
2. check device is displayed by 'lsusb' and 'lsusb -t'
3. unbind and bind root hub where device is plugged into
4. this time 'lsusb' does list device and 'lsusb -t' does not

Is it ok?

After unbind/bind device definitely is not working - there is led
indicator and it is off. Should I 'enable' device after binding root
hub with another command?

On 28 February 2016 at 23:33, alexander nekrasov <[email protected]> wrote:
> Thanks for an answer, Christian! Adapter is getting hot sometimes
> indeed. I will try reload host controller next time it happens, but
> I'm afraid Im to newbie to do the 'usb data stream debugging' =) I'm
> also reading link maybe it'll help me. Thanks again
>
> On 28 February 2016 at 14:27, Christian Lamparter
> <[email protected]> wrote:
>> Hello,
>>
>> On Sunday, February 28, 2016 03:06:35 AM alexander nekrasov wrote:
>>> I'm using TP-LINK TL-WN821N and encountering very annoying behaviour -
>>> adapter 'hangs' at random period of time - sometimes it is 1 hour,
>>> sometimes 2. After it hangs Network manager does not see any wireless
>>> networks and the only way to make it work is to reboot system (also
>>> tried unplugging/plugging adapter and removing/adding module but it
>>> did not work)
>> Did it get hot? Or Have you tried unloading/reloading the ohci/ehci/xhci?
>> The used USB-PHY FUSB200 (in the AR9170) is known to misbehave. If you
>> want to read more about the implications and possible solution, you can
>> visit the ath9k_htc firmware community. They have written a wiki entry
>> which describes the issues in detail [0].
>>
>>> Heres lsusb -v:
>>> Bus 004 Device 004: ID 0cf3:1002 Atheros Communications, Inc. TP-Link
>>> TL-WN821N v2 / TL-WN822N v1 802.11n [Atheros AR9170]
>>>
>>> And here what i have in syslog right before the hang:
>>> Following messages are also relevant to adapter failure but i guess it
>>> will be to long to post it here.
>>>
>>> Feb 28 01:46:53 evren kernel: [ 4978.753087] usb 4-1.4: no command
>>> feedback received (-90).
>>> Feb 28 01:46:53 evren kernel: [ 4978.753098] usb 4-1.4: restart device (6)
>>> Feb 28 01:46:54 evren kernel: [ 4979.891093] usb 4-1.4: device
>>> restarted successfully.
>>> Feb 28 01:46:54 evren kernel: [ 4979.899273] ieee80211 phy1: Hardware
>>> restart was requested
>> Commands are issued on the devices end point #4.... And the response the
>> driver is waiting for doesn't get through. If you want to debug this,
>> you'll need to look at the usb data stream and check which party (host
>> controller (ehci/ohci), device (AR9170) or cable?) is at fault.
>>
>> Regards,
>> Christian
>>
>> [0] <https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues>

2016-03-12 20:59:26

by Christian Lamparter

[permalink] [raw]
Subject: Re: carl1970: stops working at random periods on Ubuntu 15.05

On Friday, March 11, 2016 09:12:40 AM alexander nekrasov wrote:
> Thanks for an answer, Christian! Adapter is getting hot sometimes
> indeed. Also my adapter is usb2.0 but it was on extender with another
> usb1.1 device. I plugged it into motherboards port directly but issue
> still continue to happens. I also tried reload host controller but it
> did not help.
In that case, this might be a problem with the host controller on your
motherboard. I say "might", because it could also be that the ar9170
device is damaged or that something else is going on. Can you test the
device on a different PC and test if it fails in the same way?

Other than that, there's not much you can do (easily). If you want
to investigate the issue further, you would need probe the FUSB200
in the device. The only place you can do that is within the firmware
as the USB subsystem is breaking down. The firmware can be downloaded
from [0]. The register to look at is 0x1E110C (AR9170_USB_REG_DMA_STATUS).

There are a few error bits that can be checked.

Bit 24: Error when the upstream DMA access the data bus.
Bit 25: Error when the upstream DMA access the command bus.
Bit 26: Error when the downstream DMA access the data bus.
Bit 27: Error when the downstream DMA access the command bus.
Bit 28: Error when the CPU access the data bus.
Bit 29: Error when the CPU access the command bus.

If any of those bits are set, it's probably time to issue a
firmware reboot (set fw.reboot to 1 or directly call "reboot();").

That said, I don't have high hopes. In your logs, the carl9170
driver is already trying to reset the device... and failing since
it is unable to communicate with the device.

> However I discovered strange behavior. Here is my
> scenario:
> 1. boot system
> 2. check device is displayed by 'lsusb' and 'lsusb -t'
> 3. unbind and bind root hub where device is plugged into
> 4. this time 'lsusb' does list device and 'lsusb -t' does not
>
> Is it ok?
>
> After unbind/bind device definitely is not working - there is led
> indicator and it is off. Should I 'enable' device after binding root
> hub with another command?

I would suggest you also contact the linux-usb mailing list [1].
They may be able to debug why the host controller is not responding
to the bind and unbind.

[0] <https://wireless.wiki.kernel.org/en/users/drivers/carl9170.fw>
[1] <http://www.linux-usb.org/mailing.html>