Hi Larry,
On Thu, Jul 12, 2012 at 10:14:05PM -0500, Larry Finger wrote:
> On 07/12/2012 04:57 PM, Forest Bond wrote:
> >On Thu, Jul 12, 2012 at 05:07:03PM -0400, Forest Bond wrote:
> >>On Thu, Jul 12, 2012 at 02:17:51PM -0400, Forest Bond wrote:
> >>>On Thu, Jul 12, 2012 at 11:23:20AM -0500, Larry Finger wrote:
> >>>>On 07/12/2012 10:25 AM, Forest Bond wrote:
> >>>>>On Wed, Jul 11, 2012 at 08:58:16PM -0500, Larry Finger wrote:
> >>>>>>On 07/11/2012 08:32 PM, Forest Bond wrote:
> >>>>>>>On Wed, Jul 11, 2012 at 07:58:04PM -0500, Larry Finger wrote:
> >>>>>>>>On 07/11/2012 07:21 PM, Forest Bond wrote:
> >>>>>>>>>The rtl8192de driver is working fine for me at 5GHz, but I am having trouble
> >>>>>>>>>getting scan results for 2.4GHz 802.11g networks. I have been doing a lot of
> >>>>>>>>>debugging but am not making much progress. I suspect the 802.11 b/g/n phy is
> >>>>>>>>>not being initialized correctly, but I'm pretty far outside my domain on this
> >>>>>>>>>one.
> >>>>>>>>>
> >>>>>>>>>Is anyone successfully using this driver with a 2.4GHz 802.11g network?
> >>>>>>>>
> >>>>>>>>I have several different models - some work better than others. What
> >>>>>>>>is the PCI ID for yours?
> >>>>>>>
> >>>>>>>This is the one I have:
> >>>>>>>
> >>>>>>>02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. Device [10ec:8193]
> >>>>>>>02:00.1 Network controller [0280]: Realtek Semiconductor Co., Ltd. Device [10ec:8193] (rev 01)
> >>>>>>
> >>>>>>It turns out that both kinds have the same ID. I think one of them
> >>>>>>is a prototype, while the other is probably a production unit.
> >>>>>>Obviously, bitrot has set in while I wasn't testing. With the kernel
> >>>>>>driver, neither unit can even scan in the 2.4 GHz band. Using the
> >>>>>>latest version of the vendor driver, the production version connects
> >>>>>>with APs running WEP, WPA, or WPA2. The prototype can only handle
> >>>>>>WEP.
> >>>>>>
> >>>>>>Obviously, I have some work to do. In the meantime, I will send you
> >>>>>>a tarball containing the vendor driver - privately so as not to spam
> >>>>>>the list.
> >>>>>
> >>>>>Thank you, I appreciate that.
> >>>>>
> >>>>>Of course, my preference would be to fix up the kernel driver. I don't mind
> >>>>>doing some manual bisection with compat-wireless releases unless you think that
> >>>>>would be a total waste of time. Do you have any sense for what the last working
> >>>>>kernel version would have been?
> >>>>>
> >>>>>As you suggest, we may need to use the vendor driver in the meantime. Thanks
> >>>>>again for sending it over (although I suspect it is the same version I
> >>>>>downloaded from Realtek's web site).
> >>>>
> >>>>It started with the Realtek version, but has some important bug
> >>>>fixes that I wanted you to have.
> >>>
> >>>Thanks, that's really helpful.
> >>>
> >>>>Of course, we want to fix the kernel version, but if you want to
> >>>>bisect compat-wireless, that would be a big help. In the meantime, I
> >>>>will try bisecting wireless-testing when I get a chance.
> >>>
> >>>I have begun disecting compat-wireless releases. 3.1.1-1 works, 3.2.5-1
> >>>doesn't. I'm going to try to identify the commit that broke things by applying
> >>>patches to 3.1.1-1.
> >>
> >>So unless I screwed something up while bisecting, I think this is where things
> >>broke:
> >>
> >>
> >>commit d83579e2a50ac68389e6b4c58b845c702cf37516
> >>Author: Chaoming Li <chaoming_li@xxxxxxxxxxxxxx>
> >>Date: Tue Oct 11 21:28:51 2011 -0500
> >>
> >> rtlwifi: rtl8192de: Updates from latest Reaktek driver - Part III
> >>
> >> This patch incorporate the differences between the 06/20/2011 and
> >> 08/16/2011 Realtek releases of the rtl8192de driver.
> >>
> >> The changes include:
> >>
> >> 1. Update for new chip versions
> >>
> >> Signed-off-by: Chaoming Li <chaoming_li@xxxxxxxxxxxxxx>
> >> Signed-off-by: Larry Finger <Larry.Finger@xxxxxxxxxxxx>
> >> Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx>
> >>
> >>
> >>I managed to get into an interesting situation at one point during testing where
> >>neither MAC would return scan results, even after reverting to a known-good
> >>driver version. This was resolved by removing and re-applying power (i.e. a
> >>reboot did not fix it). Something must've put the hardware in a bad state. I
> >>haven't seen this problem again.
> >>
> >>Anyway, I'll probably play with that patch a bit to see if I can figure out what
> >>broke, but let me know if you have any ideas.
> >
> >
> >So this seems to fix things:
> >
> >diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
> >index 18380a7..be21c81 100644
> >--- a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
> >+++ b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
> >@@ -3345,21 +3345,25 @@ void rtl92d_phy_config_macphymode_info(struct ieee80211_hw *hw)
> > switch (rtlhal->macphymode) {
> > case DUALMAC_SINGLEPHY:
> > rtlphy->rf_type = RF_2T2R;
> >- rtlhal->version |= CHIP_92D_SINGLEPHY;
> >+ /*rtlhal->version |= CHIP_92D_SINGLEPHY;*/
> >+ rtlhal->version |= RF_TYPE_2T2R;
> > rtlhal->bandset = BAND_ON_BOTH;
> > rtlhal->current_bandtype = BAND_ON_2_4G;
> > break;
> >
> > case SINGLEMAC_SINGLEPHY:
> > rtlphy->rf_type = RF_2T2R;
> >- rtlhal->version |= CHIP_92D_SINGLEPHY;
> >+ /*rtlhal->version |= CHIP_92D_SINGLEPHY;*/
> >+ rtlhal->version |= RF_TYPE_2T2R;
> > rtlhal->bandset = BAND_ON_BOTH;
> > rtlhal->current_bandtype = BAND_ON_2_4G;
> > break;
> >
> > case DUALMAC_DUALPHY:
> > rtlphy->rf_type = RF_1T1R;
> >- rtlhal->version &= (~CHIP_92D_SINGLEPHY);
> >+ /*rtlhal->version &= (~CHIP_92D_SINGLEPHY);*/
> >+ rtlhal->version &= RF_TYPE_1T1R;
> >+
> > /* Now we let MAC0 run on 5G band. */
> > if (rtlhal->interfaceindex == 0) {
> > rtlhal->bandset = BAND_ON_5G;
> >
> >
> >And this is unrelated, but also seems important:
> >
> >diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> >index b338d52..59e85f5 100644
> >--- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> >+++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> >@@ -1058,11 +1058,14 @@ static enum version_8192d _rtl92de_read_chip_version(struct ieee80211_hw *hw)
> > u32 value32;
> >
> > value32 = rtl_read_dword(rtlpriv, REG_SYS_CFG);
> >+ version |= CHIP_92D;
> >+
> > if (!(value32 & 0x000f0000)) {
> > version = VERSION_TEST_CHIP_92D_SINGLEPHY;
> > RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD, "TEST CHIP!!!\n");
> > } else {
> >- version = VERSION_NORMAL_CHIP_92D_SINGLEPHY;
> >+ /*version = VERSION_NORMAL_CHIP_92D_SINGLEPHY;*/
> >+ version |= NORMAL_CHIP;
> > RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD, "Normal CHIP!!!\n");
> > }
> > return version;
> >
> >
> >Let me know what you think. I can prepare some proper patches sometime
> >tomorrow.
>
> All of those match the code in the 0816.2011 driver. I have no idea
> what went wrong earlier, but I think those patches are OK.
Okay, I sent a patch off that fixes the scanning issue. The other change turned
out to be a no-op.
I'd like to tackle some clean-up work for the version calculation logic at some
point, as there are likely some other bugs there. For instance, I'm pretty sure
in the dual-mac, dual-phy case we end up with both RF_TYPE_1T1R and RF_TYPE_2T2R
set since VERSION_NORMAL_CHIP_92D_SINGLEPHY implies RF_TYPE_2T2R. And, bugs
aside, the code is a bit difficult to understand, which I imagine makes it
harder to avoid introducing new bugs, particularly when integrating changes from
the vendor driver.
Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.rapidrollout.com
Attachment:
signature.asc
Description: Digital signature
