Larry Finger <Larry.Finger@xxxxxxxxxxxx> writes: > On 09/17/2016 03:59 PM, Jes Sorensen wrote: >> Larry Finger <Larry.Finger@xxxxxxxxxxxx> writes: >>> As soon as debugging is turned on, the logs are filled with messages >>> reporting the interrupt status. As this quantity is usually zero, this >>> output is not needed. In fact, there will be a report if the status is >>> not zero, thus the debug line in question could probably be deleted. >>> Rather than taking that action, I have changed it to only be printed >>> when the RTL8XXXU_DEBUG_USB bit is set in the debug mask. >> >> Wrong flag, please add a RTL8XXXU_DEBUG_INTERRUPT flag instead and use >> that. >> >> Which device do you see this with? > > OK. I will change the flag. > > I found this with a TP-Link TL-MN8200ND, which has some variant of the > RTL8188CU chip. It transmits, but I see no evidence that the receiver > is functioning at all. The same is true for driver rtl8192cu. Only the > driver from Realtek's web site actually works. I assume you mean TL-WN8200ND? That device is 'interesting' in the least positive sense of the word. It seems abandoned by the manufacturer too. I have one of them but never managed to get it working, not with any driver under Linux nor Windows. TP-Link shipped a driver disc with it, but you cannot install that in any recent version of Windows because the OS ships with it's own driver for the 8192cu/8188cu series and the device uses the common USB ID. I have been meaning to see if I could find a box with Vista on it to install their driver and run a USB trace on it. > One other problem that I have found is that the debug option on module > load seems to be ignored. So far, I've had to hard wire the > flags. Once I find the reason, I'll send a patch for that as well. That is odd - I use it regularly and haven't had problems with it. Cheers, Jes
