Larry Finger wrote: > On 11/13/2009 06:15 PM, William Bourque wrote: >> Larry Finger wrote: >>> Based on a suggestion by Matthew Garrett, please try the patch below. >>> >>> Thanks, >>> >>> Larry >>> >>> ================= >>> >>> >>> Index: wireless-testing/drivers/net/wireless/b43/main.c >>> =================================================================== >>> --- wireless-testing.orig/drivers/net/wireless/b43/main.c >>> +++ wireless-testing/drivers/net/wireless/b43/main.c >>> @@ -43,6 +43,7 @@ >>> #include <linux/io.h> >>> #include <linux/dma-mapping.h> >>> #include <asm/unaligned.h> >>> +#include <linux/pm_qos_params.h> >>> >>> #include "b43.h" >>> #include "main.h" >>> @@ -3881,6 +3882,8 @@ redo: >>> if (!dev || b43_status(dev) < B43_STAT_STARTED) >>> return dev; >>> >>> + pm_qos_update_requirement(PM_QOS_CPU_DMA_LATENCY, "b43", >>> + PM_QOS_DEFAULT_VALUE); >>> /* Cancel work. Unlock to avoid deadlocks. */ >>> mutex_unlock(&wl->mutex); >>> cancel_delayed_work_sync(&dev->periodic_work); >>> @@ -3963,6 +3966,9 @@ static int b43_wireless_core_start(struc >>> /* We are ready to run. */ >>> b43_set_status(dev, B43_STAT_STARTED); >>> >>> + /* Set the maximum DMA latency */ >>> + pm_qos_update_requirement(PM_QOS_CPU_DMA_LATENCY, "b43", 200); >>> + >>> /* Start data flow (TX/RX). */ >>> b43_mac_enable(dev); >>> b43_write32(dev, B43_MMIO_GEN_IRQ_MASK, dev->irq_mask); >>> >>> >>> >>> >> Well, this one did not solve the problem but it certainly did help! >> >> It took me some effort to make it bug again... I worked fine for 5 >> minutes, I was able to browse the web and such. I was also >> removed/inserted the module a few times. It finally crashed when I tried >> to transfert a file of several MB. >> >> Maybe the 200ms delay should be less (or more?) I think I will try to >> change it for some arbitrary number, just to see if it helps. > > You should try decreasing it. That parameter is used by 2 drivers in the > kernel: > ipw2100 with a value of 175 and e1000e with a value of 55. I would expect the > value for the other wireless device to be closer that that for a wired > interface. Please try 150. If that also fails, try 100. BTW, the parameter is > in > usec, not msec. > > I'm finally encouraged that we might figure out this problem. > > Larry > > > Larry >
Ok, I tried with value of 150, 100 already and I'm recompiling to see the result with 175 and 125. 150us seems to give me the best result. As with 200 I could use the wireless for several minutes and insert/remove the module. However it failed when I tried to transfert a big file at full speed over LAN. So for some reason, low speed seems to work ok (althought I ad some PHY Transmission error, but I suppose it is not related). 100us is worst than the unpatched code. The wireless fails as soon as I bring up the interface and the DMA errors then repeat at a very high rate. Then, when I try to remove the module, "modprobe" is having a very bad time. On fist try, it took around 3 minutes to be able to remove the module and on the second ttry, the machine just hanged (couldn't see if there wasan oops or something). In the mean time, I could tell that the DMA error where still pilling up, as the wireless LED was furiously flashing from red to blue (usual behavior on an error). I'll try 175usec first, then 125usec to see if anything better happen but I doubt so... I think the patch just fixed a part of the problem, not the whole. Oh and I didn't bother posting the output of dmesg as it is the exact same thing again but if you need it I kept it. - William _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
