On Feb 14, 2008 8:43 AM, Kalle Valo <[EMAIL PROTECTED]> wrote: [...] > > other users reported it too as Luca Olivetti pointed out. and it > > seems like the problem and fix is described here: > > > > http://internettablettalk.com/forums/showpost.php?p=134914&postcount=15 > > > > at least for the 770 the fix seems to exist, > > What I read from the link, someone had written a workaround to try > again whenever the chip is responding. That would good a feature, but > I would like to get more information about what's happening in this > case.
I'm sorry. For some unknown reason, I thought that I notified you about this problem long ago, but appears that we only discussed this issue privately with Frantisek Dufka :( I encountered this problem when I was checking what is the maximum McBSP clock frequency that could be used reliably on Nokia 770 to speed up WLAN performance. To do this stability test, I just put the device on charger, established wlan connection and started a test script which repeatedly executed wget to download a large file, piping it to md5sum and verifying that the file always gets received correctly. That's probably one of the most simple stress tests that can be done :) People on ITT, who are suffering from this disconnection problem are running bittorent client software which probably stresses network to a much higher extent. Having kept this simple test running, I noticed that wlan network is getting stuck eventually. Sometimes very soon and sometimes after a long time. Checking dmesg log revealed the following lines: [84936.145721] We haven't got a READY interrupt from WAKEUP. (firmware crashed?) [84940.419342] TX dropped [84940.419433] TX dropped The symptoms are similar to what other people reported as https://bugs.maemo.org/show_bug.cgi?id=329 Initially I thought that it was the effect of overclocking, but could reproduce the problem even after going back to the standard frequency. With a simple patch that just retries operation on such error, wireless connection got stable. After a long test with the test script, no problems were detected. The following lines could be occasionally seen in dmesg log and it proves that there were potential connection drops encountered, but they all did not cause any troubles in reality (MD5 of downloaded file was always OK): [50559.494232] Dynamic PSM [50559.494323] PSM timeout 1000 ms [50622.038146] We haven't got a READY interrupt from WAKEUP. (firmware crashed?) [50622.038269] Try again... [50622.038330] succeeded!!! I'm attaching the same patch here. It is not very clean, but it does the job (for Nokia 770). And I have encountered other problems with WLAN driver that are yet to be solved. For example, sometimes speed drops to ~30KB/s (that's still an unresolved mystery to me). Also CPU usage is very high because of busyloop when waiting till DMA transfer is done. Tasklet, which executes the code can't be easily preempted, as far as I understand kernel documentation. Maybe it is possible to split tasklet into several parts, one of them could be responsible for initiating DMA transfer, the other could be activated on DMA transfer completion? This all is important for video streaming as any excessive CPU resources consumption by WLAN driver negatively impacts video playback performance.
n770_wlan_retry_on_wake_error.diff
Description: Binary data
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
