Re: [zd1211-devs] [zd1211rw] Driver leaving device in bugged state ?

2006-12-03 Thread athoslnx


it is the same problem that I have! I have resolved plug peripheral after
the pc  start or the reboot!
http://www.nabble.com/file/4430/grep_error_-110.txt grep_error_-110.txt 

Norman Jonas-4 wrote:
 
 Hi,
 
 could it be that zd1211rw ( kernel 2.6.18-rc4 ) leaves the device in a
 bugged state ? The reason why I think so is that :
 
 - When I power on the computer everything is fine and the driver module
 gets loaded properly
 
 - On every reboot afterwards there are error messages like this
 usb 5-7: device descriptor read/64, error -110
 and the driver doesn't load
 
 - When the device is removed and plugged in everything works fine again
 ( like when powering on ... )
 
 - Another driver ( ndiswrapper ) for the same device works fine under
 all circumstances and never causes the -110 bug.
 
 - That bug simply starts appears only when zd1211rw has been loaded.
 
 And I am not the only one experiencing it :
 
 http://www.mail-archive.com/zd1211-devs@lists.sourceforge.net/msg00293.html
 
 Quote :
 
 I rebooted my computer with acpi=off and 
 didn't start my cpufreq userspace program 'powernowd'. My usb dongle was 
 still plugged in and it hasn't been properly initialized at boot time as 
 you will see. then i replugged it and everything went fine again.
 
 Note that system configuration ( acpi, pci, apic ) does not influence the
 problem.
 
 Best regards,
 
 Norman
 
 
 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job
 easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Zd1211-devs mailing list - http://zd1211.ath.cx/
 Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
 
 

-- 
View this message in context: 
http://www.nabble.com/-zd1211rw--Driver-leaving-device-in-bugged-state---tf2288772.html#a7662325
Sent from the zd1211-devs mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs


Re: [zd1211-devs] nslu2 arm observations

2006-12-03 Thread William Keaney

Also, I had a lot of miscellaneous problems with zd1211rw under 2.6.18.  I
updated to 2.6.19 yesterday and patched in the latest zd1211rw.git, and have
noticed a marked improvement in reliability/performance.

On 12/3/06, Daniel Drake [EMAIL PROTECTED] wrote:


Arek Jankowski wrote:
 Some of this is already known, but I hope this information may be still
useful
 for some. My main question is why the zd1211rw performance is so low? Is
 there a way to debug this problem?

You didn't state whether you were measuring RX or TX performance, or
whether you were using 802.11b or g.

In general zd1211rw performance is not that bad, although I think we
still only meet about half the RX speed of the vendor driver, unsure
about TX. We're not sure why, but at the same time nobody has really
investigated. Our driver is less efficient in that we allocate memory in
the RX path rather than using some kind of circular buffer system, but
this should be insignificant (unless we're pegging the CPU on your ARM?)

Also remember that the vendor driver dynamically adjust it's rate based
on signal quality but zd1211rw defaults to 11m and relies on the user
setting a sensible rate. If you set 54M but don't have a strong signal,
then you'll get considerably worse performance than (e.g.) 24M.

To start with, use a vendor driver which does not have large packet
support, otherwise it is not a fair comparison. (It is *possible* that
zd1211rw not using jumbo frames is a reason for slowdown but I expect it
will be an insignificant difference)

The next steps would be to find what's different. You could dump the
controlset on each outgoing frame and check that the match for both
drivers. You could also write a patch for both drivers to dump the
contents of all control registers on-demand (possibly through the
ethtool interface) and then compare results from the 2 drivers.

Daniel

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs