Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #2348 (new defect)

Opened 12 years ago

Last modified 12 years ago

ar5001x+ status 3

Reported by: trash Assigned to:
Priority: minor Milestone:
Component: madwifi: other Version:
Keywords: Cc:
Patch is attached: 0 Pending: 0

Description (Last modified by mrenzmann)

hello ive tried every package and them some - been trying to get this to work with various things for ages. any help would be most appreciated - i have no idea why it doesnt work other than it might not be supported - but the madwifi page claims it is. im in a spin ive tried so many things i cant find a similar problem where the solution works.

Linux 2.6.29-sabayon #1 SMP Wed Aug 19 22:18:09 UTC 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz GenuineIntel GNU/Linux

04:00.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)
	Subsystem: Atheros Communications Inc. Ubiquiti Networks SuperRange a/b/g Cardbus Adapter
	Flags: medium devsel, IRQ 19
	Memory at 124000000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: [44] Power Management version 2
	Kernel modules: ath_pci

#ath_info 124000000
sleep_ctl reg ffffffff   reset_ctl reg ffffffff
waking up the chip
removing resets
MAC revision 0xffff is not supported!

dmesg

[ 2242.925996] ath_pci 0000:04:00.0: enabling device (0000 -> 0002)
[ 2242.926023] ath_pci 0000:04:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 2242.930329] MadWifi: unable to attach hardware: 'Hardware didn't respond as expected' (HAL status 3)
[ 2242.930355] ath_pci 0000:04:00.0: PCI INT A disabled

ive tried madwifi-current various revisions of madwifi-hal, madwifi-old, 0.9.4. 0.10.5.6 nothing works older ones throw up a revision problem. one thing that bothers me is why does the memory on lspci say 32bit ?

Change History

(follow-up: ↓ 2 ) 09/27/09 08:47:04 changed by mrenzmann

  • description changed.

(in reply to: ↑ 1 ; follow-ups: ↓ 3 ↓ 4 ) 09/27/09 08:59:06 changed by trash

Replying to mrenzmann: according to ubiquiti networks this is wrongly identified and should be a 5004x not sure if thats right.

(in reply to: ↑ 2 ) 09/28/09 00:45:52 changed by anonymous

Replying to trash:

Replying to mrenzmann: according to ubiquiti networks this is wrongly identified and should be a 5004x not sure if thats right.

from some irc chat and the ubiquiti site - i think ive confirmed the chipset is a 5004x

Subsystem: Atheros Communications Inc. Ubiquiti Networks SuperRange a/b/g Cardbus Adapter [168c:1042]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 124000000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Kernel modules: ath_pci

(in reply to: ↑ 2 ; follow-up: ↓ 5 ) 09/28/09 08:27:35 changed by mrenzmann

Replying to trash:

according to ubiquiti networks this is wrongly identified and should be a 5004x not sure if thats right.

lspci is not reliable for chipset identification. MadWifi uses different ways to see which chipset is used on devices it handles.

(in reply to: ↑ 4 ; follow-up: ↓ 6 ) 09/28/09 17:39:22 changed by anonymous

lspci is not reliable for chipset identification. MadWifi uses different ways to see which chipset is used on devices it handles.

what not even the device string ?

main:
168c:0013
subsystem:
168c:1042

according to ubnt this is a 5004x how would i confirm that then ? and also - what difference does it make to anything ? :)

(in reply to: ↑ 5 ; follow-up: ↓ 7 ) 09/29/09 07:14:23 changed by mrenzmann

Replying to anonymous:

what not even the device string ?

The PCI ID comes from the card, but it is no reliable indicator of chipset and stuff - there are vendors that use the same ID for different cards with different chipsets.

ath_info is the only reliable way to programmatically determine which chipset is working on your card. Make sure you use the latest version of it.

and also - what difference does it make to anything ? :)

None. The magic words here are "Hardware didn't respond as expected (HAL status 3)". This appears like a hardware problem. If it was a lack of support for the chipset on that card, HAL status would more likely be 13.

I know there were cases of HAL status 3 in the past that could be solved, IIRC those were handled in the madwifi-users list. Already tried searching the archives of that list, and/or searching the tickets here?

(in reply to: ↑ 6 ; follow-ups: ↓ 8 ↓ 9 ) 09/29/09 19:38:55 changed by anonymous

ath_info is the only reliable way to programmatically determine which chipset is working on your card. Make sure you use the latest version of it.

double checked for latest version - same message.

None. The magic words here are "Hardware didn't respond as expected (HAL status 3)". This appears like a hardware problem. If it was a lack of support for the chipset on that card, HAL status would more likely be 13.

yep. after extensive googling for the past year i knew that :)

I know there were cases of HAL status 3 in the past that could be solved, IIRC those were handled in the madwifi-users list. Already tried searching of that list, and/or /search searching the tickets] here?

ive searched for the last year before posting this - i dont post bug reports unless ive really exhausted all avenues. i searched again just for a laugh nothing for '5001 status 3' or '5004 status 3' on tickets. and couldnt see anything on the users list, but im assuming that would have come up in a google search anyway.

can you confirm what exact driver versions and download i should use for a 5004x on amd64 2.6.29 gentoo ? bit confusing all the different versions - i think ive tried every one now anyway :)

(in reply to: ↑ 7 ) 09/30/09 02:33:13 changed by anonymous

also tried

setpci -s 0b:00.0 command=0x41f cache_line_size=0x10 

from ath_info manual - but this results in the same message.

(in reply to: ↑ 7 ; follow-up: ↓ 10 ) 09/30/09 06:32:16 changed by mrenzmann

Replying to anonymous:

can you confirm what exact driver versions and download i should use for a 5004x

Latest trunk. Not because I know this would work, but because that version has the highest chance to get fixed in case your problem turns out to be driver-related. But please note that the overall chances for that are not too high, taking into consideration that MadWifi is considered legacy.

(in reply to: ↑ 9 ) 09/30/09 07:15:42 changed by anonymous

so i should go back to the ath dev mailing list then :-/ i tried that a few months back same troubles. i just tried it on backtrack 4 and the card loads fine on the ath5k driver. the reason i was trying madwifi is i had struggled with the ath5k in exactly the same way on gentoo for months. ok consider this bug report over if ath5k will go into monitor mode on my card. i will use this for reference for the ath5k bug report again - although even the devs couldnt seem to see what was happening last time (cannot wake up mac chip) thanks for your time sir.

(follow-up: ↓ 12 ) 09/30/09 07:43:38 changed by anonymous

[ 2567.110663] ath5k 0000:04:00.0: enabling device (0000 -> 0002)
[ 2567.110673] ath5k 0000:04:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 2567.110732] ath5k 0000:04:00.0: registered as 'phy1'
[ 2567.120849] ath5k phy1: failed to wakeup the MAC Chip
[ 2567.120878] ath5k 0000:04:00.0: PCI INT A disabled
[ 2567.121272] ath5k: probe of 0000:04:00.0 failed with error -5

oh. that one again. you dont know how much ive missed this error. so glad to go back to ath5k again. ha. who actually makes these drivers ? is there anyway i can take them by the neck via the internet ? perhaps some kind of pneumatic hand that comes as a 3.5 hard drive bay attachment ala fufme ? ahem.

(in reply to: ↑ 11 ; follow-up: ↓ 13 ) 09/30/09 12:07:23 changed by mrenzmann

Replying to anonymous:

[ 2567.120849] ath5k phy1: failed to wakeup the MAC Chip oh. that one again.

As a blind (and uneducated) guess, I'd take this message and the one you got from MadWifi as strong hint that the problem comes either from a unusual "system setup" or a hardware-related issue. As in: I don't think this problem originates from (a bug in) the drivers as such. But please take this with a grain of salt.

who actually makes these drivers?

ath5k is part of the Linux kernel. Bug reports can be reported via the kernel bugzilla, developers can be reached via the linux-wireless or ath5k-devel mailing lists.

(in reply to: ↑ 12 ) 09/30/09 18:47:07 changed by anonymous

sorry for my silly comment. ahem. ok well im running it on a dell laptop precision m4300. i sort of have an inkling it might be something like what you suggest. its not waking up so the driver doesnt even have a chance to get at it - it seems. are there steps i can take to copy the setup that works in backtrack 4. im starting to wonder if backtrack 4 has some kind of patch applied to its kernel for ath5k. ill try and find out and see what happens. thanks for your help.