All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksij Rempel <linux@rempel-privat.de>
To: Alan Stern <stern@rowland.harvard.edu>,
	Anders Darander <anders.darander@gmail.com>
Cc: linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org,
	ath9k-devel@qca.qualcomm.com
Subject: Re: ath9k -> bogus usb xfer on at91
Date: Fri, 04 Jul 2014 18:54:55 +0200	[thread overview]
Message-ID: <53B6DC5F.3090304@rempel-privat.de> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1407041225290.6607-100000@netrider.rowland.org>

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

Am 04.07.2014 18:30, schrieb Alan Stern:
> On Fri, 4 Jul 2014, Anders Darander wrote:
> 
>> Hi,
>>
>> While porting an internal BSP (a design based on a at91sam9g20 SoC)
>> from 3.10 to 3.14, I got flooded with messages like:
>>
>> ~# usb 1-1: new full-speed USB device number 3 using at91_ohci
>> usb 1-1: ath9k_htc: Firmware htc_9271.fw requested
>> usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
>> -----------[ cut here ]-----------
>> WARNING: CPU: 0 PID: 93 at
>> /mnt/cs-builds/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/linux-yocto-ccu/3.14+gitAUTOINC+7b03bd3dfd-r0/linux/drivers/usb/core/urb.c:450
>> usb_submit_urb+0x2ac/0x460()
>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>> Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mac80211
>> cfg80211 ccudrv(O) at91_disable_wdt(O) at91_bootcount(O) at91_adc(O)
>> CPU: 0 PID: 93 Comm: kworker/0:3 Tainted: G W O 3.14.10-ccu #2
>> Workqueue: events request_firmware_work_func
>> [<c000d354>] (unwind_backtrace) from [<c000bb74>] (show_stack+0x10/0x14)
>> [<c000bb74>] (show_stack) from [<c00155ac>] (warn_slowpath_common+0x60/0x80)
>> [<c00155ac>] (warn_slowpath_common) from [<c00155f8>]
>> (warn_slowpath_fmt+0x2c/0x3c)
>> [<c00155f8>] (warn_slowpath_fmt) from [<c01d9c14>] (usb_submit_urb+0x2ac/0x460)
>> [<c01d9c14>] (usb_submit_urb) from [<bf134e28>]
>> (hif_usb_send+0x268/0x2c8 [ath9k_htc])
>> [<bf134e28>] (hif_usb_send [ath9k_htc]) from [<bf133064>]
>> (htc_issue_send.constprop.4+0x64/0x68 [ath9k_htc])
>> [<bf133064>] (htc_issue_send.constprop.4 [ath9k_htc]) from
>> [<bf133354>] (htc_connect_service+0x170/0x1c8 [ath9k_htc])
>> [<bf133354>] (htc_connect_service [ath9k_htc]) from [<bf135484>]
>> (ath9k_wmi_connect+0x50/0x6c [ath9k_htc])
>> [<bf135484>] (ath9k_wmi_connect [ath9k_htc]) from [<bf13b2e0>]
>> (ath9k_init_htc_services.isra.10+0x20/0x280 [ath9k_htc])
>> [<bf13b2e0>] (ath9k_init_htc_services.isra.10 [ath9k_htc]) from
>> [<bf13b744>] (ath9k_htc_probe_device+0xe4/0x928 [ath9k_htc])
>> [<bf13b744>] (ath9k_htc_probe_device [ath9k_htc]) from [<bf13374c>]
>> (ath9k_htc_hw_init+0x10/0x30 [ath9k_htc])
>> [<bf13374c>] (ath9k_htc_hw_init [ath9k_htc]) from [<bf1345e0>]
>> (ath9k_hif_usb_firmware_cb+0x4cc/0x5c8 [ath9k_htc])
>> [<bf1345e0>] (ath9k_hif_usb_firmware_cb [ath9k_htc]) from [<c018993c>]
>> (request_firmware_work_func+0x2c/0x4c)
>> [<c018993c>] (request_firmware_work_func) from [<c0026bd0>]
>> (process_one_work+0x20c/0x33c)
>> [<c0026bd0>] (process_one_work) from [<c002774c>] (worker_thread+0x234/0x384)
>> [<c002774c>] (worker_thread) from [<c002bea0>] (kthread+0xc0/0xd4)
>> [<c002bea0>] (kthread) from [<c00094d0>] (ret_from_fork+0x14/0x24)
>> --[ end trace b92d2c3cd165cd68 ]--
>> -----------[ cut here ]-----------
> 
> I can't tell exactly where the fault is, but this message means that an
> URB was submitted for a bulk endpoint with a pipe of type
> PIPE_INTERRUPT.

Then kernel driver and firmware should be updated. There was some
Bulk/Interrupt issues which was fixed last year.

I hope this HW will not be used as AP.

>> After temporarily reverting commit
>> 3482528e9aced9234d4e2a4a9538c882a9aa5aa2, which enables debug checks
>> on all USB urb's (previously is was only enabled for a
>> CONFIG_USB_DEBUG enabled kernel), the WiFi chip starts to work
>> correctly. The chip in question is a ar9721.
>>
>>  The same USB stick works without these messages on my laptop; while
>> another USB stick, based on an rtl8187 chip, works without these
>> messages on the target system (at91sam9g20)
>>
>> Any pointers to what it could be? Or suggestions on how to attack the issue?
> 
> Fix the URB submission to use the correct pipe type.
> 
> Alan Stern
> 
> --
> 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: 278 bytes --]

  reply	other threads:[~2014-07-04 16:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04 13:32 ath9k -> bogus usb xfer on at91 Anders Darander
2014-07-04 13:58 ` Oleksij Rempel
2014-07-04 16:30 ` Alan Stern
2014-07-04 16:54   ` Oleksij Rempel [this message]
2014-07-07 13:40     ` Anders Darander
2014-07-07 15:08       ` Oleksij Rempel
2014-07-08  5:53         ` Oleksij Rempel
2014-07-09 11:49         ` Anders Darander
2014-07-07 13:42   ` Anders Darander
  -- strict thread matches above, loose matches on Subject: below --
2014-11-26  0:28 David Lechner
2014-11-26 18:29 ` Oleksij Rempel
2014-11-26 18:54   ` David Lechner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53B6DC5F.3090304@rempel-privat.de \
    --to=linux@rempel-privat.de \
    --cc=anders.darander@gmail.com \
    --cc=ath9k-devel@qca.qualcomm.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.