2007/11/30, Nick Kossifidis <[EMAIL PROTECTED]>: > 2007/11/29, Pavel Roskin <[EMAIL PROTECTED]>: > > On Thu, 2007-11-29 at 10:43 +0200, Nick Kossifidis wrote: > > > > > O.K. so problem seems the same, as ticket > > > http://madwifi.org/ticket/859 says it's a problem on pci-e cards. I > > > believe that pci-e cards have a different wakeup method and since > > > binary HAL identifies chip via pci-id (which is bad imho), if someone > > > has a faulty pci id (pci id of another chipset eg. some cards on > > > Thinkpafs) then HAL won't use the proper wakeup method. > > > > > > You might be right about the bridge thing, i've got some 4x MiniPCI to > > > PCI adapters so i'll test it there too and see what happens. For your > > > card, i just want to know srev value, so you can comment out the whole > > > eeprom etc stuff from ath_info and just read srev, does it also return > > > 0xfff.. ? I've seen that srev value can be read even without setpci > > > (on a 5416 card which is also pci-e i always get srev, even when > > > eeprom returns 0xfff.., also on other cards without setpci i don't > > > always get eeprom info or radio revision but i always get srev). > > > > srev is 0xffff. Both under 32-bit and 64-bit kernel. > > > > ?!?!? this looks weird... > > I'll come back to you with the attach sequence of 5418 which is also > pci-e, maybe if we try doing the same for your chip, it'll work... >
Ppl can you try using madwifi-trace with hal commited by atheros here ?-> http://madwifi.org/ticket/1679 -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
