[PATCH stable 4/4] b43: Workaround DMA quirks
Some mainboards/CPUs don't allow DMA masks bigger than a certain limit.
Some VIA crap^h^h^h^hdevices have an upper limit of 0x. So in this
case a 64-bit b43 device would always fail to acquire the mask.
Implement a workaround to fallback to lower DMA mask, as we can always
also support a lower mask.
This patch is in wireless-testing.git, commit
91725545159f81f1c9dc738dfc329199583f649a
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25/drivers/net/wireless/b43/dma.c
===
--- linux-2.6.25.orig/drivers/net/wireless/b43/dma.c2008-04-19
18:29:16.0 +0200
+++ linux-2.6.25/drivers/net/wireless/b43/dma.c 2008-04-23 18:35:33.0
+0200
@@ -819,12 +819,24 @@ static u64 supported_dma_mask(struct b43
if (tmp B43_DMA32_TXADDREXT_MASK)
return DMA_32BIT_MASK;
return DMA_30BIT_MASK;
}
+static enum b43_dmatype dma_mask_to_engine_type(u64 dmamask)
+{
+ if (dmamask == DMA_30BIT_MASK)
+ return B43_DMA_30BIT;
+ if (dmamask == DMA_32BIT_MASK)
+ return B43_DMA_32BIT;
+ if (dmamask == DMA_64BIT_MASK)
+ return B43_DMA_64BIT;
+ B43_WARN_ON(1);
+ return B43_DMA_30BIT;
+}
+
/* Main initialization function. */
static
struct b43_dmaring *b43_setup_dmaring(struct b43_wldev *dev,
int controller_index,
int for_tx,
enum b43_dmatype type)
@@ -979,42 +991,61 @@ void b43_dma_free(struct b43_wldev *dev)
b43_destroy_dmaring(dma-tx_ring1);
dma-tx_ring1 = NULL;
b43_destroy_dmaring(dma-tx_ring0);
dma-tx_ring0 = NULL;
}
+static int b43_dma_set_mask(struct b43_wldev *dev, u64 mask)
+{
+ u64 orig_mask = mask;
+ bool fallback = 0;
+ int err;
+
+ /* Try to set the DMA mask. If it fails, try falling back to a
+* lower mask, as we can always also support a lower one. */
+ while (1) {
+ err = ssb_dma_set_mask(dev-dev, mask);
+ if (!err)
+ break;
+ if (mask == DMA_64BIT_MASK) {
+ mask = DMA_32BIT_MASK;
+ fallback = 1;
+ continue;
+ }
+ if (mask == DMA_32BIT_MASK) {
+ mask = DMA_30BIT_MASK;
+ fallback = 1;
+ continue;
+ }
+ b43err(dev-wl, The machine/kernel does not support
+ the required %u-bit DMA mask\n,
+ (unsigned int)dma_mask_to_engine_type(orig_mask));
+ return -EOPNOTSUPP;
+ }
+ if (fallback) {
+ b43info(dev-wl, DMA mask fallback from %u-bit to %u-bit\n,
+ (unsigned int)dma_mask_to_engine_type(orig_mask),
+ (unsigned int)dma_mask_to_engine_type(mask));
+ }
+
+ return 0;
+}
+
int b43_dma_init(struct b43_wldev *dev)
{
struct b43_dma *dma = dev-dma;
struct b43_dmaring *ring;
int err;
u64 dmamask;
enum b43_dmatype type;
dmamask = supported_dma_mask(dev);
- switch (dmamask) {
- default:
- B43_WARN_ON(1);
- case DMA_30BIT_MASK:
- type = B43_DMA_30BIT;
- break;
- case DMA_32BIT_MASK:
- type = B43_DMA_32BIT;
- break;
- case DMA_64BIT_MASK:
- type = B43_DMA_64BIT;
- break;
- }
- err = ssb_dma_set_mask(dev-dev, dmamask);
- if (err) {
- b43err(dev-wl, The machine/kernel does not support
- the required DMA mask (0x%08X%08X)\n,
- (unsigned int)((dmamask 0xULL) 32),
- (unsigned int)(dmamask 0xULL));
- return -EOPNOTSUPP;
- }
+ type = dma_mask_to_engine_type(dmamask);
+ err = b43_dma_set_mask(dev, dmamask);
+ if (err)
+ return err;
err = -ENOMEM;
/* setup TX DMA channels. */
ring = b43_setup_dmaring(dev, 0, 1, type);
if (!ring)
goto out;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH stable 1/4] ssb: Fix all-ones boardflags
From: Larry Finger [EMAIL PROTECTED] In the SSB SPROM a field set to all ones means the value is not defined in the SPROM. In case of the boardflags, we need to set them to zero to avoid confusing drivers. Drivers will only check the flags by ANDing. This patch is in wireless-testing.git, commit d30cdf8a251e88e58bc566f5acaa9eb97ac102e9 Signed-off-by: Larry Finger [EMAIL PROTECTED] Signed-off-by: Gabor Stefanik [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] Index: linux-2.6.25/drivers/ssb/pci.c === --- linux-2.6.25.orig/drivers/ssb/pci.c 2008-04-17 17:11:28.0 +0200 +++ linux-2.6.25/drivers/ssb/pci.c 2008-04-19 17:56:54.0 +0200 @@ -482,6 +482,11 @@ static int sprom_extract(struct ssb_bus goto unsupported; } + if (out-boardflags_lo == 0x) + out-boardflags_lo = 0; /* per specs */ + if (out-boardflags_hi == 0x) + out-boardflags_hi = 0; /* per specs */ + return 0; unsupported: ssb_printk(KERN_WARNING PFX Unsupported SPROM revision %d ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH stable 3/4] b43: Add more btcoexist workarounds
This adds more workarounds for devices with broken BT bits.
This patch is in wireless-testing.git, commit
4b43b16f74b362d4d2ce7df5b761eb838dfd5d32
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25/drivers/net/wireless/b43/main.c
===
--- linux-2.6.25.orig/drivers/net/wireless/b43/main.c 2008-04-19
18:32:08.0 +0200
+++ linux-2.6.25/drivers/net/wireless/b43/main.c2008-04-19
18:32:08.0 +0200
@@ -4009,6 +4009,12 @@ static int b43_one_core_attach(struct ss
return err;
}
+#define IS_PDEV(pdev, _vendor, _device, _subvendor, _subdevice)
( \
+ (pdev-vendor == PCI_VENDOR_ID_##_vendor) \
+ (pdev-device == _device) \
+ (pdev-subsystem_vendor == PCI_VENDOR_ID_##_subvendor)\
+ (pdev-subsystem_device == _subdevice) )
+
static void b43_sprom_fixup(struct ssb_bus *bus)
{
struct pci_dev *pdev;
@@ -4022,10 +4028,9 @@ static void b43_sprom_fixup(struct ssb_b
bus-sprom.boardflags_lo |= B43_BFL_PACTRL;
if (bus-bustype == SSB_BUSTYPE_PCI) {
pdev = bus-host_pci;
- if (pdev-vendor == PCI_VENDOR_ID_BROADCOM
- pdev-device == 0x4318
- pdev-subsystem_vendor == PCI_VENDOR_ID_ASUSTEK
- pdev-subsystem_device == 0x100F)
+ if (IS_PDEV(pdev, BROADCOM, 0x4318, ASUSTEK, 0x100F) ||
+ IS_PDEV(pdev, BROADCOM, 0x4320, LINKSYS, 0x0015) ||
+ IS_PDEV(pdev, BROADCOM, 0x4320, LINKSYS, 0x0013))
bus-sprom.boardflags_lo = ~B43_BFL_BTCOEXIST;
}
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH stable 2/4] b43: Workaround invalid bluetooth settings
This adds a workaround for invalid bluetooth SPROM settings
on ASUS PCI cards.
This will stop the microcode from poking with the BT GPIO line.
This fixes data transmission on this device, as the BT GPIO line
is used for something TX related on this device
(probably the power amplifier or the radio).
This also adds a modparam knob to help debugging this in the future,
as more devices with this bug may show up.
This patch is in wireless-testing.git, commit
5e0fa73f3f6d2aea9c0498dc8d7e621c8fb9e6aa
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: linux-2.6.25/drivers/net/wireless/b43/main.c
===
--- linux-2.6.25.orig/drivers/net/wireless/b43/main.c 2008-04-17
17:11:26.0 +0200
+++ linux-2.6.25/drivers/net/wireless/b43/main.c2008-04-19
17:58:40.0 +0200
@@ -78,6 +78,11 @@ static int modparam_nohwcrypt;
module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
MODULE_PARM_DESC(nohwcrypt, Disable hardware encryption.);
+static int modparam_btcoex = 1;
+module_param_named(btcoex, modparam_btcoex, int, 0444);
+MODULE_PARM_DESC(btcoex, Enable Bluetooth coexistance (default on));
+
+
static const struct ssb_device_id b43_ssb_tbl[] = {
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 5),
SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 6),
@@ -3339,6 +3344,8 @@ static void b43_bluetooth_coext_enable(s
struct ssb_sprom *sprom = dev-dev-bus-sprom;
u32 hf;
+ if (!modparam_btcoex)
+ return;
if (!(sprom-boardflags_lo B43_BFL_BTCOEXIST))
return;
if (dev-phy.type != B43_PHYTYPE_B !dev-phy.gmode)
@@ -3350,11 +3357,13 @@ static void b43_bluetooth_coext_enable(s
else
hf |= B43_HF_BTCOEX;
b43_hf_write(dev, hf);
- //TODO
}
static void b43_bluetooth_coext_disable(struct b43_wldev *dev)
-{ //TODO
+{
+ if (!modparam_btcoex)
+ return;
+ //TODO
}
static void b43_imcfglo_timeouts_workaround(struct b43_wldev *dev)
@@ -4002,6 +4011,8 @@ static int b43_one_core_attach(struct ss
static void b43_sprom_fixup(struct ssb_bus *bus)
{
+ struct pci_dev *pdev;
+
/* boardflags workarounds */
if (bus-boardinfo.vendor == SSB_BOARDVENDOR_DELL
bus-chip_id == 0x4301 bus-boardinfo.rev == 0x74)
@@ -4009,6 +4020,14 @@ static void b43_sprom_fixup(struct ssb_b
if (bus-boardinfo.vendor == PCI_VENDOR_ID_APPLE
bus-boardinfo.type == 0x4E bus-boardinfo.rev 0x40)
bus-sprom.boardflags_lo |= B43_BFL_PACTRL;
+ if (bus-bustype == SSB_BUSTYPE_PCI) {
+ pdev = bus-host_pci;
+ if (pdev-vendor == PCI_VENDOR_ID_BROADCOM
+ pdev-device == 0x4318
+ pdev-subsystem_vendor == PCI_VENDOR_ID_ASUSTEK
+ pdev-subsystem_device == 0x100F)
+ bus-sprom.boardflags_lo = ~B43_BFL_BTCOEXIST;
+ }
}
static void b43_wireless_exit(struct ssb_device *dev, struct b43_wl *wl)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Tons of interrupts on driver load
Hello, First some background: I am currently running latest mainline from git. This kernel suffers from a scheduler? issue where keys get stuck and audio skips every now and then. Confirmed to be triggered by a commit named sched: fix fair sleepers. I am currently on wired lan and have the wireless disabled via hardware button. The b43 module is still loaded. While trying to find what these hickups come from I ran watch --interval .1 cat /proc/interrupts. I can see there that the b43 disappears, gets unloaded probably, and then reappears. When b43 reappears in the interrupt listing, that line generates some 25000 irq's within a fraction of a second. Is this a bug somewhere or by design? Note that I wouldn't ever see this if the kernel was behaving as normal. I have no idea if the b43 driver has always behaved like this. I could of course test an older kernel on request. regards, Richard ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Tons of interrupts on driver load
On Thu, 2008-04-24 at 21:48 +0200, Richard Jonsson wrote: Hello, First some background: I am currently running latest mainline from git. This kernel suffers from a scheduler? I think this question is more suited for LKML. While trying to find what these hickups come from I ran watch --interval .1 cat /proc/interrupts. I can see there that the b43 disappears, gets unloaded probably, and then reappears. You should probably show the exact contents of /proc/interrupts and provide some details about the systems (architecture, CPU speed, contents of /proc/sched_debug, lspci output, dmesg output). When b43 reappears in the interrupt listing, that line generates some 25000 irq's within a fraction of a second. Is this a bug somewhere or by design? It's possible that the interrupt count is not shown when the driver disappears, but is not reset to 0. Once the interrupt has a handler, the original count is shown. Note that I wouldn't ever see this if the kernel was behaving as normal. I have no idea if the b43 driver has always behaved like this. I could of course test an older kernel on request. That's probably a good idea, as the LKML folks would suspect something they know least about, i.e. the hardware. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Feedback on ASUS WL-138G V2 on x86_64
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 ...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 InsteadI 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'tthe 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=0x 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 That passage gets repeated to dmesg multiple times in a rapid fire machinegun type of way. Apart from the fact I probably shouldn't be @ 2.6.24 with this (I'll move to 2.6.25-git5 next reboot), can someone please advise me on where to head next hunting this? Regards, Donald _ Are you paid what you're worth? Find out: SEEK Salary Centre http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2Fcareer%2Dresources%2Fsalary%2Dcentre%2F%3Ftracking%3Dsk%3Ahet%3Asc%3Anine%3A0%3Ahot%3Atext_t=764565661_r=OCT07_endtext_salary_m=EXT ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH V3] ssb-sprom: Update README
Michael, This version modifies the setting of the patch to ssb_sprom to handle systems with multiple SSB-based devices. Larry --- Index: ssb_sprom/README === --- ssb_sprom.orig/README +++ ssb_sprom/README @@ -13,3 +13,106 @@ Requirements 1)C99 compatible compiler. + +Usage +- + +The contents of the sprom are exposed to the user in sysfs. This +tool can, in principle, read and write the sprom in place; however, +making a mistake during sprom writing could render your device +unusable. For this reason, we recommend copying the sprom contents +to disk as the first step. This copy can then be modified until it +contains the desired new information. Only then and with caution +should the sprom be rewritten. DO NOT MAKE ANY CHANGES UNLESS YOU +KNOW WHAT YOU ARE DOING You have been warned!!! + +Obtaining a disk copy of the sprom contents +--- + +This file name for the sprom contents depends on the bus layout of +the specific computer being used and will be something like + +/sys/devices/pci:00/:00:0d.0/:04:00.0/ssb_sprom + +It is not recommended that you try to type the name. Instead, you +should use the following commands to get and check the path for the +sprom file: + +SSB_SPROM=$(find /sys -name ssb_sprom) +echo $SSB_SPROM + +If the echo command only results in a single instance of /sys/..., +you may proceed. For systems with more than one SSB-based interface, +there will be such a string for each, and the command that sets the +SSB_SPROM symbol will have to be changed. In the name above, the +sequence states that this device is attached to the 0'th PCI bus via +bridge 0d.0 and is device 04:00.0 on that bridge. To find which of +your SSB devices to select, use the 'lspci -v' command. On my system, +the first line of such output for my interface is 04:00.0 Network +controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 02). +To select only this device, one would use + +SSB_SPROM=$(find /sys -name ssb_sprom | grep 04:00.0) +echo $SSB_SPROM + +Of course, the 04:00.0 needs to match your system, and check the +output value to determine that there is now a single instance of +/sys... and that the path matches the device whose SPROM is to be +changed. If not, adjust the string after 'grep' accordingly. + +Once the SSB_SPROM variable matches the path to ssb_sprom for your +device, get a working copy of the sprom contents with + +sudo cat $SSB_SPROM ssb_sprom_copy + +Modifying the contents of the working copy +-- + +You may now see the contents of your sprom with the command + +ssb-sprom -i ssb_sprom_copy -P + +As an example, let us suppose that you have purchased a Dell mini-pci +card to use in an HP laptop. The HP BIOS refuses to use the card when +the pcivendor is Dell (code 0x1028), not HP (code 0x103C). From the +information provided by an ssb-prom --help command, we learn that +the switch needed to change this vendor code is --subv. To change +that code, we use the command + +ssb-sprom -i ssb_sprom_copy -o new_ssb_sprom_copy --subv 0x103C + +to write the HP vendor ID to our working copy. I use different +input and output files so as not to destroy the original. If further +changes are needed, for example the PCI product ID, the command + +ssb-sprom -i new_ssb_sprom_copy -o new_ssb_sprom_copy --subp 0x137C + +would be used. Note that the input and output files may be the same. +Once you think you have updated correctly, use + +ssb-sprom -i new_ssb_sprom_copy -P + +to check the contents. + +Rewriting the sprom contents + + +Once the sprom contents are the way you want them, and presumably +correct, you are ready to rewrite the file. First, use + +echo $SSB_SPROM + +to ensure that this symbol still contains the SPROM path. If not, +then it will have to be reloaded as discussed above. + +You are then ready to rewrite the sprom with + +sudo cp new_ssb_sprom_copy $SSB_SPROM + +Once again, you are urged to be absolutely certain of the contents +of the working copy BEFORE taking this step. If your interface +becomes unusable as a result of writing incorrect data into the +sprom, the responsibility is YOURS. Once again, you have been warned. + +-- + ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Inconsistency in handling board revision
Michael, I have discovered that both sprom_extract_r123() in the ssb driver, and ssb-sprom use a two-byte quantity to extract the board revision. In the specifications detailed in http://bcm-v4.sipsolutions.net/SPROM, a single-byte is used for this parameter. It is unlikely that this causes any serious difficulties; however, at least one fixup depends on the board revision, and I wanted to be certain that you were aware of the situation. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Feedback on ASUS WL-138G V2 on x86_64
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 InsteadI 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'tthe 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=0x 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 Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
