I want to have a 5 Ghz access point, so I replaced the miniPCI card in a WGT634U with a card from a WAG11.

I get an error message:

ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133,
REGOPS_FUNC)
ath_rate_minstrel: Minstrel automatic rate control algorithm 1.2 (svn r2568)
ath_rate_minstrel: look around rate set to 10%
ath_rate_minstrel: EWMA rolloff level set to 75%
ath_rate_minstrel: max segment size in the mrr set to 6000 us
wlan: mac acl policy registered
ath_pci: 0.9.4.5 (svn r2568)
PCI: Enabling device 0000:00:01.0 (0000 -> 0002)
PCI: Fixing up device 0000:00:01.0
MadWifi: unable to attach hardware: 'Hardware self-test failed' (HAL status 14)

Bummer.

This same card works fine in an x86 machine:

ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133
)
wlan: 0.8.4.2 (svn r2726)
ath_pci: 0.9.4.5 (svn r2726)
ACPI: PCI Interrupt 0000:01:09.0[A] -> GSI 21 (level, low) -> IRQ 21

ath_pci: switching rfkill capability off
ath_rate_sample: 1.2 (svn r2726)
ath_pci: switching per-packet transmit power control off
wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbp
s 54Mbps
wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: mac 5.6 phy 4.1 5 GHz radio 1.7 2 GHz radio 2.3
wifi0: Use hw queue 1 for WME_AC_BE traffic
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 2 for WME_AC_VI traffic
wifi0: Use hw queue 3 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
wifi0: Atheros 5212: mem=0xbfef0000, irq=21

Help me, Obi-Wan Kenobi; you're my only hope.

I got the same problem.
Any workaround?!

Can you be more specific?  Do you have a setup where the card works and one where it does not?  Is your dmesg the same?

What kernel is each machine running? Can you do a "uname -a" on both the working one and the non-working one?  I suspect the kernels might be different.
You might also have better luck with kamikaze svn trunk (compiled from source)... I believe the trunk uses a much newer kernel than 7.09.

What's the output of "lspci -vv"?

sorry, that was an misplaced entry.
i solved the problem already.

but thank you