Thread: Re: [Madwifi-devel] UBNT Bullet 5M support on madwifi
Status: Beta
Brought to you by:
otaku
From: LAMBA J. <Jai...@al...> - 2010-01-12 23:33:22
|
>> Finally, we could backport only the files for AR928X support and their dependencies. That's would be the easiest in terms of changes, but it would still take several iterations before it compiles, >> and I'm not sure it would work right away. It tried it and gave up due to lack of time. >> You can get FreeBSD HAL by svn co http://svn.freebsd.org/base/head/sys/dev/ath I took a stab at this option. I could compile the code and after couple of fixes got to a point where there is EEPROM mismatch. Basically in file ath_hal/ah_eeprom_v14.c in function ath_hal_v14EepromAttach, a function call to (!ath_hal_eepromRead(ah, AR5416_EEPROM_MAGIC_OFFSET, &magic)) is setting magic to 0 which causes mismatch. Any pointers to move forward on this are appreciated. If you would like to look at the code please let me know and I will upload it somewhere. Thanks, Jaideep |
From: LAMBA J. <Jai...@al...> - 2010-01-14 17:54:23
|
>> >> I suggest that you give a little bit more details about the errors you encounter. At least please quote the exact messages. >> >> If I understand correctly, the magic value you get is neither 0x5aa5 nor 0xa55a. Then what is the value? Can you print it? >> This is the exact dmesg dump after compiling the load with HAL_DEBUG turned on. I am digging in further but pointers are much appreciated. I am using r4107 with Pavel's patch. PCI: Setting latency timer of device 0000:00:00.0 to 64 ar9280Attach: sc 81664300 st (null) sh b0000000 ar9280Attach: ID 0x852ff VERSION 0x2 TYPE 0x5 REVISION 0x2 ath_hal_v14EepromAttach Eeprom Magic = 0x0 Bad magic number ar5416Detach: MadWifi: unable to attach hardware: 'EEPROM magic number invalid' (HAL status 4) Regards, Jaideep |
From: Pavel R. <pr...@gn...> - 2010-01-14 19:15:30
|
On Thu, 2010-01-14 at 11:53 -0600, LAMBA Jaideep wrote: > PCI: Setting latency timer of device 0000:00:00.0 to 64 > ar9280Attach: sc 81664300 st (null) sh b0000000 > ar9280Attach: ID 0x852ff VERSION 0x2 TYPE 0x5 REVISION 0x2 > ath_hal_v14EepromAttach Eeprom Magic = 0x0 > Bad magic number Then it's not byteswapping. It's a failure to read EEPROM or an unknown EEPROM layout. Answering your other e-mail, you should be able to dump EEPROM by doing printk() in the driver. It's actually more reliable than ath_info. ath_info is a userspace program that touches the hardware without any drivers, which is a very hacking approach. -- Regards, Pavel Roskin |
From: LAMBA J. <Jai...@al...> - 2010-02-20 21:53:12
|
>> Didn't you get my message where I pointed out that the UBNT gear has the calibration data on system flash instead of a separate EEPROM? >> Here's another hint: Access to the data is provided through platform data, which the OpenWrt ar71xx kernel code attaches to the PCI device. Felix, I was finally able to grab the platform data from pci device. In order to achieve this I had to pass pci_device pointer from probe function all the way down to ar9280Attach function. I also wrote a new eepromread function for ar9280 to read from platform data and put it in HAL eeprom structure. I verified this output with ath5K platform data to make sure I was doing it right. Now although I was able to attach drivers to wifi device and create an interface with adhoc mode and ip address, the system didn't work at all. As soon as the ipaddress was assigned dmesg kept on bombarding the log file with the following errors. wifi0: ath_rxorn_tasklet: Receive FIFO overrun; resetting. wifi0: ath_fatal_tasklet: Hardware error; resetting. I tried the following as reported in ticket 1017 and others iwpriv ath0 bgscan 0 After turning on some traces I also saw following messages getting displayed wifi0: ath_tx_stopdma: TX queue [2] 0x0, link 00000000 wifi0: ath_tx_stopdma: TX queue [9] 0x0, link 00000000 wifi0: ath_stoprecv: receive queue buffer 0x1438000, link a143a520 wifi0: ath_startrecv: RX settings: mtu 1500 cachelsz 32 rxbufsize 3104 wifi0: ath_tx_tasklet: Processing CABQ... it is setup and active in HAL. wifi0: ath_tx_tasklet: Processing CABQ... it is setup and active in HAL. wifi0: ath_rxorn_tasklet: Receive FIFO overrun; resetting. wifi0: ath_draintxq: Invoking ath_hal_stoptxdma with sc_bhalq:9. wifi0: ath_draintxq: Beacon queue txbuf is 0x0. wifi0: ath_tx_stopdma: TX queue [0] 0x0, link 00000000 I am using madwifi trunk 4107+my patches for reading platform data on Bullet M5HP. Lspci output for the same is root@OpenWrt:~# ./lspci 00:00.0 0280: 168c:002a (rev 01) I am running openwrt on the bullet with 2.6.30.10 kernel compiled on Jan 2' 2010. Dmesg output reporting chipset is Wifi0: Atheros AR9280 chip found (MAC 128.2 PHY 5133 13.0, Radio 12.0) Any help pointers to go further are appreciated. Thanks, Jaideep |
From: Felix F. <nb...@op...> - 2010-02-22 14:02:50
|
On 2010-02-20 10:52 PM, LAMBA Jaideep wrote: > >>> Didn't you get my message where I pointed out that the UBNT gear has > the calibration data on system flash instead of a separate EEPROM? >>> Here's another hint: Access to the data is provided through platform > data, which the OpenWrt ar71xx kernel code attaches to the PCI device. > > Felix, > > I was finally able to grab the platform data from pci device. In order > to achieve this I had to pass pci_device pointer from probe function all > the way down to ar9280Attach function. I also wrote a new eepromread > function for ar9280 to read from platform data and put it in HAL eeprom > structure. I verified this output with ath5K platform data to make sure > I was doing it right. > > Now although I was able to attach drivers to wifi device and create an > interface with adhoc mode and ip address, the system didn't work at all. > As soon as the ipaddress was assigned dmesg kept on bombarding the log > file with the following errors. > > wifi0: ath_rxorn_tasklet: Receive FIFO overrun; resetting. > wifi0: ath_fatal_tasklet: Hardware error; resetting. > > I tried the following as reported in ticket 1017 and others > iwpriv ath0 bgscan 0 > > After turning on some traces I also saw following messages getting > displayed > wifi0: ath_tx_stopdma: TX queue [2] 0x0, link 00000000 > wifi0: ath_tx_stopdma: TX queue [9] 0x0, link 00000000 > wifi0: ath_stoprecv: receive queue buffer 0x1438000, link a143a520 > wifi0: ath_startrecv: RX settings: mtu 1500 cachelsz 32 rxbufsize 3104 > wifi0: ath_tx_tasklet: Processing CABQ... it is setup and active in HAL. > wifi0: ath_tx_tasklet: Processing CABQ... it is setup and active in HAL. > wifi0: ath_rxorn_tasklet: Receive FIFO overrun; resetting. > wifi0: ath_draintxq: Invoking ath_hal_stoptxdma with sc_bhalq:9. > wifi0: ath_draintxq: Beacon queue txbuf is 0x0. > wifi0: ath_tx_stopdma: TX queue [0] 0x0, link 00000000 > > I am using madwifi trunk 4107+my patches for reading platform data on > Bullet M5HP. Lspci output for the same is > root@OpenWrt:~# ./lspci > 00:00.0 0280: 168c:002a (rev 01) > > I am running openwrt on the bullet with 2.6.30.10 kernel compiled on Jan > 2' 2010. Dmesg output reporting chipset is > Wifi0: Atheros AR9280 chip found (MAC 128.2 PHY 5133 13.0, Radio 12.0) > > Any help pointers to go further are appreciated. No idea about this, sorry. The only thing I can tell you about this is that RXORN is typically the hardware complaining about failures in the DMA setup, but it could still be anything... But I still wonder: why put so much work into a codebase that is quickly falling behind in terms of stability and even features? With recent versions, ath9k is working reliably for me on AR9280 based hardware, including full 11n support and even Multi-BSS operation. What advantage does madwifi have left? - Felix |
From: Pavel R. <pr...@gn...> - 2010-01-13 07:05:54
|
Quoting LAMBA Jaideep <Jai...@al...>: > I took a stab at this option. I could compile the code and after couple > of fixes got to a point where there is EEPROM mismatch. I have committed what I have done so far. The preparatory work affecting AR5416 has been committed as a separate patch, so that the effects on other chipsets can be localized. I'm getting an error: wifi1: ath_init: unable to reset hardware: 'Hardware self-test failed' (HAL status 14) (freq 2412 flags 0xa0) However, I can only test my code on a card that doesn't even work with ath9k. It might work with the hardware supported by ath9k. > Basically in file ath_hal/ah_eeprom_v14.c in function > ath_hal_v14EepromAttach, a function call to (!ath_hal_eepromRead(ah, > AR5416_EEPROM_MAGIC_OFFSET, &magic)) is setting magic to 0 which causes > mismatch. Any pointers to move forward on this are appreciated. If you > would like to look at the code please let me know and I will upload it > somewhere. I'm getting 0xa55a there, which is the right value. You may want to diff your code against the current trunk. The change should not be very big, as we would basically do the same thing. Then you can drop the minor differences or what you think is done better in Subversion. Then you can post the diff here. -- Regards, Pavel Roskin |
From: Pavel R. <pr...@gn...> - 2010-01-13 07:40:16
|
Quoting Pavel Roskin <pr...@gn...>: > I'm getting an error: > > wifi1: ath_init: unable to reset hardware: 'Hardware self-test failed' > (HAL status 14) (freq 2412 flags 0xa0) > > However, I can only test my code on a card that doesn't even work with > ath9k. It might work with the hardware supported by ath9k. I was able to avoid this error by treating the card as an older version. For that I applied the following patch: Index: ath_hal/ar5416/ar9280_attach.c =================================================================== --- ath_hal/ar5416/ar9280_attach.c (revision 4107) +++ ath_hal/ar5416/ar9280_attach.c (working copy) @@ -147,7 +147,7 @@ AH_PRIVATE(ah)->ah_ispcie = (val & AR_XSREV_TYPE_HOST_MODE) == 0; /* setup common ini data; rf backends handle remainder */ - if (AR_SREV_MERLIN_20_OR_LATER(ah)) { + if (0) { HAL_INI_INIT(&ahp->ah_ini_modes, ar9280Modes_v2, 6); HAL_INI_INIT(&ahp->ah_ini_common, ar9280Common_v2, 2); HAL_INI_INIT(&AH5416(ah)->ah_ini_pcieserdes, With the above patch, I was able to scan, associate to an AP with WEP and run dhcp client on the interface successfully. However, I could not send any more data through it. I'm pretty optimistic that AR9220/AR9280 cards that currently work with ath9k should work with the current trunk. I may be able to test it tomorrow. -- Regards, Pavel Roskin |
From: Pavel R. <pr...@gn...> - 2010-01-13 17:23:04
|
On Wed, 2010-01-13 at 02:40 -0500, Pavel Roskin wrote: > I'm pretty optimistic that AR9220/AR9280 cards that currently work > with ath9k should work with the current trunk. I may be able to test > it tomorrow. Yes, it's working perfectly. It looks like PCI Express cards are working, but PCI (including miniPCI) is initialized incorrectly. If the solution is not found quickly, 168c:0029 will be removed from the PCI ID list, but 168c:002a will stay. So MadWifi trunk should now support PCI Express based AR9280 devices. As far as I know AR9220 refers to the same devices as AR9280 for all practical purposes. -- Regards, Pavel Roskin |
From: LAMBA J. <Jai...@al...> - 2010-01-13 17:28:28
|
>> >>> I'm pretty optimistic that AR9220/AR9280 cards that currently work >>> with ath9k should work with the current trunk. I may be able to test >>> it tomorrow. >> >Yes, it's working perfectly. It looks like PCI Express cards are working, but PCI (including miniPCI) is initialized incorrectly. If the solution is not found quickly, 168c:0029 will be removed from >the PCI ID list, but 168c:002a will stay. > >So MadWifi trunk should now support PCI Express based AR9280 devices. >As far as I know AR9220 refers to the same devices as AR9280 for all practical purposes. Thanks Pavel. I am going to check the diff and test it today. |
From: Lorenzo B. <lor...@gm...> - 2010-01-13 18:38:59
|
2010/1/13 LAMBA Jaideep <Jai...@al...>: >>> >>>> I'm pretty optimistic that AR9220/AR9280 cards that currently work >>>> with ath9k should work with the current trunk. I may be able to > test >>>> it tomorrow. >>> >>Yes, it's working perfectly. It looks like PCI Express cards are > working, but PCI (including miniPCI) is initialized incorrectly. If the > solution is not found quickly, 168c:0029 will be removed from >>the PCI ID list, but 168c:002a will stay. >> >>So MadWifi trunk should now support PCI Express based AR9280 devices. >>As far as I know AR9220 refers to the same devices as AR9280 for all > practical purposes. > > Thanks Pavel. I am going to check the diff and test it today. > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > Hi all, I am trying MadWiFi-trunk revision 4107 on Bullet M5 with the latest version of OpenWRT trunk but when I load the ath_pci module I obtain this error: "MadWifi: unable to attach hardware: 'EEPROM magic number invalid' (HAL status 4)" Have I missed some configuration step? Regards, Lorenzo |
From: Pavel R. <pr...@gn...> - 2010-01-13 19:01:56
|
On Wed, 2010-01-13 at 19:38 +0100, Lorenzo Bianconi wrote: > I am trying MadWiFi-trunk revision 4107 on Bullet M5 with the latest version > of OpenWRT trunk but when I load the ath_pci module I obtain this error: > > "MadWifi: unable to attach hardware: 'EEPROM magic number invalid' > (HAL status 4)" > > Have I missed some configuration step? No, it just confirms that LAMBA Jaideep didn't make a mistake and that the problem with EEPROM is real and not an artifact of HAL code porting. Is ath9k working with your device? If yes, chances are your EEPROM simply needs byteswapping. -- Regards, Pavel Roskin |
From: LAMBA J. <Jai...@al...> - 2010-01-13 19:11:50
|
> > No, it just confirms that LAMBA Jaideep didn't make a mistake and that the problem with EEPROM is real and not an artifact of HAL code porting. > > Is ath9k working with your device? If yes, chances are your EEPROM simply needs byteswapping. I verified the code differences are same as what I ported to my working copy. And I am facing the same EEPROM problem with trunk-4107. Pavel can you please tell something more about this EEPROM byteswapping. Thanks, Jaideep |
From: Pavel R. <pr...@gn...> - 2010-01-13 19:18:30
|
On Wed, 2010-01-13 at 13:11 -0600, LAMBA Jaideep wrote: > I verified the code differences are same as what I ported to my working > copy. And I am facing the same EEPROM problem with trunk-4107. Pavel can > you please tell something more about this EEPROM byteswapping. You can see the byteswapping code in ath9k in several places: if (magic != AR5416_EEPROM_MAGIC) { magic2 = swab16(magic); if (magic2 == AR5416_EEPROM_MAGIC) { size = sizeof(struct ar5416_eeprom_def); need_swap = true; eepdata = (u16 *) (&ah->eeprom); for (addr = 0; addr < size / sizeof(u16); addr++) { temp = swab16(*eepdata); *eepdata = temp; eepdata++; } It means, if the magic is byteswapped, then the rest of the EEPROM buffer should be byteswapped as well. -- Regards, Pavel Roskin |
From: LAMBA J. <Jai...@al...> - 2010-01-13 19:24:25
|
>> It means, if the magic is byteswapped, then the rest of the EEPROM buffer should be byteswapped as well. This might actually be true. I compiled ath_info with a workaround for MAC version check and ath_info dump is showing this device to be 2Ghz device as compared to 5Ghz device. I guess ath_hal needs to read EEPROM differently with byte swapping. What would be a good place to start making that code change in madwifi ? Thanks, Jaideep |
From: Pavel R. <pr...@gn...> - 2010-01-13 22:46:19
|
On Wed, 2010-01-13 at 13:23 -0600, LAMBA Jaideep wrote: > >> It means, if the magic is byteswapped, then the rest of the EEPROM > buffer should be byteswapped as well. > > This might actually be true. I compiled ath_info with a workaround for > MAC version check and ath_info dump is showing this device to be 2Ghz > device as compared to 5Ghz device. I guess ath_hal needs to read EEPROM > differently with byte swapping. What would be a good place to start > making that code change in madwifi ? It looks like there is some byteswap code in the HAL already. However, it won't be reached if byteswapping is needed because the magic value is checked earlier in the same function and there is no fallback for the byteswapped magic. Please test this patch: --- a/ath_hal/ah_eeprom_v14.c +++ b/ath_hal/ah_eeprom_v14.c @@ -313,7 +313,11 @@ ath_hal_v14EepromAttach(struct ath_hal *ah) } HALDEBUG(ah, HAL_DEBUG_ATTACH, "%s Eeprom Magic = 0x%x\n", __func__, magic); - if (magic != AR5416_EEPROM_MAGIC) { + if (magic == AR5416_EEPROM_MAGIC) + need_swap = 0; + else if (magic == __bswap16(AR5416_EEPROM_MAGIC)) + need_swap = 1; + else { HALDEBUG(ah, HAL_DEBUG_ANY, "Bad magic number\n"); return HAL_EEMAGIC; } @@ -335,7 +339,7 @@ ath_hal_v14EepromAttach(struct ath_hal *ah) } } /* Convert to eeprom native eeprom endian format */ - if (isBigEndian()) { + if (need_swap) { for (w = 0; w < NW(struct ar5416eeprom); w++) eep_data[w] = __bswap16(eep_data[w]); } -- Regards, Pavel Roskin |
From: LAMBA J. <Jai...@al...> - 2010-01-13 23:09:52
|
>> >>It looks like there is some byteswap code in the HAL already. However, it won't be reached if byteswapping is needed because the magic value is checked earlier in the same function and there is >>no fallback for the byteswapped magic. >> >>Please test this patch: I tested something similar. I jumped magic number check test and saw it fall through the big_endian code where it byte swaps but then the loading would failure with EEPROM checksum invalid. If I try your patch as is on 4107 I would again have magic number check failure. Regards, Jaideep |
From: Pavel R. <pr...@gn...> - 2010-01-14 06:39:11
|
Quoting LAMBA Jaideep <Jai...@al...>: > I tested something similar. I jumped magic number check test and saw it > fall through the big_endian code where it byte swaps but then the > loading would failure with EEPROM checksum invalid. > > If I try your patch as is on 4107 I would again have magic number check > failure. I suggest that you give a little bit more details about the errors you encounter. At least please quote the exact messages. If I understand correctly, the magic value you get is neither 0x5aa5 nor 0xa55a. Then what is the value? Can you print it? -- Regards, Pavel Roskin |
From: LAMBA J. <Jai...@al...> - 2010-01-14 06:47:14
|
>> I tested something similar. I jumped magic number check test and saw >> it fall through the big_endian code where it byte swaps but then the >> loading would failure with EEPROM checksum invalid. >> >> If I try your patch as is on 4107 I would again have magic number >> check failure. > >I suggest that you give a little bit more details about the errors you encounter. At least please quote the exact messages. > >If I understand correctly, the magic value you get is neither 0x5aa5 nor 0xa55a. Then what is the value? Can you print it? Madwifi r4107 would give you HAL status 4 (HAL_EEMAGIC). If you bypass magic check and add your patch to byte swap then we get HAL status 7 (HAL_EEBADSUM). I am not near the test setup to print out the exact error messages but these are the error values and corresponding text gets printed. Magic value was zero. But I will check again tomorrow to confirm. If magic value is zero what do I have to debug further ? Ath_info doesn't work for ar9280. Is there any other tool that I can use to dump the eeprom from bullet 5M. |
From: LAMBA J. <Jai...@al...> - 2010-01-16 00:46:10
|
>>>>>> >>>>>> I suggest that you give a little bit more details about the errors you encounter. At least please quote the exact messages. >>>>>> >>>>>> If I understand correctly, the magic value you get is neither 0x5aa5 nor 0xa55a. Then what is the value? Can you print it? >>>>>> >> >>Complete information after turning ON all traces in HAL debug. >> >>PCI: Setting latency timer of device 0000:00:00.0 to 64 >>ar9280Attach: sc 81ef8300 st (null) sh b0000000 ar5416SetReset Applying descriptor swap >>ar5416SetPowerMode: AWAKE -> AWAKE (set chip ) >>ar9280Attach: ID 0x852ff VERSION 0x2 TYPE 0x5 REVISION 0x2 ath_hal_v14EepromAttach Eeprom Magic = 0x0 Bad magic number >>ar5416Detach: >>Detaching Ani >>Disable MIB counters >>ar5212SetPowerMode: AWAKE -> AWAKE (set chip ) ar5416SetReset Applying descriptor swap >>ar5416SetPowerMode: AWAKE -> FULL-SLEEP (set chip ) >>MadWifi: unable to attach hardware: 'EEPROM magic number invalid' (HAL status 4) I tried multiple approaches to read the contents of the EEPROM like adding offset 0x100 as ath9k does but I still keep on getting 0x0 in every single word of the eeprom. After comparing ath9k code with madwifi only difference I can figure out is that ini arrays defined in ath9k_v2.ini are different from those defined in ar9280v2.ini. Not sure if that can cause eeprom reading problems. I don't think it's a byte swapping issue since the output result is plain 0. I have banged my head hard but cant figure out what am I doing wrong. Would really appreciate another set of eyes at this point. Regards, Jaideep |
From: Felix F. <nb...@op...> - 2010-01-17 21:56:46
|
On 2010-01-16 1:14 AM, LAMBA Jaideep wrote: >>>>>>> >>>>>>> I suggest that you give a little bit more details about the > errors you encounter. At least please quote the exact messages. >>>>>>> >>>>>>> If I understand correctly, the magic value you get is neither > 0x5aa5 nor 0xa55a. Then what is the value? Can you print it? >>>>>>> >>> >>>Complete information after turning ON all traces in HAL debug. >>> >>>PCI: Setting latency timer of device 0000:00:00.0 to 64 >>>ar9280Attach: sc 81ef8300 st (null) sh b0000000 ar5416SetReset > Applying descriptor swap >>>ar5416SetPowerMode: AWAKE -> AWAKE (set chip ) >>>ar9280Attach: ID 0x852ff VERSION 0x2 TYPE 0x5 REVISION 0x2 > ath_hal_v14EepromAttach Eeprom Magic = 0x0 Bad magic number >>>ar5416Detach: >>>Detaching Ani >>>Disable MIB counters >>>ar5212SetPowerMode: AWAKE -> AWAKE (set chip ) ar5416SetReset Applying > descriptor swap >>>ar5416SetPowerMode: AWAKE -> FULL-SLEEP (set chip ) >>>MadWifi: unable to attach hardware: 'EEPROM magic number invalid' (HAL > status 4) > > > I tried multiple approaches to read the contents of the EEPROM like > adding offset 0x100 as ath9k does but I still keep on getting 0x0 in > every single word of the eeprom. After comparing ath9k code with madwifi > only difference I can figure out is that ini arrays defined in > ath9k_v2.ini are different from those defined in ar9280v2.ini. Not sure > if that can cause eeprom reading problems. > > I don't think it's a byte swapping issue since the output result is > plain 0. > > I have banged my head hard but cant figure out what am I doing wrong. > Would really appreciate another set of eyes at this point. Didn't you get my message where I pointed out that the UBNT gear has the calibration data on system flash instead of a separate EEPROM? Here's another hint: Access to the data is provided through platform data, which the OpenWrt ar71xx kernel code attaches to the PCI device. - Felix |
From: LAMBA J. <Jai...@al...> - 2010-01-19 06:25:06
|
>> Didn't you get my message where I pointed out that the UBNT gear has the calibration data on system flash instead of a separate EEPROM? >> Here's another hint: Access to the data is provided through platform data, which the OpenWrt ar71xx kernel code attaches to the PCI device. Thanks Felix. I will try again soon after I return to lab in few days and would report back my results. Regards, Jaideep |
From: LAMBA J. <Jai...@al...> - 2010-01-14 19:10:47
|
>>>> >>>> I suggest that you give a little bit more details about the errors you encounter. At least please quote the exact messages. >>>> >>>> If I understand correctly, the magic value you get is neither 0x5aa5 nor 0xa55a. Then what is the value? Can you print it? >>>> >> >>This is the exact dmesg dump after compiling the load with HAL_DEBUG turned on. I am digging in further but pointers are much appreciated. I am using r4107 with Pavel's patch. >> >>PCI: Setting latency timer of device 0000:00:00.0 to 64 >>ar9280Attach: sc 81664300 st (null) sh b0000000 >>ar9280Attach: ID 0x852ff VERSION 0x2 TYPE 0x5 REVISION 0x2 ath_hal_v14EepromAttach Eeprom Magic = 0x0 Bad magic number >>ar5416Detach: >>MadWifi: unable to attach hardware: 'EEPROM magic number invalid' (HAL status 4) >> Complete information after turning ON all traces in HAL debug. PCI: Setting latency timer of device 0000:00:00.0 to 64 ar9280Attach: sc 81ef8300 st (null) sh b0000000 ar5416SetReset Applying descriptor swap ar5416SetPowerMode: AWAKE -> AWAKE (set chip ) ar9280Attach: ID 0x852ff VERSION 0x2 TYPE 0x5 REVISION 0x2 ath_hal_v14EepromAttach Eeprom Magic = 0x0 Bad magic number ar5416Detach: Detaching Ani Disable MIB counters ar5212SetPowerMode: AWAKE -> AWAKE (set chip ) ar5416SetReset Applying descriptor swap ar5416SetPowerMode: AWAKE -> FULL-SLEEP (set chip ) MadWifi: unable to attach hardware: 'EEPROM magic number invalid' (HAL status 4) Regards, Jaideep |