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"
(Report from Greg Kerns) |
(Update from alsnider) |
||
| Line 1: | Line 1: | ||
==Trendnet TEW-643PI Wireless 802.11 bdgn== | ==Trendnet TEW-643PI Wireless 802.11 bdgn== | ||
| − | * Chipset: | + | * Chipset: rtl8190P |
* pciid: 10ec:8190 | * 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: 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== | ==Info== | ||
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. | ||
| + | |||
| + | --- | ||
| + | |||
| + | 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 | ||
| + | |||
[[Category:Trendnet]] | [[Category:Trendnet]] | ||
[[Category:PCI]] | [[Category:PCI]] | ||
[[Category:WORKS]] | [[Category:WORKS]] | ||
Revision as of 11:34, 23 February 2010
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
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
