Date: Tue, 17 Jun 2008 15:44:28 -0400 From: "Alexander Sack" <pisymbol@gmail.com> To: "Edwin L. Culp" <eculp@casasponti.net> Cc: freebsd-questions@freebsd.org, freebsd-drivers@freebsd.org Subject: Re: Atheros (ath) MSI wireless embedded chipset fails to attach on 7.0-STABLE Message-ID: <3c0b01820806171244g6f2ba46ybe0ba6d89eaab13b@mail.gmail.com> In-Reply-To: <20080617143554.1808562gg94i8ikg@intranet.casasponti.net> References: <3c0b01820806170757v5565b59ne0e9d5db06f26761@mail.gmail.com> <4857D8BB.1080901@gmail.com> <3c0b01820806170852t39a6346doa6d77a655469eed9@mail.gmail.com> <20080617135900.18654t73s6d7sfqc@intranet.casasponti.net> <48580EB9.7090701@gmail.com> <20080617143554.1808562gg94i8ikg@intranet.casasponti.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 17, 2008 at 3:35 PM, Edwin L. Culp <eculp@casasponti.net> wrote= : > "Manolis Kiagias" <sonic2000gr@gmail.com> escribi=F3: > >> Edwin L. Culp wrote: >>> >>> "Alexander Sack" <pisymbol@gmail.com> escribi=F3: >>> >>>> On Tue, Jun 17, 2008 at 11:31 AM, Manolis Kiagias >>>> <sonic2000gr@gmail.com> wrote: >>>>> >>>>> Alexander Sack wrote: >>>>>> >>>>>> Hello: >>>>>> >>>>>> I have installed FreeBSD-7.0-amd64 stable on my new AMD X2 Turon bas= ed >>>>>> 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 n= o >>> difference which really worries me that I must have done something wron= g. >>> >>> 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 ker= n >>> 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: unta= r, >> replace the existing files, recompile / install kernel, reboot. If you g= ot >> 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 kern= el. 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... -aps
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c0b01820806171244g6f2ba46ybe0ba6d89eaab13b>