Benno Senoner wrote:
2008/2/14, Kalle Valo [EMAIL PROTECTED]:
Most probably the connection would recover after a while, and the
while here being several minutes with the default TCP settings.
You think those time outs are really that long ?
Yeah, they are quite long. I have heard about long
ext Siarhei Siamashka [EMAIL PROTECTED] writes:
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
ext Benno Senoner [EMAIL PROTECTED] writes:
An easy way to confirm, if this is a TCP problem or something else,
is to run ping in the background and see how long timeouts (ie. how
much you see packet loss) you get with it. ICMP ping does not have
any of problems that TCP has.
Yes I did and
ext Frantisek Dufka [EMAIL PROTECTED] writes:
[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).
Not seeing
Kalle Valo wrote:
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
ext Siarhei Siamashka [EMAIL PROTECTED] writes:
A while ago I looked for various kernel docs to see what's happening in the
wlan driver and what can be done to reduce cpu load. My impression was that
tasklet can be only preempted by hardware interrupts, so it is impossible to
sleep in it and
On 22 February 2008, Frantisek Dufka wrote:
Kalle Valo wrote:
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
Kalle Valo wrote:
ext Siarhei Siamashka [EMAIL PROTECTED] writes:
A while ago I looked for various kernel docs to see what's happening in the
wlan driver and what can be done to reduce cpu load. My impression was that
tasklet can be only preempted by hardware interrupts, so it is impossible
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=134914postcount=15
at least for the 770 the fix
Siarhei Siamashka wrote:
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 think it was discussed also in the Memory corruption during WLAN use
bug too -
Hi,
on Roaming: I have quite good experience with roaming when using
unencrypted wifi and securing it with OpenVPN. In this setup you have
your access point connected to a firewall (with OpenVPN installed) and
do encryption from wifi device to the OpenVPN enabled firewall instead
of to the AP.
ext Benno Senoner [EMAIL PROTECTED] writes:
The question is could it be that the socket remains stuck due to the
roaming and is not able to recover ?
TCP doesn't fit wireless networks that well, it usually takes a long
time to cover from packet lost. Most probably what happens for you is
ext Frank Banul [EMAIL PROTECTED] writes:
I'm a home user with two access points. I've noticed that the N810 holds on
to the connection with the established AP far longer than the 770 seemed to.
I expect to never see low strength signals as the two APs cover my home
nicely. But I have not
I'm a home user with two access points. I've noticed that the N810 holds on
to the connection with the established AP far longer than the 770 seemed to.
I expect to never see low strength signals as the two APs cover my home
nicely. But I have not noticed any problems associated with this apparent
ext Luca Olivetti [EMAIL PROTECTED] writes:
Sometimes it even happens that the operator when roaming and wanting to
use the N800
the VNC session got stuck and nothing works, so he has to power cycle it.
This also happens with no roaming at all (i.e. the connection manager
show the tablet
On Sat, 2008-02-02 at 23:18 +0100, Benno Senoner wrote:
Any suggestions ?
I find this wlan freeze problem a grave bug is this a defect in the
N800 or a software bug ?
One thing you could try is setting up openvpn: N800 as client, the VNC
machine as server: it will secure your VNC connection,
Hi all,
I am trying to solve a big WLAN roaming problem which the N800 experiences
and I think it is of
interest to many as good WLAN responsiveness for the N800(and successors) is
the key
for smooth user experience, so please chime in with your experiences, ideas
how to solve
those problems etc.
En/na Benno Senoner ha escrit:
Sometimes it even happens that the operator when roaming and wanting to
use the N800
the VNC session got stuck and nothing works, so he has to power cycle it.
This also happens with no roaming at all (i.e. the connection manager
show the tablet as associated
Thanks for your information Luca !
what do you mean with t's not possible to transfer any data ?
you mean VNC gets stuck or the whole network layer of the n800 ?
So basically once it gets stuck you cannot even open the brower and access a
webpage ?
Please elaborate.
And with reconnect the the
En/na Benno Senoner ha escrit:
Thanks for your information Luca !
what do you mean with t's not possible to transfer any data ?
that you can't ping, cannot resolve hostname, ssh sessions hangs, can't
load webpages, etc., you get the idae
you mean VNC gets stuck or the whole network layer
20 matches
Mail list logo
