Hi,
I have some problem with the AR6004 (hw 1.3) initialisation.
I'm using the compat wireless 3.6.6-1 package, with the ath6kl driver from
https://github.com/kvalo/ath6kl.git. (master branch)
The device seems not to respond after the firmware upload.
"ath6kl: htc_wait_recv_ctrl_message: Timeout!"
Increasing the timeout doesn't help.
Here is the log at startup.
http://pastebin.com/DsivqdDP
If I unplug and re-plug the adapter, every thing is going well.
http://pastebin.com/BTz0w5QL.
Any Idea on how to fix or workaround this issue ?
(I've also tried the recovery options recovery_enable=1 heart_beat_poll=200)
Regards,
Julien
Hi Julien,
Julien Massot <[email protected]> writes:
> I have some problem with the AR6004 (hw 1.3) initialisation.
Just to be clear I think a problem with USB code/hardware, most likely
SDIO doesn't have this issue.
> I'm using the compat wireless 3.6.6-1 package, with the ath6kl driver from
> https://github.com/kvalo/ath6kl.git. (master branch)
>
> The device seems not to respond after the firmware upload.
> "ath6kl: htc_wait_recv_ctrl_message: Timeout!"
> Increasing the timeout doesn't help.
> Here is the log at startup.
> http://pastebin.com/DsivqdDP
>
> If I unplug and re-plug the adapter, every thing is going well.
> http://pastebin.com/BTz0w5QL.
Finally I got working USB boards again and I see the same thing:
Dec 13 01:43:21 x201 kernel: [ 24.843691] ath6kl: Failed to start hardware: -5
Dec 13 01:43:21 x201 kernel: [ 24.843781] ath6kl: Failed to init ath6kl core: -5
Dec 13 01:43:21 x201 kernel: [ 24.843849] ath6kl_usb: probe of 2-1.2:1.0 failed with error -5
> Any Idea on how to fix or workaround this issue ?
I remember seeing a test patch which did some low level reset on the
hardware. I need to dig that up and see if it helps.
Also adding delay to various places would be good to test, in case
hardware needs some time to initialise itself.
> (I've also tried the recovery options recovery_enable=1 heart_beat_poll=200)
I doubt this helps as we are not even able to upload the firmware.
Kalle
Hi Kalle
> IIRC you mentioned on IRC that you don't see this anymore, is that
> correct?
I still have the problem on a reboot, but the device initialize itself
properly after a normal boot.
It's still a problem for me, I obtain exactly the same log.
ath6kl: Failed to start hardware: -5
Dec 13 01:43:21 x201 kernel: [ 24.843781] ath6kl: Failed to init
ath6kl core: -5
Dec 13 01:43:21 x201 kernel: [ 24.843849] ath6kl_usb: probe of
2-1.2:1.0 failed with error -5
If you need to test anything don't hesitate to request me.
Regards,
--
Julien
Larry Finger <[email protected]> writes:
> On 02/21/2013 08:03 AM, Julien Massot wrote:
>> Hi,
>> I just find a quick and dirty patch to workaround this issue.
>> I just reset the device on initialization failure.
>>
>> I hope this helps to understand the real issue.
>>
[...]
> I am certain that the real problem here is that ath6kl is requesting
> firmware with a synchronous call using request_firmware() rather than
> with the asynchronous request_firmware_nowait(). That used to work,
> but updates to udev caused the firmware read operation to time out. It
> works after a reset because the file reading routines are now running;
> however, the correct fix is to rewrite the firmware reading section.
I haven't looked at all the details yet, but AFAIK this is about cold vs
warm booting the chip. When rebooting the host while maintaining the
power to ar6004 ("warm boot") ath6kl probe fails as the chip is in odd
state and needs to be reset. It's not about dowloading the firmware
image from user space, it's about starting the firmware inside the chip.
And besides, didn't udev finally fix that (after some "feedback" from
Linus) so that we don't need to change all the drivers?
--
Kalle Valo
Kalle Valo <kvalo@...> writes:
>
> Larry Finger <Larry.Finger@...> writes:
>
> > On 02/21/2013 08:03 AM, Julien Massot wrote:
> >> Hi,
> >> I just find a quick and dirty patch to workaround this issue.
> >> I just reset the device on initialization failure.
> >>
> >> I hope this helps to understand the real issue.
> >>
>
> [...]
>
> > I am certain that the real problem here is that ath6kl is requesting
> > firmware with a synchronous call using request_firmware() rather than
> > with the asynchronous request_firmware_nowait(). That used to work,
> > but updates to udev caused the firmware read operation to time out. It
> > works after a reset because the file reading routines are now running;
> > however, the correct fix is to rewrite the firmware reading section.
>
> I haven't looked at all the details yet, but AFAIK this is about cold vs
> warm booting the chip. When rebooting the host while maintaining the
> power to ar6004 ("warm boot") ath6kl probe fails as the chip is in odd
> state and needs to be reset. It's not about dowloading the firmware
> image from user space, it's about starting the firmware inside the chip.
>
> And besides, didn't udev finally fix that (after some "feedback" from
> Linus) so that we don't need to change all the drivers?
>
Hi,
I'm having the exact same problem than Julien, (my kernel log are _exactly_ the
same than his).
A difference on the behavior: the problem is not on reboot, it's always present
(normal boot and reboot...).
But the "quick fix" witch consist in adding "reset_device" doesn't work, it just
goes into a loop (hardware_init fail->reset device->hardware_init fail->...)
Main difference is the linux system:
the architecture is ARM9 (armv4) with a buildroot system and kernel 3.6.7
note: hardware USB port is usb_v1.1 only.
I've tried ath6kl drivers from the kernel and the one from compat-
driver_next(2013-02-20)
=>same result.
The wireless USB dongle is working properly on my linux computer with the same
compat-driver and same firmware files, so it shouldn't have hardware problem
Another wireless dongle based on RALINK chipset is working properly on my ARM
system, so this shouldn't be an hardware problem from the board.
Any clue?
KR,
Yvan.
On 02/21/2013 08:03 AM, Julien Massot wrote:
> Hi,
> I just find a quick and dirty patch to workaround this issue.
> I just reset the device on initialization failure.
>
> I hope this helps to understand the real issue.
>
> [ 7.012514] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/bdata.bin
> [ 7.035276] cfg80211: World regulatory domain updated:
> [ 7.035287] cfg80211: (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [ 7.035299] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
> (300 mBi, 2000 mBm)
> [ 7.037916] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/fw-3.bin
> [ 9.378940] ath6kl: f59afe4c
> [ 9.379054] ath6kl: f59afe6c
> [ 9.379391] ath6kl_usb: probe of 1-7:1.0 failed with error -5
> Here I reset the device.
>
> [ 9.380081] usbcore: registered new interface driver ath6kl_usb
> [ 10.396824] usb 1-7: USB disconnect, address 7
> [ 10.712160] usb 1-7: new high speed USB device using ehci_hcd and address 8
> [ 10.832491] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/bdata.bin
> [ 10.838218] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/fw-3.bin
> [ 11.026652] ath6kl: f5287c50
>
> and it works..
>
> ---
> drivers/net/wireless/ath/ath6kl/main.c | 1 +
> drivers/net/wireless/ath/ath6kl/usb.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath6kl/main.c
> b/drivers/net/wireless/ath/ath6kl/main.c
> index d0080b3..9060380 100644
> --- a/drivers/net/wireless/ath/ath6kl/main.c
> +++ b/drivers/net/wireless/ath/ath6kl/main.c
> @@ -375,6 +375,7 @@ void ath6kl_reset_device(struct ath6kl *ar, u32 target_type,
> if (status)
> ath6kl_err("failed to reset target\n");
> }
> +EXPORT_SYMBOL(ath6kl_reset_device);
>
> static void ath6kl_install_static_wep_keys(struct ath6kl_vif *vif)
> {
> diff --git a/drivers/net/wireless/ath/ath6kl/usb.c
> b/drivers/net/wireless/ath/ath6kl/usb.c
> index c7b87be..910bef9 100644
> --- a/drivers/net/wireless/ath/ath6kl/usb.c
> +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> @@ -1121,6 +1121,7 @@ static int ath6kl_usb_probe(struct usb_interface
> *interface,
> ret = ath6kl_core_init(ar, ATH6KL_HTC_TYPE_PIPE);
> if (ret) {
> ath6kl_err("Failed to init ath6kl core: %d\n", ret);
> + ath6kl_reset_device(ar, ar->target_type, true, true);
> goto err_core_free;
> }
>
> --
I am certain that the real problem here is that ath6kl is requesting firmware
with a synchronous call using request_firmware() rather than with the
asynchronous request_firmware_nowait(). That used to work, but updates to udev
caused the firmware read operation to time out. It works after a reset because
the file reading routines are now running; however, the correct fix is to
rewrite the firmware reading section.
Larry
On 02/25/2013 11:19 AM, Yvan wrote:
> Kalle Valo <kvalo@...> writes:
>
>>
>> Larry Finger <Larry.Finger@...> writes:
>>
>>> On 02/21/2013 08:03 AM, Julien Massot wrote:
>>>> Hi,
>>>> I just find a quick and dirty patch to workaround this issue.
>>>> I just reset the device on initialization failure.
>>>>
>>>> I hope this helps to understand the real issue.
>>>>
>>
>> [...]
>>
>>> I am certain that the real problem here is that ath6kl is requesting
>>> firmware with a synchronous call using request_firmware() rather than
>>> with the asynchronous request_firmware_nowait(). That used to work,
>>> but updates to udev caused the firmware read operation to time out. It
>>> works after a reset because the file reading routines are now running;
>>> however, the correct fix is to rewrite the firmware reading section.
>>
>> I haven't looked at all the details yet, but AFAIK this is about cold vs
>> warm booting the chip. When rebooting the host while maintaining the
>> power to ar6004 ("warm boot") ath6kl probe fails as the chip is in odd
>> state and needs to be reset. It's not about dowloading the firmware
>> image from user space, it's about starting the firmware inside the chip.
>>
>> And besides, didn't udev finally fix that (after some "feedback" from
>> Linus) so that we don't need to change all the drivers?
>>
>
> Hi,
>
> I'm having the exact same problem than Julien, (my kernel log are _exactly_ the
> same than his).
>
> A difference on the behavior: the problem is not on reboot, it's always present
> (normal boot and reboot...).
>
> But the "quick fix" witch consist in adding "reset_device" doesn't work, it just
> goes into a loop (hardware_init fail->reset device->hardware_init fail->...)
>
> Main difference is the linux system:
> the architecture is ARM9 (armv4) with a buildroot system and kernel 3.6.7
> note: hardware USB port is usb_v1.1 only.
>
> I've tried ath6kl drivers from the kernel and the one from compat-
> driver_next(2013-02-20)
> =>same result.
>
> The wireless USB dongle is working properly on my linux computer with the same
> compat-driver and same firmware files, so it shouldn't have hardware problem
>
> Another wireless dongle based on RALINK chipset is working properly on my ARM
> system, so this shouldn't be an hardware problem from the board.
Does 'modprobe -rv ath6kl' followed by 'modprobe -r ath6kl' make it work? If so,
then my idea about firmware loading might be correct. If not, then the problem
is somewhere else.
Larry
On 02/26/2013 02:17 AM, [email protected] wrote:
> Thank's for the quick answer!
> I don't use modprobe, I use insmod/rmmod.
> Loading/unloading the module doesn't change anything.
> I tried multiple combination of physicaly connecting/disconnecting the dongle
> and loading/unloading the modules, never got it working.
As modprobe uses insmod/rmmod for its heavy lifting, you are doing essentially
the same thing. It seems that the chip has some other problem. As I know nothing
about it, I cannot help.
Larry
Hi,
I just find a quick and dirty patch to workaround this issue.
I just reset the device on initialization failure.
I hope this helps to understand the real issue.
[ 7.012514] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/bdata.bin
[ 7.035276] cfg80211: World regulatory domain updated:
[ 7.035287] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 7.035299] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 7.037916] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/fw-3.bin
[ 9.378940] ath6kl: f59afe4c
[ 9.379054] ath6kl: f59afe6c
[ 9.379391] ath6kl_usb: probe of 1-7:1.0 failed with error -5
Here I reset the device.
[ 9.380081] usbcore: registered new interface driver ath6kl_usb
[ 10.396824] usb 1-7: USB disconnect, address 7
[ 10.712160] usb 1-7: new high speed USB device using ehci_hcd and address 8
[ 10.832491] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/bdata.bin
[ 10.838218] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/fw-3.bin
[ 11.026652] ath6kl: f5287c50
and it works..
---
drivers/net/wireless/ath/ath6kl/main.c | 1 +
drivers/net/wireless/ath/ath6kl/usb.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath6kl/main.c
b/drivers/net/wireless/ath/ath6kl/main.c
index d0080b3..9060380 100644
--- a/drivers/net/wireless/ath/ath6kl/main.c
+++ b/drivers/net/wireless/ath/ath6kl/main.c
@@ -375,6 +375,7 @@ void ath6kl_reset_device(struct ath6kl *ar, u32 target_type,
if (status)
ath6kl_err("failed to reset target\n");
}
+EXPORT_SYMBOL(ath6kl_reset_device);
static void ath6kl_install_static_wep_keys(struct ath6kl_vif *vif)
{
diff --git a/drivers/net/wireless/ath/ath6kl/usb.c
b/drivers/net/wireless/ath/ath6kl/usb.c
index c7b87be..910bef9 100644
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@ -1121,6 +1121,7 @@ static int ath6kl_usb_probe(struct usb_interface
*interface,
ret = ath6kl_core_init(ar, ATH6KL_HTC_TYPE_PIPE);
if (ret) {
ath6kl_err("Failed to init ath6kl core: %d\n", ret);
+ ath6kl_reset_device(ar, ar->target_type, true, true);
goto err_core_free;
}
--
Regards,
Julien
Hi Julien,
On 02/21/2013 07:33 PM, Julien Massot wrote:
> Hi,
> I just find a quick and dirty patch to workaround this issue.
> I just reset the device on initialization failure.
>
> I hope this helps to understand the real issue.
>
> [ 7.012514] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/bdata.bin
> [ 7.035276] cfg80211: World regulatory domain updated:
> [ 7.035287] cfg80211: (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [ 7.035299] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
> (300 mBi, 2000 mBm)
> [ 7.037916] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/fw-3.bin
> [ 9.378940] ath6kl: f59afe4c
> [ 9.379054] ath6kl: f59afe6c
> [ 9.379391] ath6kl_usb: probe of 1-7:1.0 failed with error -5
> Here I reset the device.
that was the suggestion gave by Wei. The failure it seems
check hostapp area to check target status and reset the device
if needed.
Great that you figured it out yourself!
We will send a proper patch for this.
>
> [ 9.380081] usbcore: registered new interface driver ath6kl_usb
> [ 10.396824] usb 1-7: USB disconnect, address 7
> [ 10.712160] usb 1-7: new high speed USB device using ehci_hcd and address 8
> [ 10.832491] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/bdata.bin
> [ 10.838218] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/fw-3.bin
> [ 11.026652] ath6kl: f5287c50
>
> and it works..
>
> ---
> drivers/net/wireless/ath/ath6kl/main.c | 1 +
> drivers/net/wireless/ath/ath6kl/usb.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath6kl/main.c
> b/drivers/net/wireless/ath/ath6kl/main.c
> index d0080b3..9060380 100644
> --- a/drivers/net/wireless/ath/ath6kl/main.c
> +++ b/drivers/net/wireless/ath/ath6kl/main.c
> @@ -375,6 +375,7 @@ void ath6kl_reset_device(struct ath6kl *ar, u32 target_type,
> if (status)
> ath6kl_err("failed to reset target\n");
> }
> +EXPORT_SYMBOL(ath6kl_reset_device);
>
> static void ath6kl_install_static_wep_keys(struct ath6kl_vif *vif)
> {
> diff --git a/drivers/net/wireless/ath/ath6kl/usb.c
> b/drivers/net/wireless/ath/ath6kl/usb.c
> index c7b87be..910bef9 100644
> --- a/drivers/net/wireless/ath/ath6kl/usb.c
> +++ b/drivers/net/wireless/ath/ath6kl/usb.c
> @@ -1121,6 +1121,7 @@ static int ath6kl_usb_probe(struct usb_interface
> *interface,
> ret = ath6kl_core_init(ar, ATH6KL_HTC_TYPE_PIPE);
> if (ret) {
> ath6kl_err("Failed to init ath6kl core: %d\n", ret);
> + ath6kl_reset_device(ar, ar->target_type, true, true);
> goto err_core_free;
> }
>
> --
> Regards,
> Julien
>
--
thanks,
shafi
Hi,
On 02/15/2013 07:40 PM, Julien Massot wrote:
> Hi Kalle
>
>> IIRC you mentioned on IRC that you don't see this anymore, is that
>> correct?
>
> I still have the problem on a reboot, but the device initialize itself
> properly after a normal boot.
>
> It's still a problem for me, I obtain exactly the same log.
> ath6kl: Failed to start hardware: -5
> Dec 13 01:43:21 x201 kernel: [ 24.843781] ath6kl: Failed to init
> ath6kl core: -5
> Dec 13 01:43:21 x201 kernel: [ 24.843849] ath6kl_usb: probe of
> 2-1.2:1.0 failed with error -5
In x86 I remember this issue can be seen, I will try to take
a look at this by finding some time :)
>
> If you need to test anything don't hesitate to request me.
>
>
--
thanks,
shafi
Hi Julien,
sorry for taking so long to get back to you.
Julien Massot <[email protected]> writes:
> I have some problem with the AR6004 (hw 1.3) initialisation.
> I'm using the compat wireless 3.6.6-1 package, with the ath6kl driver from
> https://github.com/kvalo/ath6kl.git. (master branch)
>
> The device seems not to respond after the firmware upload.
> "ath6kl: htc_wait_recv_ctrl_message: Timeout!"
> Increasing the timeout doesn't help.
> Here is the log at startup.
> http://pastebin.com/DsivqdDP
>
> If I unplug and re-plug the adapter, every thing is going well.
> http://pastebin.com/BTz0w5QL.
>
> Any Idea on how to fix or workaround this issue ?
>
> (I've also tried the recovery options recovery_enable=1 heart_beat_poll=200)
IIRC you mentioned on IRC that you don't see this anymore, is that
correct?
--
Kalle Valo
Mohammed Shafi Shajakhan <[email protected]> writes:
> Hi Julien,
>
> On 02/21/2013 07:33 PM, Julien Massot wrote:
>> Hi,
>> I just find a quick and dirty patch to workaround this issue.
>> I just reset the device on initialization failure.
>>
>> I hope this helps to understand the real issue.
>>
>> [ 7.012514] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/bdata.bin
>> [ 7.035276] cfg80211: World regulatory domain updated:
>> [ 7.035287] cfg80211: (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [ 7.035299] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
>> (300 mBi, 2000 mBm)
>> [ 7.037916] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/fw-3.bin
>> [ 9.378940] ath6kl: f59afe4c
>> [ 9.379054] ath6kl: f59afe6c
>> [ 9.379391] ath6kl_usb: probe of 1-7:1.0 failed with error -5
>> Here I reset the device.
>
> that was the suggestion gave by Wei. The failure it seems
> check hostapp area to check target status and reset the device
> if needed.
>
> Great that you figured it out yourself!
The power of Open Source in action :)
But thanks a lot Julien, it was really great that you could solve it
yourself.
> We will send a proper patch for this.
I now sent a patch (plus few cleanups) to fix this.
--
Kalle Valo
On 03/08/2013 03:58 PM, Kalle Valo wrote:
> Mohammed Shafi Shajakhan <[email protected]> writes:
>
>> Hi Julien,
>>
>> On 02/21/2013 07:33 PM, Julien Massot wrote:
>>> Hi,
>>> I just find a quick and dirty patch to workaround this issue.
>>> I just reset the device on initialization failure.
>>>
>>> I hope this helps to understand the real issue.
>>>
>>> [ 7.012514] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/bdata.bin
>>> [ 7.035276] cfg80211: World regulatory domain updated:
>>> [ 7.035287] cfg80211: (start_freq - end_freq @ bandwidth),
>>> (max_antenna_gain, max_eirp)
>>> [ 7.035299] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
>>> (300 mBi, 2000 mBm)
>>> [ 7.037916] usb 1-7: firmware: requesting ath6k/AR6004/hw1.3/fw-3.bin
>>> [ 9.378940] ath6kl: f59afe4c
>>> [ 9.379054] ath6kl: f59afe6c
>>> [ 9.379391] ath6kl_usb: probe of 1-7:1.0 failed with error -5
>>> Here I reset the device.
>>
>> that was the suggestion gave by Wei. The failure it seems
>> check hostapp area to check target status and reset the device
>> if needed.
>>
>> Great that you figured it out yourself!
>
> The power of Open Source in action :)
>
> But thanks a lot Julien, it was really great that you could solve it
> yourself.
>
>> We will send a proper patch for this.
>
> I now sent a patch (plus few cleanups) to fix this.
>
yeah, I had a few patches in my stash, but you addressed them in your
series. thanks :-)
--
thanks,
shafi