Atheros (ath) MSI wireless embedded chipset fails to attach on
7.0-STABLE
Alexander Sack
pisymbol at gmail.com
Fri Aug 8 14:46:11 UTC 2008
Edwin L. Culp wrote:
>
> Alexander Sack <pisymbol at gmail.com> escribió:
>
>>
>>
>>
>> Edwin L. Culp wrote:
>>>
>>> "Alexander Sack" <pisymbol at gmail.com> escribió:
>>>
>>>> Final update, I got everything working! I came home and connected by
>>>> new notebook using the latest PCIe Atheros chipset to a WPA2 network
>>>> using wpa_supplicant! Yippie!
>>>>
>>>> Hope this thread helps someone else,
>>>>
>>>> -aps
>>>>
>>>> On Tue, Jun 17, 2008 at 5:17 PM, Alexander Sack <pisymbol at gmail.com>
>>>> wrote:
>>>>> On Tue, Jun 17, 2008 at 3:44 PM, Alexander Sack <pisymbol at gmail.com>
>>>>> wrote:
>>>>>> On Tue, Jun 17, 2008 at 3:35 PM, Edwin L. Culp
>>>>>> <eculp at casasponti.net> wrote:
>>>>>>> "Manolis Kiagias" <sonic2000gr at gmail.com> escribió:
>>>>>>>
>>>>>>>> Edwin L. Culp wrote:
>>>>>>>>>
>>>>>>>>> "Alexander Sack" <pisymbol at gmail.com> escribió:
>>>>>>>>>
>>>>>>>>>> On Tue, Jun 17, 2008 at 11:31 AM, Manolis Kiagias
>>>>>>>>>> <sonic2000gr at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Alexander Sack wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello:
>>>>>>>>>>>>
>>>>>>>>>>>> I have installed FreeBSD-7.0-amd64 stable on my new AMD X2
>>>>>>>>>>>> Turon based
>>>>>>>>>>>> notebook, a MSI-1710A (GX710Ax) which has a generic embedded
>>>>>>>>>>>> controller. During boot up I notice that ATH complains with:
>>>>>>>>>>>>
>>>>>>>>>>>> ath_rate: version 1.2 <SampleRate bit-rate selection algorithm>
>>>>>>>>>>>> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112,
>>>>>>>>>>>> RF2413,
>>>>>>>>>>>> RF5413)
>>>>>>>>>>>> ath0: <Atheros 5424/2424> mem 0xfd7f0000-0xfd7fffff irq 16 at
>>>>>>>>>>>> device
>>>>>>>>>>>> 0.0
>>>>>>>>>>>> on pci2
>>>>>>>>>>>> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfd7f0000
>>>>>>>>>>>> ath0: [MPSAFE]
>>>>>>>>>>>> ath0: [ITHREAD]
>>>>>>>>>>>> ath0: unable to attach hardware; HAL status 13
>>>>>>>>>>>> device_attach: ath0 attach returned 6
>>>>>>>>>>>>
>>>>>>>>>>>> HAL status 13 from the header file seems to indicate that the
>>>>>>>>>>>> 7.0-STABLE driver doesn't support my hardware revision. Here
>>>>>>>>>>>> is
>>>>>>>>>>>> my
>>>>>>>>>>>> pciconf -l output:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Maybe you could try compiling a kernel with a newer hal. This is
>>>>>>>>>>> the
>>>>>>>>>>> kind of
>>>>>>>>>>> hack we use on the eeepc. Have a look at this:
>>>>>>>>>>>
>>>>>>>>>>> http://nighthack.org/wiki/EeeBSD
>>>>>>>>>>
>>>>>>>>>> Thank you SO much for this link. That's EXACTLY what I want to
>>>>>>>>>> do
>>>>>>>>>> because I realize that this is a HAL problem. I've been
>>>>>>>>>> searching
>>>>>>>>>> like MAD where I could get an updated binary HAL for this chipset
>>>>>>>>>> (PCIe based).
>>>>>>>>>
>>>>>>>>> That makes two of us ;)
>>>>>>>>>
>>>>>>>>> My dmesg is very, very similar to yours and hoped that this would
>>>>>>>>> work.
>>>>>>>>>
>>>>>>>>> ath0: <Atheros 5424/2424> mem 0xf2200000-0xf220ffff irq 19 at
>>>>>>>>> device
>>>>>>>>> 0.0
>>>>>>>>> on pci5
>>>>>>>>> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf2200000
>>>>>>>>> ioapic0: routing intpin 19 (PCI IRQ 19) to vector 64
>>>>>>>>> ath0: [MPSAFE]
>>>>>>>>> ath0: [ITHREAD]
>>>>>>>>> ath0: unable to attach hardware; HAL status 13
>>>>>>>>> device_attach: ath0 attach returned 6
>>>>>>>>>
>>>>>>>>> I followed the instructions from the web page, recompiled and it
>>>>>>>>> made no
>>>>>>>>> difference which really worries me that I must have done
>>>>>>>>> something wrong.
>>>>>>>>>
>>>>>>>>> cd madwifi-ng-r2756+ar5007/hal
>>>>>>>>> cp -R * /usr/src/sys/contrib/dev/ath/
>>>>>>>>>
>>>>>>>>> I did not erase it previously but am going to try that. I made
>>>>>>>>> no
>>>>>>>>> kern
>>>>>>>>> configuration changes to find that the hal is from contrib. Is
>>>>>>>>> there
>>>>>>>>> nothing else I should do?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>
>>>>>>>> Well, I have only tested this on the eeepc and can confirm it
>>>>>>>> works.
>>>>>>>> Maybe different atheros chipset have other problems not directly
>>>>>>>> related
>>>>>>>> to the hal version.
>>>>>>>> You do not need to do anything more that what is shown in the
>>>>>>>> page: untar,
>>>>>>>> replace the existing files, recompile / install kernel, reboot.
>>>>>>>> If you got
>>>>>>>> no errors during the kernel compilation phase, you can safely
>>>>>>>> assume you did
>>>>>>>> everything correctly, and the problem lies elsewhere.
>>>>>>>
>>>>>>> At least there was a ray of hope for the time it took to compile
>>>>>>> the kernel.
>>>>>>
>>>>>> Ed:
>>>>>>
>>>>>> I took recompiled and got the same issue. If I use the LATEST mad
>>>>>> distro I get some compile bugs (ath_desc_status was moved into
>>>>>> ath_desc structure in ah_desc.h) which I can't completely work around
>>>>>> (apparently the API into the HAL has changed as well). What I'm
>>>>>> trying to do is look at the Linux driver and understand the newer API
>>>>>> in order to get past this compile issue and see if this works.
>>>>>> Otherwise I believe we are SOL.
>>>>>>
>>>>>> Does anyone know if the CURRENT contains an updated ath HAL AND
>>>>>> driver
>>>>>> for support of newer PCIe based chipsets?
>>>>>>
>>>>>> If I get it to work I will let you know...
>>>>>>
>>>>>
>>>>> Ok the trick is not to get it from the madfi project. Get it from the
>>>>> author directly!
>>>>>
>>>>> If you grab:
>>>>>
>>>>> http://people.freebsd.org/~sam/ath_hal-20080528.tgz
>>>>>
>>>>> Copy the contents into the src/sys/contrib/dev/ath/* and recompile,
>>>>> you should now see ath attach properly to the your NIC card. Thanks
>>>>> go to my friend jkim for pointing this out since he has a similar
>>>>> notebook/chipset and runs CURRENT successfully. I tried using CURRENT
>>>>> ath but there is to much vap support in it and it turned out the
>>>>> 7.0-RELEASE driver works.
>>>>>
>>>>> Now ath attaches properly and I'm going to test it out! (this is at
>>>>> least much further than a bad attach status code from the HAL).
>>>>>
>>>>> Let me know how it goes,
>>>
>>> Going G R E A T for the first time I see:
>>>
>>> ath_hal: 0.10.5.6 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112,
>>> RF2413, RF5413, RF2133, RF2425, RF2417)
>>>
>>> ath0: <Atheros 5424/2424> mem 0xf2200000-0xf220ffff irq 19 at device
>>> 0.0 on pci5
>>> ath0: [ITHREAD]
>>> ath0: WARNING: using obsoleted if_watchdog interface
>>> ath0: mac 14.2 phy 7.0 radio 10.2
>>>
>>> and an ifconfig ath0 shows:
>>>
>>> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
>>> 2290
>>> ether 00:1d:d9:27:5c:e5
>>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
>>> status: no carrier
>>>
>>> My problem is now the no carrier, I think that I'm very close but
>>> still no cigar.
>>>
>>> Thanks soooooo much for your help. Gonna bang away and the manuals
>>> and google to find out why, no carrier. I have an AP a few feet away
>>> and iPhone works great.
>>>
>>
>> Did you get this to ever work? I am now running into the same issue.
>> What
>> had happened was I sent my notebook back to fix a plastic latch and at
>> the
>> sametime work changed the wireless AP settings. Now when the chipset
>> comes
>> up I constantly get no carrier and ifconfig ath0 scan list just hangs
>> (sits
>> there).
>>
>> Any idea what maybe the issue? This is highly frustrating because it WAS
>> working (I'm using a new 7.0-STABLE, from yesterday freshly built against
>> Sam's latest HAL).
>
> It is working great for me on both amd64 and i386 Current 8 with
> ath_hal-20080528.
>
> I haven't had time to be too adventurous and am using a fixed
> configuration in rc.conf which follows:
>
> wlans_ath0=wlan0
> ifconfig_wlan0="DHCP ssid virus wepmode on wepkey 1:0x2373FE9515 weptxkey
> 1"
>
> It hasn't even hiccuped since I set it up. Actually I have multiple
> configurations for different AP's but haven't set it up to be automatic.
>
> I hope this helps some,
>
> ed
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"
>
>
Yes thanks. False alarm. Friggin support folks didn't install the antenna
right. As a result I was getting well no carrier all the time. Its fixed
and working!
Thanks!
--
View this message in context: http://www.nabble.com/Atheros-%28ath%29-MSI-wireless-embedded-chipset-fails-to-attach-on-7.0-STABLE-tp17913515p18893212.html
Sent from the freebsd-questions mailing list archive at Nabble.com.
More information about the freebsd-questions
mailing list