<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Leonardo Pereira Santos wrote:<br>
<blockquote type="cite" cite="mid200306301158.02287.lsantos@pd3.com.br">
  <pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(...)
  </pre>
  <blockquote type="cite">
    <pre wrap="">IMHO i think XI-626 need a PCI revision 2.1 or 2.2 ? Iam using a boards
that pass PCI revision requirements and not have those problems (d-com
and sparklan wl-360, avreage 10-15 associated clients) . In some routers
iam also using low cost motherboards (with via C3 on board) with no
problems ... IMHO maybe coming time turn off  old p100 router and
upgrade it, to pass basic PCI bus requirements with the wlan card ... I
using my own patch to solve BAP busy timeouts, maybe its a goal or me
(from pre 0.0.1 to current 0.0.3) ...
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I guess a C3 Gigapro uP is way faster than a P100, or we might just get some 
bad luck and the C3 is just fast enought... Ok, anyway, what about this ptach 
of yours? Can you send it to the list? Is it against hostap-0.03?

Cheers!

  </pre>
  <blockquote type="cite">
    <pre wrap="">Jiri

_______________________________________________
HostAP mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HostAP@shmoo.com">HostAP@shmoo.com</a>
<a class="moz-txt-link-freetext" href="http://lists.shmoo.com/mailman/listinfo/hostap">http://lists.shmoo.com/mailman/listinfo/hostap</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
- -- 

Leonardo Pereira Santos
Engenheiro de Projetos
PD3 Tecnologia
av. Par&aacute; 330/202
(51) 3337 1237

Today Fortune tells us:
        It is a profoundly erroneous truism, repeated by all copy-books and
by eminent people when they are making speeches, that we should cultivate
the habit of thinking about what we are doing.  The precise opposite is the
case.  Civilization advances by extending the numbers of important operations
which we can perform without thinking about them.  Operations of thought are
like cavalry charges in battle -- they are strictly limited in number, they
require fresh horses, and must only be made at decisive moments.
                -- Alfred North Whitehead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/AE/58uAMCTjfaxIRAizyAJ4tP/lTlblQqJ6yCxPfrlpezcEI1ACcCd/z
/oW5+FlhnsBKNZoLYhebBvM=
=DpRt
-----END PGP SIGNATURE-----

_______________________________________________
HostAP mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HostAP@shmoo.com">HostAP@shmoo.com</a>
<a class="moz-txt-link-freetext" href="http://lists.shmoo.com/mailman/listinfo/hostap">http://lists.shmoo.com/mailman/listinfo/hostap</a>

  </pre>
</blockquote>
Hello<br>
<br>
I have posted this patch already, but OK. I using it with all hostap
versions i use. Jouni had done related solutuon in one from the latest
patches but BAP0 timeout happen for me again, so i think something was
wrong ....<br>
<br>
There is a HFA384X_BAP_BUSY_TIMEOUT define that define count of retries
to get&nbsp; BAP0 ready status. The timeout betwen retries are defined by
the udelay function. I begin experiment with those values:<br>
<br>
pre 0.0.1 cvs versions was defined number of retries 5000 and udealy
betwen retries 1usec. I had problem when i setup hostap driver with the
scripts (some values as SSID RTS etc was not setup correctly), and when
i start ping flooding. I change retries to 10000 and all related
problems gone !<br>
0.0.1 version has same settings as pre 0.0.1 and i have changet only
retries to 10000<br>
0.0.3 ( 0.0.2 i not used) version have retries 5000 and the delay was
changet to 10usec. So for first look it seems to be ok because the
maximum timeout are higer that my previous settings. But it was not
right ! Due to some reason the timeout scaling by 10usec was not good
and my log sometime during hight speed transfers got old know BAP0 busy
timeout message ... I have reverted old working algorithm and from that
time i not had any from those messages.<br>
<br>
Conclusion<br>
IMHO 10usec scaling to get BAP0 ready status are much long and cause
CPU saturation whish can result at slover CPU's some problems ....<br>
<br>
BTW I using three routers with Via C3 onboard (an ECS micro ATX
manboard wit SIS chipset) , one with Celeron 1.3 Ghz and a Via KT-133
chipset. Wlan cards are d-com wl-360 PCI and sparklan wl-360f PCI,
firmware 1.5.6 and 1.7.4 , Redhat 8.0 with latest updates ...<br>
<br>
The patch i used against 0.0.3 :<br>
<br>
--- ./hostap-0.0.3/driver/modules/hostap_hw.c&nbsp;&nbsp; 2003-06-25
07:10:40.000000000 +0200<br>
+++ ./hostap-0.0.3.work/driver/modules/hostap_hw.c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2003-06-26
10:04:13.000000000 +0200<br>
@@ -147,9 +147,9 @@<br>
<br>
&nbsp;/* ca. 1 usec */<br>
&nbsp;#define HFA384X_CMD_BUSY_TIMEOUT 5000<br>
+#define HFA384X_BAP_BUSY_TIMEOUT 10000<br>
<br>
&nbsp;/* ca. 10 usec */<br>
-#define HFA384X_BAP_BUSY_TIMEOUT 5000<br>
&nbsp;#define HFA384X_INIT_TIMEOUT 50000<br>
&nbsp;#define HFA384X_CMD_COMPL_TIMEOUT 20000<br>
&nbsp;#define HFA384X_DL_COMPL_TIMEOUT 1000000<br>
@@ -578,7 +578,7 @@<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while ((HFA384X_INW(o_off) &amp; HFA384X_OFFSET_BUSY)
&amp;&amp; tries &gt; 0) {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tries--;<br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; udelay(10);<br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; udelay(1);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return (HFA384X_INW(o_off) &amp; HFA384X_OFFSET_BUSY);<br>
&nbsp;}<br>
</body>
</html>