<div dir="ltr">Hi all,<br>sorry for continuing an old discussion:<br><a href="http://lists.maemo.org/pipermail//maemo-developers/2008-February/032389.html">http://lists.maemo.org/pipermail//maemo-developers/2008-February/032389.html</a><br>
<br>I ugraded my N800 to the latest diablo image from nokia and I still have issues with the wi-fi connectivity dying in some situations:<br>basically I have local GUI app on the n800 which communicates with a linux postgresql server on the same LAN<br>
(network is 802.11g 54mbit WEP 128bit). <br>the problem is when I walk out of the access point's coverage area my app freezes when trying to issue an sql query (which is to be expected).<br>when I get back within the wi-fi coverage area (let's say after 10-30secs) sometimes the app works again, sometimes I get the<br>
connection lost banner and then it reconnects and sometimes it disconnects from the wlan.<br>if I reenable the wlan manually clicking on the network icon then after the wlan comes up my sql app starts working again, without the <br>
TCP connection to the SQL server breaking down.<br>Siarhei suggested to recompile the cx3110x driver with a patch that retries to communicate (at that time it was for N770).<br>now the question is: is this patch already integrated in the cx3110x code which comes with the latest diablo release or not ?<br>
is there an updated patch which is specific for the n800/n810 running on diablo ? or was it integrated in the latest cx3110x ?<br>if yes should I use the repository code or the latest tarball ?<br><br>Keep in mind that I am running sliderotate, a tool which allows to rotate the screen by 90degrees<br>
<a href="http://www.internettablettalk.com/forums/showthread.php?t=19447">http://www.internettablettalk.com/forums/showthread.php?t=19447</a><br>I installed it using the install script and after installation the sliderrotate setup app allows to update the kernel<br>
in order to allow support for screen rotation with xrandr. the setup app automatically downloads and installs the modified kernel.<br>(not sure what the modifications are in this case or if it is simply a standard kernel with some options turned on)<br>
now the question is: in order to compile the cx3110x driver what kind of kernel headers do I need to install in order to compile it for the<br>kernel with screen rotation enabled ?<br><br>Or is there a simpler method to allow automatic (fast) reconnect of the wlan when I get back into the wlan coverage area ?<br>
<br>thanks in advance for informations, if you need me to perform some tests on the n800 or provide additional feedback I'll gladly do it.<br>best regards,<br>Benno<br><br><br><br><div class="gmail_quote">2008/2/18 Siarhei Siamashka <span dir="ltr"><<a href="mailto:siarhei.siamashka@gmail.com">siarhei.siamashka@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Feb 14, 2008 8:43 AM, Kalle Valo <<a href="mailto:kalle.valo@nokia.com">kalle.valo@nokia.com</a>> wrote:<br>
[...]<br>
<div class="Ih2E3d">> > other users reported it too as Luca Olivetti pointed out. and it<br>
> > seems like the problem and fix is described here:<br>
> ><br>
> > <a href="http://internettablettalk.com/forums/showpost.php?p=134914&postcount=15" target="_blank">http://internettablettalk.com/forums/showpost.php?p=134914&postcount=15</a><br>
> ><br>
> > at least for the 770 the fix seems to exist,<br>
><br>
> What I read from the link, someone had written a workaround to try<br>
> again whenever the chip is responding. That would good a feature, but<br>
> I would like to get more information about what's happening in this<br>
> case.<br>
<br>
</div>I'm sorry. For some unknown reason, I thought that I notified you<br>
about this problem long ago, but appears that we only discussed this<br>
issue privately with Frantisek Dufka :(<br>
<br>
I encountered this problem when I was checking what is the maximum<br>
McBSP clock frequency that could be used reliably on Nokia 770 to<br>
speed up WLAN performance. To do this stability test, I just put the<br>
device on charger, established wlan connection and started a test<br>
script which repeatedly executed wget to download a large file, piping<br>
it to md5sum and verifying that the file always gets received<br>
correctly. That's probably one of the most simple stress tests that<br>
can be done :)<br>
<br>
People on ITT, who are suffering from this disconnection problem are<br>
running bittorent client software which probably stresses network to a<br>
much higher extent.<br>
<br>
Having kept this simple test running, I noticed that wlan network is<br>
getting stuck eventually. Sometimes very soon and sometimes after a<br>
long time. Checking dmesg log revealed the following lines:<br>
[84936.145721] We haven't got a READY interrupt from WAKEUP. (firmware crashed?)<br>
[84940.419342] TX dropped<br>
[84940.419433] TX dropped<br>
<br>
The symptoms are similar to what other people reported as<br>
<a href="https://bugs.maemo.org/show_bug.cgi?id=329" target="_blank">https://bugs.maemo.org/show_bug.cgi?id=329</a><br>
<br>
Initially I thought that it was the effect of overclocking, but could<br>
reproduce the problem even after going back to the standard frequency.<br>
<br>
With a simple patch that just retries operation on such error,<br>
wireless connection got stable. After a long test with the test<br>
script, no problems were detected. The following lines could be<br>
occasionally seen in dmesg log and it proves that there were<br>
potential connection drops encountered, but they all did not cause any<br>
troubles in reality (MD5 of downloaded file was always OK):<br>
[50559.494232] Dynamic PSM<br>
[50559.494323] PSM timeout 1000 ms<br>
[50622.038146] We haven't got a READY interrupt from WAKEUP. (firmware<br>
crashed?)<br>
[50622.038269] Try again...<br>
[50622.038330] succeeded!!!<br>
<br>
I'm attaching the same patch here. It is not very clean, but it does<br>
the job (for Nokia 770).<br>
<br>
<br>
And I have encountered other problems with WLAN driver that are yet to<br>
be solved. For example, sometimes speed drops to ~30KB/s (that's still<br>
an unresolved mystery to me). Also CPU usage is very high because of<br>
busyloop when waiting till DMA transfer is done. Tasklet, which<br>
executes the code can't be easily preempted, as far as I understand<br>
kernel documentation. Maybe it is possible to split tasklet into<br>
several parts, one of them could be responsible for initiating DMA<br>
transfer, the other could be activated on DMA transfer completion?<br>
This all is important for video streaming as any excessive CPU<br>
resources consumption by WLAN driver negatively impacts video playback<br>
performance.<br>
</blockquote></div><br></div>