bug report for ath9k_htc driver

bug report for ath9k_htc driver

[Jeremy Audet]

ath9k_htc driver bug report
===========================

I'm writing in to report a bug (I think) with the ath9k_htc driver.

I am using a TP-LINK TL-WN722N USB wireless adapter. According to the USB
drivers page [1], this device uses the ath9k_htc driver, and the ath9k_htc
driver page [2] requests that readers "report bugs, crashes, weird behavior and
other general tantrums thrown by the driver." That's what I'm doing now.

I am attempting to use the TL-WN722N to create a wireless access point. (Yeah,
I'm sure there's better devices out there. Spare me the sarcasm, but please do
give a suggestion for better-supported hardware.) I have briefly been able to
make this work: my phone has associated with an access point advertised by the
TL-WN722N and accessed outside networks at wonderfully zippy WiFi speeds.
Unfortunately, the AP functioned for a mere matter of minutes.

This has made me wonder whether the issue lies with netctl (the high-level
network manager I'm using) or underlying software. Unfortunately, the latter
appears to be the case. Merely bringing up the wireless interface with the `ip`
utility causes gobs of nasty information to be printed to the system log.

You ask for a bit of information on the "Reporting_bugs" web page, and what
follows is my best attempt to provide that information. Please let me know if
there's anything else I can do to help diagnose or fix this issue. I'm modestly
experienced with software engineering, Linux system administration and computer
networking, and I am happy to learn more, but this is totally new to me.

Please CC me when replying. I am not subscribed to this mailing list.

device information
------------------

Trimmed output from `sudo bash -c 'lsusb -v'` is available here:
http://www.ichimonji10.name/downloads/tl-wn722n-lsusb.txt

Device firmware is installed on the system.

    $ find /usr/lib/firmware -name '*9271*'
    /usr/lib/firmware/ar9271.fw
    /usr/lib/firmware/htc_9271.fw

software versions
-----------------

Here you go:

    $ uname -a
    Linux pine 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC
2014 x86_64 GNU/Linux
    $ ip -V
    ip utility, iproute2-ss141009
    $ netctl --version
    netctl version 1.9

command invocations and log output
----------------------------------

The system has three physical interfaces. enp2s0 is used as an external
interface, and the internal interfaces are enp3s0 and wlp0s18f0u4.

    $ ip link show
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state
UNKNOWN mode DEFAULT group default
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    2: enp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state
DOWN mode DEFAULT group default qlen 1000
        link/ether b8:97:5a:04:f4:c8 brd ff:ff:ff:ff:ff:ff
    3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 68:05:ca:01:20:a0 brd ff:ff:ff:ff:ff:ff
    6: wlp0s18f0u4: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
mode DEFAULT group default qlen 1000
        link/ether e8:de:27:1a:31:a6 brd ff:ff:ff:ff:ff:ff

The wireless interface can successfully be brought up and down.

    $ sudo ip link set dev wlp0s18f0u4 up; echo $?
    0
    $ sudo ip link set dev wlp0s18f0u4 down; echo $?
    0

I executed `iw event -t` before executing the `ip` commands above. It had
nothing to say. I also executed `dmesg --follow > ~/tmp/dmesg.log` while
executing the `ip` commands above, and it had lots to say:

    $ wc ~/tmp/dmesg.log
    61391  385687 5337913 /home/ichimonji10/tmp/dmesg.log

`dmesg.log` is available here:
http://www.ichimonji10.name/downloads/tl-wn722n-dmesg.txt

-Jeremy "Ichimonji10" Audet

[1] http://wireless.kernel.org/en/users/Drivers
[2] http://wireless.kernel.org/en/users/Drivers/ath9k_htc
[3] https://wiki.archlinux.org/index.php/Netctl

Re: bug report for ath9k_htc driver

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 4545 bytes --]

Hi Jeremy,

please try latest firmware,
https://github.com/olerem/ath9k-htc-firmware-blob


Am 23.12.2014 um 00:53 schrieb Jeremy Audet:
> ath9k_htc driver bug report
> ===========================
> 
> I'm writing in to report a bug (I think) with the ath9k_htc driver.
> 
> I am using a TP-LINK TL-WN722N USB wireless adapter. According to the USB
> drivers page [1], this device uses the ath9k_htc driver, and the ath9k_htc
> driver page [2] requests that readers "report bugs, crashes, weird behavior and
> other general tantrums thrown by the driver." That's what I'm doing now.
> 
> I am attempting to use the TL-WN722N to create a wireless access point. (Yeah,
> I'm sure there's better devices out there. Spare me the sarcasm, but please do
> give a suggestion for better-supported hardware.) I have briefly been able to
> make this work: my phone has associated with an access point advertised by the
> TL-WN722N and accessed outside networks at wonderfully zippy WiFi speeds.
> Unfortunately, the AP functioned for a mere matter of minutes.
> 
> This has made me wonder whether the issue lies with netctl (the high-level
> network manager I'm using) or underlying software. Unfortunately, the latter
> appears to be the case. Merely bringing up the wireless interface with the `ip`
> utility causes gobs of nasty information to be printed to the system log.
> 
> You ask for a bit of information on the "Reporting_bugs" web page, and what
> follows is my best attempt to provide that information. Please let me know if
> there's anything else I can do to help diagnose or fix this issue. I'm modestly
> experienced with software engineering, Linux system administration and computer
> networking, and I am happy to learn more, but this is totally new to me.
> 
> Please CC me when replying. I am not subscribed to this mailing list.
> 
> device information
> ------------------
> 
> Trimmed output from `sudo bash -c 'lsusb -v'` is available here:
> http://www.ichimonji10.name/downloads/tl-wn722n-lsusb.txt
> 
> Device firmware is installed on the system.
> 
>     $ find /usr/lib/firmware -name '*9271*'
>     /usr/lib/firmware/ar9271.fw
>     /usr/lib/firmware/htc_9271.fw
> 
> software versions
> -----------------
> 
> Here you go:
> 
>     $ uname -a
>     Linux pine 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC
> 2014 x86_64 GNU/Linux
>     $ ip -V
>     ip utility, iproute2-ss141009
>     $ netctl --version
>     netctl version 1.9
> 
> command invocations and log output
> ----------------------------------
> 
> The system has three physical interfaces. enp2s0 is used as an external
> interface, and the internal interfaces are enp3s0 and wlp0s18f0u4.
> 
>     $ ip link show
>     1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state
> UNKNOWN mode DEFAULT group default
>         link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     2: enp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state
> DOWN mode DEFAULT group default qlen 1000
>         link/ether b8:97:5a:04:f4:c8 brd ff:ff:ff:ff:ff:ff
>     3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> fq_codel state UP mode DEFAULT group default qlen 1000
>         link/ether 68:05:ca:01:20:a0 brd ff:ff:ff:ff:ff:ff
>     6: wlp0s18f0u4: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN
> mode DEFAULT group default qlen 1000
>         link/ether e8:de:27:1a:31:a6 brd ff:ff:ff:ff:ff:ff
> 
> The wireless interface can successfully be brought up and down.
> 
>     $ sudo ip link set dev wlp0s18f0u4 up; echo $?
>     0
>     $ sudo ip link set dev wlp0s18f0u4 down; echo $?
>     0
> 
> I executed `iw event -t` before executing the `ip` commands above. It had
> nothing to say. I also executed `dmesg --follow > ~/tmp/dmesg.log` while
> executing the `ip` commands above, and it had lots to say:
> 
>     $ wc ~/tmp/dmesg.log
>     61391  385687 5337913 /home/ichimonji10/tmp/dmesg.log
> 
> `dmesg.log` is available here:
> http://www.ichimonji10.name/downloads/tl-wn722n-dmesg.txt
> 
> -Jeremy "Ichimonji10" Audet
> 
> [1] http://wireless.kernel.org/en/users/Drivers
> [2] http://wireless.kernel.org/en/users/Drivers/ath9k_htc
> [3] https://wiki.archlinux.org/index.php/Netctl
> --
> 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
> 


-- 
Regards,
Oleksij


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: bug report for ath9k_htc driver

[Jeremy Audet]

Hi Oleksij,

Sure thing. I cloned your ath9k-htc-firmware-blob repository and
copied the htc_9271.fw file to /usr/lib/firmware/. I then plugged in
the TL-WN722N USB adapter, brought up the wireless device with `sudo
ip link set dev wlp0s18f2u4 up; echo $?` (return code 0), and sat back
and waited. I did not interact with the machine beyond keeping open an
SSH session (via a wired interface) and watching the log file. About
five minutes later, a similar error occurred as described in my
previous email.

I've collected some logging output with the command `journalctl -k
--since=today`. You may find this log a bit more useful than the dmesg
log linked to in my previous email. You can find the log here:
http://www.ichimonji10.name/downloads/tl-wn722n-journalctl.txt

-Jeremy "Ichimonji10" Audet

Re: bug report for ath9k_htc driver

[Oleksij Rempel]

Am 23.12.2014 um 16:31 schrieb Jeremy Audet:
> Hi Oleksij,
> 
> Sure thing. I cloned your ath9k-htc-firmware-blob repository and
> copied the htc_9271.fw file to /usr/lib/firmware/. I then plugged in
> the TL-WN722N USB adapter, brought up the wireless device with `sudo
> ip link set dev wlp0s18f2u4 up; echo $?` (return code 0), and sat back
> and waited. I did not interact with the machine beyond keeping open an
> SSH session (via a wired interface) and watching the log file. About
> five minutes later, a similar error occurred as described in my
> previous email.
> 
> I've collected some logging output with the command `journalctl -k
> --since=today`. You may find this log a bit more useful than the dmesg
> log linked to in my previous email. You can find the log here:
> http://www.ichimonji10.name/downloads/tl-wn722n-journalctl.txt
> 
> -Jeremy "Ichimonji10" Audet
> 

So, at some point usb layer dropped connection, and reconnected in
full-speed mode, which is slow:
=================================================================
Dec 23 10:07:49 pine kernel: usb 5-4: USB disconnect, device number 9
Dec 23 10:07:49 pine kernel: ath: phy6: Failed to wakeup in 500us
Dec 23 10:07:50 pine kernel: ath: phy6: RX failed to go idle in 10 ms
RXSM=0xb063df84
Dec 23 10:07:50 pine kernel: ath: phy6: Failed to wakeup in 500us
Dec 23 10:07:50 pine kernel: usb 5-4: ath9k_htc: USB layer deinitialized
Dec 23 10:07:50 pine kernel: usb 5-4: new high-speed USB device number
10 using ehci-pci
Dec 23 10:07:51 pine kernel: usb 1-4: new full-speed USB device number 5
using ohci-pci
Dec 23 10:07:51 pine kernel: usb 1-4: not running at top speed; connect
to a high speed hub
Dec 23 10:07:51 pine kernel: usb 1-4: ath9k_htc: Firmware htc_9271.fw
requested
Dec 23 10:07:51 pine kernel: usb 1-4: ath9k_htc: Transferred FW:
htc_9271.fw, size: 51008
==================================================================

After reconnecting to fulls-speed, ath9k-htc was unusable. I would
suggest to test other cable or other usb controller.
With other words, I have no idea about the reason for initial
disconnection. It can be bad usb connection, noise or not enough power.

-- 
Regards,
Oleksij

Re: bug report for ath9k_htc driver

[Jeremy Audet]

> I would suggest to test other cable or other usb controller.
> With other words, I have no idea about the reason for initial
> disconnection. It can be bad usb connection, noise or not enough power.

Oh lordy. I connected the TL-WN722N directly to my computer, set up a
wireless access point and have been streaming music off of it for the
past 30 minutes with no issues. It appears that the issue was the USB
cradle [1] that shipped with the TL-WN722N. Thank you very much for
your help, and I'm sorry for having raised a false alarm.

-Jeremy "Ichimonji10" Audet

[1] http://www.newegg.com/Product/Product.aspx?Item=N82E16833997218

Re: bug report for ath9k_htc driver

[Jeremy Audet]

Sending this again b/c of a delivery error. [9] Sorry for the possible spam.

Hi again,

When last I wrote, I stated that the issue lay with the USB cradle I'd been
using, and I'd discarded it in favor of plugging the TL-WN722N directly in to
my PC. I also mentioned that I'd gotten a wireless access point up and running
for 30 minutes. Not five minutes after I sent that email, the same error I've
described earlier occurred, and the USB wireless adapter was demoted to
full-speed mode.

This is bothersome, so in an effort to rule out sources of error, I ran a series
of simple tests, all having this structure:

1. Start logging out kernel messages with the `journalctl -k --follow -n 0`
   command.
2. Plug a TP-LINK TL-WN722N wireless adapter directly in to a USB port.
3. Turn on the adapter with the `ip link set dev $device up` command.
4. Wait for an error.
5. Stop collecting logging output. (Send CTRL-C to `journalctl`.)
6. Unplug TL-WN722N.

Here's the purpose of the above:

* It is possible that a specific USB port or ports on my motherboard are flaky.
  To help rule this out, run the test with three different USB ports on my
  motherboard. Two of the ports are built directly in to the back panel of the
  motherboard, and the third connects to header pins on the motherboard.
* It is possible that the specific TL-WN722N I am using is flaky. To help rule
  this out, run the test with a second TL-WN722N. [1, 2]

Notably, I am also using the `htc_9271.fw` firmware file available at
https://github.com/olerem/ath9k-htc-firmware-blob for this test. As a refresher,
here's some other info about my system:

    $ uname -a
    Linux pine 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC
2014 x86_64 GNU/Linux
    $ ip -V
    ip utility, iproute2-ss141009

And here's some output from `lsusb -v` for the old and new TL-WN722N devices:

* old: http://www.ichimonji10.name/downloads/tl-wn722n-old-lsusb.txt
* new: http://www.ichimonji10.name/downloads/tl-wn722n-lsusb.txt

Here's the test results. Port 1, 2, and 3 are the upper back panel, lower back
panel and header pins on the motherboard, respectively.

* Port 1, old adapter: fail [3]
* Port 1, new adapter: fail [4]
* Port 2, old adapter: fail [5]
* Port 2, new adapter: fail [6]
* Port 3, old adapter: fail [7]
* Port 3, new adapter: fail [8]

[1] I bought a TL-WN722N several years ago, eventually stuck it in the bottom of
    my tool kit and forgot about it until just now. I bought the two TL-WN722Ns
    several years apart, so it is unlikely that the two adapters both suffer
    from e.g. a manufacturing defect. They were bought on 2014-11-10 and
    2012-09-25.
[2] lsusb -v: http://www.ichimonji10.name/downloads/tl-wn722n-old-lsusb.txt
[3] http://www.ichimonji10.name/downloads/2014-12-26-p1-old.txt
[4] http://www.ichimonji10.name/downloads/2014-12-26-p1-new.txt
[5] http://www.ichimonji10.name/downloads/2014-12-26-p2-old.txt
[6] http://www.ichimonji10.name/downloads/2014-12-26-p2-new.txt
[7] http://www.ichimonji10.name/downloads/2014-12-26-p3-old.txt
[8] http://www.ichimonji10.name/downloads/2014-12-26-p3-new.txt
[9] Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
server for the recipient domain vger.kernel.org by vger.kernel.org.
[...] The error that the other server returned was: 550 5.7.1
Content-Policy reject msg: The message contains HTML subpart,
therefore we consider it SPAM or Outlook Virus.  TEXT/PLAIN is
accepted.

Re: bug report for ath9k_htc driver

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 3974 bytes --]

I found this note with similar kernel log like yours:
http://www.linuxforums.org/forum/hardware-peripherals/195227-tl-wn722n-backtrack-5-a.html

Can you please test this workaround?

Am 27.12.2014 um 05:05 schrieb Jeremy Audet:
> Sending this again b/c of a delivery error. [9] Sorry for the possible spam.
> 
> Hi again,
> 
> When last I wrote, I stated that the issue lay with the USB cradle I'd been
> using, and I'd discarded it in favor of plugging the TL-WN722N directly in to
> my PC. I also mentioned that I'd gotten a wireless access point up and running
> for 30 minutes. Not five minutes after I sent that email, the same error I've
> described earlier occurred, and the USB wireless adapter was demoted to
> full-speed mode.
> 
> This is bothersome, so in an effort to rule out sources of error, I ran a series
> of simple tests, all having this structure:
> 
> 1. Start logging out kernel messages with the `journalctl -k --follow -n 0`
>    command.
> 2. Plug a TP-LINK TL-WN722N wireless adapter directly in to a USB port.
> 3. Turn on the adapter with the `ip link set dev $device up` command.
> 4. Wait for an error.
> 5. Stop collecting logging output. (Send CTRL-C to `journalctl`.)
> 6. Unplug TL-WN722N.
> 
> Here's the purpose of the above:
> 
> * It is possible that a specific USB port or ports on my motherboard are flaky.
>   To help rule this out, run the test with three different USB ports on my
>   motherboard. Two of the ports are built directly in to the back panel of the
>   motherboard, and the third connects to header pins on the motherboard.
> * It is possible that the specific TL-WN722N I am using is flaky. To help rule
>   this out, run the test with a second TL-WN722N. [1, 2]
> 
> Notably, I am also using the `htc_9271.fw` firmware file available at
> https://github.com/olerem/ath9k-htc-firmware-blob for this test. As a refresher,
> here's some other info about my system:
> 
>     $ uname -a
>     Linux pine 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC
> 2014 x86_64 GNU/Linux
>     $ ip -V
>     ip utility, iproute2-ss141009
> 
> And here's some output from `lsusb -v` for the old and new TL-WN722N devices:
> 
> * old: http://www.ichimonji10.name/downloads/tl-wn722n-old-lsusb.txt
> * new: http://www.ichimonji10.name/downloads/tl-wn722n-lsusb.txt
> 
> Here's the test results. Port 1, 2, and 3 are the upper back panel, lower back
> panel and header pins on the motherboard, respectively.
> 
> * Port 1, old adapter: fail [3]
> * Port 1, new adapter: fail [4]
> * Port 2, old adapter: fail [5]
> * Port 2, new adapter: fail [6]
> * Port 3, old adapter: fail [7]
> * Port 3, new adapter: fail [8]
> 
> [1] I bought a TL-WN722N several years ago, eventually stuck it in the bottom of
>     my tool kit and forgot about it until just now. I bought the two TL-WN722Ns
>     several years apart, so it is unlikely that the two adapters both suffer
>     from e.g. a manufacturing defect. They were bought on 2014-11-10 and
>     2012-09-25.
> [2] lsusb -v: http://www.ichimonji10.name/downloads/tl-wn722n-old-lsusb.txt
> [3] http://www.ichimonji10.name/downloads/2014-12-26-p1-old.txt
> [4] http://www.ichimonji10.name/downloads/2014-12-26-p1-new.txt
> [5] http://www.ichimonji10.name/downloads/2014-12-26-p2-old.txt
> [6] http://www.ichimonji10.name/downloads/2014-12-26-p2-new.txt
> [7] http://www.ichimonji10.name/downloads/2014-12-26-p3-old.txt
> [8] http://www.ichimonji10.name/downloads/2014-12-26-p3-new.txt
> [9] Technical details of permanent failure:
> Google tried to deliver your message, but it was rejected by the
> server for the recipient domain vger.kernel.org by vger.kernel.org.
> [...] The error that the other server returned was: 550 5.7.1
> Content-Policy reject msg: The message contains HTML subpart,
> therefore we consider it SPAM or Outlook Virus.  TEXT/PLAIN is
> accepted.
> 


-- 
Regards,
Oleksij


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: bug report for ath9k_htc driver

[Jeremy Audet]

Yes, I will test that workaround. It'll be a few days before I can
report back with any results: I just bought a cheap USB hub from
newegg, so I will have to wait for it to arrive and make time to test
the item when it does arrive. But I'll definitely test the workaround.
Bug me if I haven't responded within two weeks.

—Jeremy 'Ichimonji10' Audet

Re: bug report for ath9k_htc driver

[Jeremy Audet]

Grr. I'm sending this again. My first email was filtered by kernel
mailing list due to the presence of HTML in the message.

Hi again,

The USB hub has arrived. [1] I ran through the same test procedure as last time:

1. Start collecting logging info with `journalctl -k --follow -n 0`.
2. Plug in the hub, if appropriate. Plug in the TL-WN722N.
3. Bring up the adapter with `ip link set dev $device up`.
4. Wait for an error.

My test system has changed slightly since I last ran this test, so I
made sure to run the test twice: once without a USB hub, and once with
a USB hub. When I ran this test without the USB hub, the kernel
immediately emitted gobs of messages and the TL-WN722N was immediately
demoted to a full-speed device. I didn't even have a chance to bring
up the device with `ip link set dev $device up`. [2] When I ran this
test with a USB hub, the kernel did eventually emit gobs of messages,
but lead-up to that failure did contain some new error messages.

I mentioned that my test system has changed. In particular, I've added
a new PCI wireless adapter to the system. [4] I've also installed some
updates, but it is worth noting that the software listed in my
original email has not changed:

    $ uname -a
    Linux pine 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC
2014 x86_64 GNU/Linux
    $ ip -V
    ip utility, iproute2-ss141009
    $ netctl --version
    netctl version 1.9

—Jeremy 'Ichimonji10' Audet

[1] http://i.imgur.com/TdlwxIC.jpg
[2] http://www.ichimonji10.name/downloads/2015-01-13-p3-new-nohub.txt
[3] http://www.ichimonji10.name/downloads/2015-01-13-p3-new-hub.txt
[4] Output from lspci -v:
04:05.0 Network controller: Ralink corp. RT3060 Wireless 802.11n 1T/1R
        Subsystem: Edimax Computer Co. Device 7711
        Flags: bus master, slow devsel, latency 32, IRQ 20
        Memory at fe900000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: rt2800pci
        Kernel modules: rt2800pci

Re: bug report for ath9k_htc driver

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]

Am 13.01.2015 um 23:46 schrieb Jeremy Audet:
> Grr. I'm sending this again. My first email was filtered by kernel
> mailing list due to the presence of HTML in the message.
> 
> Hi again,
> 
> The USB hub has arrived. [1] I ran through the same test procedure as last time:
> 
> 1. Start collecting logging info with `journalctl -k --follow -n 0`.
> 2. Plug in the hub, if appropriate. Plug in the TL-WN722N.
> 3. Bring up the adapter with `ip link set dev $device up`.
> 4. Wait for an error.
> 
> My test system has changed slightly since I last ran this test, so I
> made sure to run the test twice: once without a USB hub, and once with
> a USB hub. When I ran this test without the USB hub, the kernel
> immediately emitted gobs of messages and the TL-WN722N was immediately
> demoted to a full-speed device. I didn't even have a chance to bring
> up the device with `ip link set dev $device up`. [2] When I ran this
> test with a USB hub, the kernel did eventually emit gobs of messages,
> but lead-up to that failure did contain some new error messages.
> 
> I mentioned that my test system has changed. In particular, I've added
> a new PCI wireless adapter to the system. [4] I've also installed some
> updates, but it is worth noting that the software listed in my
> original email has not changed:
> 
>     $ uname -a
>     Linux pine 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC
> 2014 x86_64 GNU/Linux
>     $ ip -V
>     ip utility, iproute2-ss141009
>     $ netctl --version
>     netctl version 1.9
> 
> —Jeremy 'Ichimonji10' Audet
> 
> [1] http://i.imgur.com/TdlwxIC.jpg
> [2] http://www.ichimonji10.name/downloads/2015-01-13-p3-new-nohub.txt
> [3] http://www.ichimonji10.name/downloads/2015-01-13-p3-new-hub.txt
> [4] Output from lspci -v:
> 04:05.0 Network controller: Ralink corp. RT3060 Wireless 802.11n 1T/1R
>         Subsystem: Edimax Computer Co. Device 7711
>         Flags: bus master, slow devsel, latency 32, IRQ 20
>         Memory at fe900000 (32-bit, non-prefetchable) [size=64K]
>         Capabilities: <access denied>
>         Kernel driver in use: rt2800pci
>         Kernel modules: rt2800pci
> --
> 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
> 


Looks like with the hub it can work at least some hours. Correct?

Lets try to reduce interrupt traffic on usb by disabling led blinking
with this command:
sudo bash -c "echo none > /sys/class/leds/ath9k_htc-phy*/trigger"

-- 
Regards,
Oleksij


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: bug report for ath9k_htc driver

[Jeremy Audet]

Gaaaaah! Damn it, gmail. I'm sending this email again. The first copy
of this email was rejected by the ML's spam filter, due to the
presence of an HTML part. I'm sorry for spamming y'all.

> Looks like with the hub it can work at least some hours. Correct?

There was an ~18 hour timespan between when the device was physically
plugged in and when freaky error messages were dumped to the kernel
log, so that's good. However, it's worth noting the device wasn't
really "available" that entire time. The kernel log shows that the
device appears to be physically disconnected and reconnected five or
six times in that timespan. (The device remained physically
untouched.) The device is set up as a high-speed USB device again
after each disconnect, which is good, but those disconnects shouldn't
happen in the first place.

I'm doing as you've suggested:

1. Start collecting log messages with `journalctl -k --follow -n 0 >
mylogfile.txt`
2. Plug in USB hub.
3. Plug in TL-WN722N.
4. Execute `sudo bash -c 'echo none > /sys/class/leds/ath9k_htc-phy11/trigger'`
5. `sudo ip link set dev wlp0s19f2u4u2 up`
6. Wait.

I'm currently on step six. I'll post an update when appropriate.

—Jeremy 'Ichimonji10' Audet

Re: bug report for ath9k_htc driver

[Jeremy Audet]

No luck. [1] For what it's worth, the TL-WN722N's LEDs did not light
up after executing `ip link set dev $device up`, so I am pretty sure
that the `echo none > ...` command worked. I do see that version 1.4
of the firmware may be released. [2] I can build and install the
firmware and see what happens. Is that worth doing? I'm not 100% which
firmware version is provided by your repo. [3]

[1] http://www.ichimonji10.name/downloads/2015-01-18.txt
[2] https://github.com/qca/open-ath9k-htc-firmware/issues/65
[3] https://github.com/olerem/ath9k-htc-firmware-blob

—Jeremy 'Ichimonji10' Audet

Re: bug report for ath9k_htc driver

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

Am 19.01.2015 um 02:31 schrieb Jeremy Audet:
> No luck. [1] For what it's worth, the TL-WN722N's LEDs did not light
> up after executing `ip link set dev $device up`, so I am pretty sure
> that the `echo none > ...` command worked. I do see that version 1.4
> of the firmware may be released. [2] I can build and install the
> firmware and see what happens. Is that worth doing? I'm not 100% which
> firmware version is provided by your repo. [3]
> 
> [1] http://www.ichimonji10.name/downloads/2015-01-18.txt
> [2] https://github.com/qca/open-ath9k-htc-firmware/issues/65
> [3] https://github.com/olerem/ath9k-htc-firmware-blob
> 
> —Jeremy 'Ichimonji10' Audet
> 

my repo[3] provides latest git build. There is no need to build own FW.

According to the bug which you get, you should update FW:
WARNING: CPU: 1 PID: 559 at drivers/usb/core/urb.c:450
usb_submit_urb+0x265/0x5f0 [usbcore]()
usb 2-4.2: BOGUS urb xfer, pipe 1 != type 3

This part of the log, means: FW restarted with other usb setting which
are not compatible with settings used by kernel. This issue was fixed
for one or two ears in 1.4.

-- 
Regards,
Oleksij


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: bug report for ath9k_htc driver

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

Am 19.01.2015 um 01:35 schrieb Jeremy Audet:
> Gaaaaah! Damn it, gmail. I'm sending this email again. The first copy
> of this email was rejected by the ML's spam filter, due to the
> presence of an HTML part. I'm sorry for spamming y'all.
> 
>> Looks like with the hub it can work at least some hours. Correct?
> 
> There was an ~18 hour timespan between when the device was physically
> plugged in and when freaky error messages were dumped to the kernel
> log, so that's good. However, it's worth noting the device wasn't
> really "available" that entire time. The kernel log shows that the
> device appears to be physically disconnected and reconnected five or
> six times in that timespan. (The device remained physically
> untouched.) The device is set up as a high-speed USB device again
> after each disconnect, which is good, but those disconnects shouldn't
> happen in the first place.

There is one HW or FW not fixed issue which may cause FW restarts, but
proper restarting was introduced by 1.4. And, if FW triggered a restart
you will get something like this:
> [ 3501.052975] usb 1-2: ath: firmware panic! exccause: 0x0000000d; pc:
> 0x0090a641; badvaddr: 0x12345678.

> I'm doing as you've suggested:
> 
> 1. Start collecting log messages with `journalctl -k --follow -n 0 >
> mylogfile.txt`
> 2. Plug in USB hub.
> 3. Plug in TL-WN722N.
> 4. Execute `sudo bash -c 'echo none > /sys/class/leds/ath9k_htc-phy11/trigger'`
> 5. `sudo ip link set dev wlp0s19f2u4u2 up`
> 6. Wait.
> 
> I'm currently on step six. I'll post an update when appropriate.

This means, we may have some usb protocol related issue. Without proper
investigation i can't say what is happening. Currently we can find some
more or less good workaround (or dirty hack :D).

-- 
Regards,
Oleksij


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]