If you are trying to get a device working with ndiswrapper, please help ndiswrapper project wiki by contributing your findings. See HowToContribute
Difference between revisions of "Trendnet TEW-643PI"
(Update from alsnider) |
(Updates from Herrmaro) |
||
| Line 6: | Line 6: | ||
==Info== | ==Info== | ||
| + | |||
| + | XP driver did not work for a 64bit pristine Debian Squeeze | ||
| + | system, but works smooth with 32bit | ||
| + | |||
| + | --- | ||
| + | |||
ndis was doing something weird, every time i tried to wrap the driver, ndis would give me the options available to it. not sure how i got it to quit doing that, or if it was even me. tried winxp winvista and win2000 drivers only one worked was 2000. | ndis was doing something weird, every time i tried to wrap the driver, ndis would give me the options available to it. not sure how i got it to quit doing that, or if it was even me. tried winxp winvista and win2000 drivers only one worked was 2000. | ||
Latest revision as of 09:19, 25 March 2011
Trendnet TEW-643PI Wireless 802.11 bdgn
- Chipset: rtl8190P
- pciid: 10ec:8190
- Driver: Win 2000 driver http://www.trendnet.com/downloads/list_subcategory.asp?SUBTYPE_ID=1258 (has winvista winxp and win2000 drivers in same zip)
- Driver: http://downloads.trendnet.com/tew-643pi/driver_utility/utilitytew-641pc_643pi.zip (Drivers/Windows XP/x86/net819xp.inf)
Info
XP driver did not work for a 64bit pristine Debian Squeeze system, but works smooth with 32bit
---
ndis was doing something weird, every time i tried to wrap the driver, ndis would give me the options available to it. not sure how i got it to quit doing that, or if it was even me. tried winxp winvista and win2000 drivers only one worked was 2000.
---
I needed to apply a work-around to get this device up under a 32-bit SMP kernel. It appears that when an ndiswrapper kernel thread is scheduled to a different CPU the device hangs. You can usually pump about 100-200Mb full bore before this occurs. (This sound familiar)? If you lock the threads down to one CPU the device stays up. Under a 64-bit kernel, the ntos_wq thread causes a kernel oops and hangs the machine, usually within 5-6 seconds. (It might be related, but I didn't do this affinity test on 64-bit).
The work around is QCD on gentoo using /etc/conf.d/local.start:
schedtool -a 0 `ps -e | grep _wq | gawk '{print $1}'`
The same behaviour was observed using all three preemption models. More SMP investigation is obviously needed, but at the least, the code could lock its own threads down as a quick band-aid.
My system:
2 CPUs, i686 AMD Athlon(tm) II X2 215 Processor
kernel 2.6.32-gentoo-r6 (SMP)
ndiswrapper-1.55-r1
