Donald, kala mazoo wrote: > Greets, > I've spent the last too many hours trying to recreate > exactly what I'd done on the 32bit machine, on this box - an > AMD/x2 64bit unit. The software instance installed is a > 'pure_64bit' type with no 32bit compat at all. The board is > using the nvidia CK804 chipset. > > Forgetting about the hardware for a moment, I simply could > *not* get what I'd built/installed on the 32bit machine, to even > build on this 64bit thing. (I still don't believe this ;) That is to > say, I attempted to get this 64bit thing to the same place...ie; > > linux-2.6.25 > compat-wireless-2008-04-20 + Michael's patch series 'mb-wl-20080420-1630' > > > ..has me beat at the moment. The 2.6.25 kernel builds and runs fine > in pristine form, but the compat-wireless+patches updates are > producing modules with unknown symbols, and hence will not load. > In b43 mod's case, it claimed to have unknown symbols ; > > ssb_bus_resume > ssb_bus_suspend > ssb_bus_pcmciabus_register
I don't know why the symbols are unknown, but you should not have to use compat-wireless. For the BCM4318, even plain-vanilla 2.6.24 has everything that your card should need, except for Michael's patch for the bad SPROM. > > ...although these are clearly available and present in ssb.o - > nothing like this occurred with the 32bit build. Curious... > > So I abandoned this bent in an effort to remain unconcerned. > > What I'd done -should've- worked though.... > > Instead....I fathomed out the following logic -- on the 32bit machine > with a pristine 2.6.24 built and installed, b43 will *not* work on these > asus wl-138g v2 cards and now we know why. We also know that > if one does -nothing- to the software set, but instead changes the > ssb_sprom settings on the card itself, b43 *will* then start to work > the card on 32bit. Ergo, I should try see if this so on 64bit... > > It isn't....the above logic doesn't hold true on 64bit. With a fresh & > clean 2.6.24 kernel installed and running, and with the sprom image > Stefanik provided (the same one used to gain clues on the 32bit box) > written into the card, b43 behaves exactly the same as it did before - > nada... > ....then I recalled concerns over IOMMU functionality raised > before, so I rebooted with the iommu=off kernel bootparam and tried > again. It still doesn't work, however..... following this sequence; > > /config radio layer/ > > iwconfig wlan0 essid dfg > iwconfig wlan0 channel 1 > iwconfig wlan0 key 1122334455 > > /check result/ > > iwconfig wlan0 > > wlan0 IEEE 802.11g ESSID:"dfg" > Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated > Tx-Power=27 dBm > Retry min limit:7 RTS thr:off Fragment thr=2346 B > Encryption key:1122-3344-55 > Link Quality:0 Signal level:0 Noise level:0 > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > /seems ok, config IP layer and bring it up/ > > ifconfig wlan0 172.16.1.111 netmask 255.255.255.0 up > > /check result/ > > ifconfig wlan0 > > wlan0 Link encap:Ethernet HWaddr 00:14:A5:0C:8D:EF > inet addr:172.16.1.111 Bcast:172.16.1.255 Mask:255.255.255.0 > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > / all looks sane, now this.../ > > iwlist wlan0 scanning > > wlan0 No scan results > > =====dmesg output====== > > HW CONFIG: channel=11 freq=2462 phymode=2 > phy0: TX to low-level driver (len=42) FC=0x0040 DUR=0x0000 > A1=ff:ff:ff:ff:ff:ff > A2=00:14:a5:0c:8d:ef A3=ff:ff:ff:ff:ff:ff > WARNING: at drivers/net/wireless/b43/dma.c:1095 parse_cookie() > Pid: 0, comm: swapper Tainted: PF 2.6.24 #1 > > Call Trace: > [] :b43:b43_dma_handle_txstatus+0xaa/0x460 > [] :b43:b43_debugfs_log_txstat+0x3e/0xe0 > [] :b43:b43_interrupt_tasklet+0x28b/0x7f0 > [] tasklet_action+0x48/0xb0 > [] __do_softirq+0x69/0xe0 > [] call_softirq+0x1c/0x30 > [] do_softirq+0x35/0x90 > [] irq_exit+0x55/0x60 > [] do_IRQ+0x80/0x100 > [] default_idle+0x0/0x40 > [] ret_from_intr+0x0/0xa > [] default_idle+0x29/0x40 > [] cpu_idle+0x70/0xe0 > > ======================== If you apply the patch for DMA quirks that Michael listed in http://lists.berlios.de/pipermail/bcm43xx-dev/2008-April/007395.html, do you still get this warning? Doing 30-bit DMA on 64-bit machines can be dicey. How much RAM does the system have? Did you build ssb and b43 with debugging enabled? If not, please do, and send all messages from dmesg that contain either ssb or b43. Larry _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
