Re: [RFC v2 00/12] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips
On Wed, Oct 3, 2018 at 12:52 PM Larry Finger wrote: > > On 10/3/18 11:15 AM, Sid Hayn wrote: > > Is there a public repository where I can track development for this driver? > > For the moment, this is it. Once the driver is accepted into the > wireless-drivers-next tree, I will create a new rtw88 branch in > http://github.com/lwfinger.git with this driver to accomodate people that want I think you lost part of that link. Thanks, Zero > to use the driver with an older kernel.. At the moment, it is still in too > much > of a flux. > > Larry > >
Re: [RFC v2 00/12] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips
Is there a public repository where I can track development for this driver? Thanks, Zero On Wed, Oct 3, 2018 at 4:04 AM wrote: > > From: Yan-Hsuan Chuang > > This is a new mac80211 driver for Realtek 802.11ac wireless network chips. > rtwlan supports 8822BE and 8822CE chips, and will be able to support > multi-vif combinations in run-time. > > For now, only PCI bus is supported, but rtwlan was originally designed > to optionally support three buses includes USB & SDIO. USB & SDIO modules > will soon be supported by rtwlan, with configurable core module to fit > with different bus modules in the same time. > > For example, if we choose 8822BE and 8822CU, only PCI & USB modules will > be selected, built, loaded into kernel. This is one of the major > difference from rtlwifi, which can only support specific combinations. > > Another difference from rtlwifi is that rtwlan is designed to support > the latest Realtek 802.11ac wireless network chips like 8822B and > 8822C series. Compared to the earlier chips supported by rtlwifi like > the 802.11n 8192EE chipset or 802.11ac 8821AE/8812AE chips, newer ICs > have different MAC & PHY settings, such as new multi-port feature for the > MAC layer design and Jaguar2/Jaguar3 PHY layer IPs. > > Multi-Port feature is also supported under rtwlan's software architecture. > rtlwifi can only support one vif in the same time, most because of the > hardware limitations for early chips, hence the original design of it > also restricts the usage of multi-vif support, so latest chipset seems not > take advantages from its new MAC engine. > > However, rtwlan can run multiple vifs concurrently by holding them on > hardware ports provided by MAC engine, hence can easily start different > roles on a single device. > > Based on the reasons mentioned before, we implemented rtwlan. It had many > authors, they are listed here alphabetically: > > Ping-Ke Shih > Tzu-En Huang > Yan-Hsuan Chuang > > > v2 > > - rename from rtwlan to rtw88 > - remove lots of magic numbers > - add pci null entry for auto load on boot > - add rtwdev->mutex to protect against mac80211 callbacks > - add rcu lock protection for vif_list and sta_list > - refine bits & endian macros to use helper functions provided by kernel >instead of create new ones > - ieee80211_free_txskb for tx path dropped packets > - not register iface_combination since now only one vif is allowed > - some fixes suggested by Stanislaw > > > Yan-Hsuan Chuang (12): > rtw88: main files > rtw88: core files > rtw88: hci files > rtw88: trx files > rtw88: mac files > rtw88: fw and efuse files > rtw88: phy files > rtw88: debug files > rtw88: chip files > rtw88: 8822B init table > rtw88: 8822C init table > rtw88: Kconfig & Makefile > > drivers/net/wireless/realtek/Kconfig | 1 + > drivers/net/wireless/realtek/Makefile | 1 + > drivers/net/wireless/realtek/rtw88/Kconfig |57 + > drivers/net/wireless/realtek/rtw88/Makefile|19 + > drivers/net/wireless/realtek/rtw88/debug.c | 652 + > drivers/net/wireless/realtek/rtw88/debug.h |45 + > drivers/net/wireless/realtek/rtw88/efuse.c | 150 + > drivers/net/wireless/realtek/rtw88/efuse.h |53 + > drivers/net/wireless/realtek/rtw88/fw.c| 638 + > drivers/net/wireless/realtek/rtw88/fw.h| 182 + > drivers/net/wireless/realtek/rtw88/hci.h | 212 + > drivers/net/wireless/realtek/rtw88/mac.c | 1045 + > drivers/net/wireless/realtek/rtw88/mac.h |35 + > drivers/net/wireless/realtek/rtw88/mac80211.c | 482 + > drivers/net/wireless/realtek/rtw88/main.c | 1133 + > drivers/net/wireless/realtek/rtw88/main.h | 1200 ++ > drivers/net/wireless/realtek/rtw88/pci.c | 1220 ++ > drivers/net/wireless/realtek/rtw88/pci.h | 228 + > drivers/net/wireless/realtek/rtw88/phy.c | 1675 ++ > drivers/net/wireless/realtek/rtw88/phy.h | 125 + > drivers/net/wireless/realtek/rtw88/ps.c| 198 + > drivers/net/wireless/realtek/rtw88/ps.h|21 + > drivers/net/wireless/realtek/rtw88/reg.h | 404 + > drivers/net/wireless/realtek/rtw88/regd.c | 462 + > drivers/net/wireless/realtek/rtw88/regd.h |40 + > drivers/net/wireless/realtek/rtw88/rtw8822b.c | 1593 ++ > drivers/net/wireless/realtek/rtw88/rtw8822b.h | 271 + > .../net/wireless/realtek/rtw88/rtw8822b_table.c| 20783 > +++ > .../net/wireless/realtek/rtw88/rtw8822b_table.h|18 + > drivers/net/wireless/realtek/rtw88/rtw8822c.c | 1170 ++ > drivers/net/wireless/realtek/rtw88/rtw8822c.h | 416 + > .../net/wireless/realtek/rtw88/rtw8822c_table.c| 4150 > .../net/wireless/realtek/rtw88/rtw8822c_table.h|16 + > drivers/net/wireless/realtek/rtw88/rx.c| 144 + >
Re: mt76x0 bug report
On Wed, Sep 19, 2018 at 7:15 AM Stanislaw Gruszka wrote: > > On Tue, Sep 18, 2018 at 01:36:51PM -0400, Sid Hayn wrote: > > On Tue, Sep 18, 2018 at 7:56 AM Stanislaw Gruszka > > wrote: > > > > > > On Mon, Sep 17, 2018 at 11:18:57PM -0400, Sid Hayn wrote: > > > > Sorry to bump the one thing that we both agreed was low priority but > > > > > > > > So was testing all of my dongles that use the driver you are working > > > > on, and running them through my connect scripts. I moved the AP to > > > > maybe <5ft from the clients and something wierd happened. The t1u > > > > tried to connect to one of the 2.4GHz only networks. It failed, but > > > > it actually got enough scan data back to attempt authentication with a > > > > valid 2.4GHz only bssid. Which means in short, that the eeprom isn't > > > > lying and your parsing of it is correct. Something obviously makes > > > > this a 5GHz only device, as the connection failed and most of the time > > > > nothing at all is seen on 2.4GHz, but clearly it's some filter or > > > > antenna or some other mechanism which makes it 5GHz only. So probably > > > > hardware lying to you is now even lower on your list since this safely > > > > rules out the driver parsing the eeprom incorrectly. > > > > > > First of all would be good to check if problem is not already solved, > > > latest version of the driver can be found here: > > > https://github.com/nbd168/wireless > > > > Booting that kernel gets me instant to near instant kernel panics, so > > I am unable to test much. > > This has to be fixed as well, can you provide kernel messages ? Working on it, please stand by. > > > > Second, is there vendor driver available for this particular device? > > > Perhaps there are some tweeks needed that are not provided by generic > > > driver. > > > > No clue, haven't even tried to look. This hardware was all sitting on > > a shelf till it looked like a real driver was being merged into the > > kernel so um, thanks :-) > > Why do you think device is 5GHz only? This is very unusual. I know > only single-band 2.4GHz or dual-band 2.4GHz & 5GHz devices. https://www.tp-link.com/us/faq-2253.html "Note: Before you do these troubleshooting, please kindly check whether the adapter you use is Archer T1U. For this model, it only supports 5GHz network. So if the router you use only provides 2.4GHz network, ‘you can’t find the 5GHz network any more." Yup, I agree, it's wierd. -Zero > > Regards > Stanislaw
Re: mt76x0 bug report
On Tue, Sep 18, 2018 at 7:56 AM Stanislaw Gruszka wrote: > > On Mon, Sep 17, 2018 at 11:18:57PM -0400, Sid Hayn wrote: > > Sorry to bump the one thing that we both agreed was low priority but > > > > So was testing all of my dongles that use the driver you are working > > on, and running them through my connect scripts. I moved the AP to > > maybe <5ft from the clients and something wierd happened. The t1u > > tried to connect to one of the 2.4GHz only networks. It failed, but > > it actually got enough scan data back to attempt authentication with a > > valid 2.4GHz only bssid. Which means in short, that the eeprom isn't > > lying and your parsing of it is correct. Something obviously makes > > this a 5GHz only device, as the connection failed and most of the time > > nothing at all is seen on 2.4GHz, but clearly it's some filter or > > antenna or some other mechanism which makes it 5GHz only. So probably > > hardware lying to you is now even lower on your list since this safely > > rules out the driver parsing the eeprom incorrectly. > > First of all would be good to check if problem is not already solved, > latest version of the driver can be found here: > https://github.com/nbd168/wireless Booting that kernel gets me instant to near instant kernel panics, so I am unable to test much. > > Second, is there vendor driver available for this particular device? > Perhaps there are some tweeks needed that are not provided by generic > driver. No clue, haven't even tried to look. This hardware was all sitting on a shelf till it looked like a real driver was being merged into the kernel so um, thanks :-) -Zero > > Thanks > Stanislaw
Re: [PATCH] mt76x0: run vco calibration for each channel configuration
mt76x0 isn't in 4.18 at all, it's being added in 4.19 isn't it? I'm
not sure you can call it a regression, but adding a new driver with a
known bug that breaks an entire use case (monitor mode) seems silly
when a small and tested fix is available. Pretty please.
Thanks,
Zero
On Tue, Sep 18, 2018 at 8:43 AM Kalle Valo wrote:
>
> Stanislaw Gruszka writes:
>
> > On Tue, Sep 18, 2018 at 01:43:56PM +0200, Stanislaw Gruszka wrote:
> >> On Fri, Sep 07, 2018 at 11:13:12PM +0200, Lorenzo Bianconi wrote:
> >> > According to vendor sdk, vco calibration has to be executed
> >> > for each channel configuration whereas mcu calibration has to be
> >> > performed during channel scanning. This patch fixes the mt76x0
> >> > monitor mode issue since in that configuration vco calibration
> >> > was never executed
> >> >
> >> > Fixes: 10de7a8b4ab9 ("mt76x0: phy files")
> >> > Tested-by: Sid Hayn
> >> > Signed-off-by: Lorenzo Bianconi
> >>
> >> Acked-by: Stanislaw Gruszka
> >
> > For the record this is 4.19 material.
>
> I really want to minimise conflicts and because of so many mt76 patches
> conflicts are likely to happen, so I'm keeping the bar high for mt76
> patches going 4.19. Is this a regression from 4.18? If not, I think this
> should go to -next and cc stable. And besides, monitor mode isn't that
> critical anyway.
>
> --
> Kalle Valo
Re: mt76x0 bug report
On Fri, Sep 14, 2018 at 11:51 AM Sid Hayn wrote: > > On Fri, Sep 14, 2018 at 11:47 AM Lorenzo Bianconi > wrote: > > > > > > > > *bump* > > > > > > Been a few days, just a reminder that your monitor mode patch fixed > > > all channels below 144 but something appears incorrect in regdomain > > > handling as I cannot get channels 144 or higher working (my main AP > > > being on channel 149. Again, this works on mt76x2u but not on mt76x0. > > > The patch I tested doesn't appear to have landed in wireless-testing > > > yet, so if you haven't, please do push that up. > > > > I have already sent the patch to linux-wireless ml > > https://patchwork.kernel.org/patch/10592597/ > > Excellent, thank you. Is someone working on the channel/regdomain > issue as well? > > > > > > > > Secondarily, ethtool still doesn't report firmware version and that > > > would be a very helpful thing to have before 4.19 hits. > > > > > > > +Davide Caratti > > Thanks, saw his message and will watch for it to test. > > > > > Additionally, with much less severity, t1u still thinks it is dual > > > band and I'm happy to run any command, test any patch, etc. I > > > honestly don't care about this at all short term, but it does slow the > > > hardware down tuning to a bunch of channels which it cannot access so > > > long term it should probably be fixed in some way. > > > > > > > I am busy with other mt76 activities at the moment, I will look into > > it as soon as I have time > > Listed third and we seem to agree this is a "as time allows" task. Sorry to bump the one thing that we both agreed was low priority but So was testing all of my dongles that use the driver you are working on, and running them through my connect scripts. I moved the AP to maybe <5ft from the clients and something wierd happened. The t1u tried to connect to one of the 2.4GHz only networks. It failed, but it actually got enough scan data back to attempt authentication with a valid 2.4GHz only bssid. Which means in short, that the eeprom isn't lying and your parsing of it is correct. Something obviously makes this a 5GHz only device, as the connection failed and most of the time nothing at all is seen on 2.4GHz, but clearly it's some filter or antenna or some other mechanism which makes it 5GHz only. So probably hardware lying to you is now even lower on your list since this safely rules out the driver parsing the eeprom incorrectly. Thanks, Zero > > Thanks for the prompt response. > > -Zero > > > > Regards, > > Lorenzo > > > > > Thanks again for all your hard work, watching the mailing list it is > > > obvious how much effort is going into this right now. > > > > > > -Zero > > > On Fri, Sep 7, 2018 at 3:55 PM Sid Hayn wrote: > > > > > > > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi > > > > wrote: > > > > > > > > > > > Actions like that have caused great problems in the past, as the > > > > > > kernel won't allow channel control of a monitor interface at all > > > > > > when > > > > > > there is a managed interface on the same phy (afaik). > > > > > > > > > > > > But just for fun and codepath testing here are two test scenarios: > > > > > > > > > > > > Test 1: "iwconfig t2u mode monitor" > > > > > > Sees nothing on any channel, no packets reported > > > > > > > > > > > > Test 2(requested test): "iw phy phy11 interface add t2uhmon type > > > > > > monitor" > > > > > > Sees nothing on any channel, no packets reported. > > > > > > Despite having a monitor and managed interface on the same phy, > > > > > > iwconfig is reporting that the channel is changing as requested. So > > > > > > perhaps my above "afaik" comment is partially outdated. > > > > > > > > > > > > For both tests the interface was not used to connect to any ap prior > > > > > > to or during testing. > > > > > > > > > > > > > > > > Could you please try following patch? > > > > > > > > Excellent! This seems to work for all channels up to 140, however, > > > > not 144 or above. "iw list" shows these are supported but I cannot > > > > set them in monitor mode: > > > > > > > > * 5720
Re: mt76x0 bug report
On Fri, Sep 14, 2018 at 11:47 AM Lorenzo Bianconi wrote: > > > > > *bump* > > > > Been a few days, just a reminder that your monitor mode patch fixed > > all channels below 144 but something appears incorrect in regdomain > > handling as I cannot get channels 144 or higher working (my main AP > > being on channel 149. Again, this works on mt76x2u but not on mt76x0. > > The patch I tested doesn't appear to have landed in wireless-testing > > yet, so if you haven't, please do push that up. > > I have already sent the patch to linux-wireless ml > https://patchwork.kernel.org/patch/10592597/ Excellent, thank you. Is someone working on the channel/regdomain issue as well? > > > > > Secondarily, ethtool still doesn't report firmware version and that > > would be a very helpful thing to have before 4.19 hits. > > > > +Davide Caratti Thanks, saw his message and will watch for it to test. > > > Additionally, with much less severity, t1u still thinks it is dual > > band and I'm happy to run any command, test any patch, etc. I > > honestly don't care about this at all short term, but it does slow the > > hardware down tuning to a bunch of channels which it cannot access so > > long term it should probably be fixed in some way. > > > > I am busy with other mt76 activities at the moment, I will look into > it as soon as I have time Listed third and we seem to agree this is a "as time allows" task. Thanks for the prompt response. -Zero > > Regards, > Lorenzo > > > Thanks again for all your hard work, watching the mailing list it is > > obvious how much effort is going into this right now. > > > > -Zero > > On Fri, Sep 7, 2018 at 3:55 PM Sid Hayn wrote: > > > > > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi > > > wrote: > > > > > > > > > Actions like that have caused great problems in the past, as the > > > > > kernel won't allow channel control of a monitor interface at all when > > > > > there is a managed interface on the same phy (afaik). > > > > > > > > > > But just for fun and codepath testing here are two test scenarios: > > > > > > > > > > Test 1: "iwconfig t2u mode monitor" > > > > > Sees nothing on any channel, no packets reported > > > > > > > > > > Test 2(requested test): "iw phy phy11 interface add t2uhmon type > > > > > monitor" > > > > > Sees nothing on any channel, no packets reported. > > > > > Despite having a monitor and managed interface on the same phy, > > > > > iwconfig is reporting that the channel is changing as requested. So > > > > > perhaps my above "afaik" comment is partially outdated. > > > > > > > > > > For both tests the interface was not used to connect to any ap prior > > > > > to or during testing. > > > > > > > > > > > > > Could you please try following patch? > > > > > > Excellent! This seems to work for all channels up to 140, however, > > > not 144 or above. "iw list" shows these are supported but I cannot > > > set them in monitor mode: > > > > > > * 5720 MHz [144] (22.0 dBm) (no IR, radar detection) > > > * 5745 MHz [149] (22.0 dBm) (no IR) > > > * 5765 MHz [153] (22.0 dBm) (no IR) > > > * 5785 MHz [157] (22.0 dBm) (no IR) > > > * 5805 MHz [161] (22.0 dBm) (no IR) > > > * 5825 MHz [165] (22.0 dBm) (no IR) > > > > > > remote2 ~ # iw dev t2uhmon set channel 140 > > > remote2 ~ # iw dev t2uhmon set channel 144 > > > command failed: Invalid argument (-22) > > > > > > Thanks, > > > Zero > > > > > > > Regards, > > > > > > > > Lorenzo > > > > > > > > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > > > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > > > @@ -756,11 +756,10 @@ __mt76x0_phy_set_channel(struct mt76x0_dev *dev, > > > > > > > > /* Vendor driver don't do it */ > > > > /* mt76x0_phy_set_tx_power(dev, channel, rf_bw_band); */ > > > > + mt76x0_vco_cal(dev, channel); > > > > > > > > if (scan) > > > > - mt76x0_vco_cal(dev, channel); > > > > - > > > > - mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > > > + mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > > > mt76x0_phy_set_chan_pwr(dev, channel); > > > > > > > > dev->mt76.chandef = *chandef;
Re: mt76x0 bug report
*bump* Been a few days, just a reminder that your monitor mode patch fixed all channels below 144 but something appears incorrect in regdomain handling as I cannot get channels 144 or higher working (my main AP being on channel 149. Again, this works on mt76x2u but not on mt76x0. The patch I tested doesn't appear to have landed in wireless-testing yet, so if you haven't, please do push that up. Secondarily, ethtool still doesn't report firmware version and that would be a very helpful thing to have before 4.19 hits. Additionally, with much less severity, t1u still thinks it is dual band and I'm happy to run any command, test any patch, etc. I honestly don't care about this at all short term, but it does slow the hardware down tuning to a bunch of channels which it cannot access so long term it should probably be fixed in some way. Thanks again for all your hard work, watching the mailing list it is obvious how much effort is going into this right now. -Zero On Fri, Sep 7, 2018 at 3:55 PM Sid Hayn wrote: > > On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi > wrote: > > > > > Actions like that have caused great problems in the past, as the > > > kernel won't allow channel control of a monitor interface at all when > > > there is a managed interface on the same phy (afaik). > > > > > > But just for fun and codepath testing here are two test scenarios: > > > > > > Test 1: "iwconfig t2u mode monitor" > > > Sees nothing on any channel, no packets reported > > > > > > Test 2(requested test): "iw phy phy11 interface add t2uhmon type monitor" > > > Sees nothing on any channel, no packets reported. > > > Despite having a monitor and managed interface on the same phy, > > > iwconfig is reporting that the channel is changing as requested. So > > > perhaps my above "afaik" comment is partially outdated. > > > > > > For both tests the interface was not used to connect to any ap prior > > > to or during testing. > > > > > > > Could you please try following patch? > > Excellent! This seems to work for all channels up to 140, however, > not 144 or above. "iw list" shows these are supported but I cannot > set them in monitor mode: > > * 5720 MHz [144] (22.0 dBm) (no IR, radar detection) > * 5745 MHz [149] (22.0 dBm) (no IR) > * 5765 MHz [153] (22.0 dBm) (no IR) > * 5785 MHz [157] (22.0 dBm) (no IR) > * 5805 MHz [161] (22.0 dBm) (no IR) > * 5825 MHz [165] (22.0 dBm) (no IR) > > remote2 ~ # iw dev t2uhmon set channel 140 > remote2 ~ # iw dev t2uhmon set channel 144 > command failed: Invalid argument (-22) > > Thanks, > Zero > > > Regards, > > > > Lorenzo > > > > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > > @@ -756,11 +756,10 @@ __mt76x0_phy_set_channel(struct mt76x0_dev *dev, > > > > /* Vendor driver don't do it */ > > /* mt76x0_phy_set_tx_power(dev, channel, rf_bw_band); */ > > + mt76x0_vco_cal(dev, channel); > > > > if (scan) > > - mt76x0_vco_cal(dev, channel); > > - > > - mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > + mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > > mt76x0_phy_set_chan_pwr(dev, channel); > > > > dev->mt76.chandef = *chandef;
Re: mt76x0 bug report
On Fri, Sep 7, 2018 at 4:24 AM Lorenzo Bianconi wrote: > > > Actions like that have caused great problems in the past, as the > > kernel won't allow channel control of a monitor interface at all when > > there is a managed interface on the same phy (afaik). > > > > But just for fun and codepath testing here are two test scenarios: > > > > Test 1: "iwconfig t2u mode monitor" > > Sees nothing on any channel, no packets reported > > > > Test 2(requested test): "iw phy phy11 interface add t2uhmon type monitor" > > Sees nothing on any channel, no packets reported. > > Despite having a monitor and managed interface on the same phy, > > iwconfig is reporting that the channel is changing as requested. So > > perhaps my above "afaik" comment is partially outdated. > > > > For both tests the interface was not used to connect to any ap prior > > to or during testing. > > > > Could you please try following patch? Excellent! This seems to work for all channels up to 140, however, not 144 or above. "iw list" shows these are supported but I cannot set them in monitor mode: * 5720 MHz [144] (22.0 dBm) (no IR, radar detection) * 5745 MHz [149] (22.0 dBm) (no IR) * 5765 MHz [153] (22.0 dBm) (no IR) * 5785 MHz [157] (22.0 dBm) (no IR) * 5805 MHz [161] (22.0 dBm) (no IR) * 5825 MHz [165] (22.0 dBm) (no IR) remote2 ~ # iw dev t2uhmon set channel 140 remote2 ~ # iw dev t2uhmon set channel 144 command failed: Invalid argument (-22) Thanks, Zero > Regards, > > Lorenzo > > --- a/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/phy.c > @@ -756,11 +756,10 @@ __mt76x0_phy_set_channel(struct mt76x0_dev *dev, > > /* Vendor driver don't do it */ > /* mt76x0_phy_set_tx_power(dev, channel, rf_bw_band); */ > + mt76x0_vco_cal(dev, channel); > > if (scan) > - mt76x0_vco_cal(dev, channel); > - > - mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > + mt76x0_mcu_calibrate(dev, MCU_CAL_RXDCOC, 1); > mt76x0_phy_set_chan_pwr(dev, channel); > > dev->mt76.chandef = *chandef;
Re: mt76x0 bug report
On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka wrote: > > On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote: > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi > > wrote: > > > > > > > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > > > > > I've noticed two additional issues in my testing. > > > > > > > > First issue, is that it appears the mt76x0 devices don't work properly > > > > in monitor mode. Sometimes they seem to monitor one channel properly, > > > > but nothing else. The mt76x2u works great, channel control, lots of > > > > packets, etc. > > > > > > Could you elaborate a little bit please? how can you reproduce the issue? > > > just add an interface in monitor mode and run a scan? > > > > Correct, standard stuff, use iw to create a monitor mode interface, > > use iw to remove managed mode interface, run some tool such as kismet > > or airodump-ng or even wireshark. > > But what exactly are the syptomps, I don't understand what you mean by > "mt76x0 devices don't work properly in monitor mode" ? > > > > I guess it depends on eeprom values. Could you please enable debug > > > messages a paste > > > syslog output? > > > > I don't see a mediatek specific debug near the driver selection in > > menuconfig, what debug messages do you want me to enable and how? > > You need to uncomment this line: > > # ccflags-y := -DDEBUG > > in drivers/net/wireless/mediatek/mt76/mt76x0/Makefile I have done this change, rebooted, and plugged in the TP-Link t1u dongle which is 5GHz only. This is dmesg: [ 30.058587] usb 2-2: new high-speed USB device number 3 using xhci_hcd [ 30.28] usb 2-2: New USB device found, idVendor=2357, idProduct=0105, bcdDevice= 1.00 [ 30.200010] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 30.200012] usb 2-2: Product: WiFi [ 30.200013] usb 2-2: Manufacturer: MediaTek [ 30.200015] usb 2-2: SerialNumber: 1.0 [ 30.332895] usb 2-2: reset high-speed USB device number 3 using xhci_hcd [ 30.466124] mt76x0 2-2:1.0: ASIC revision: 7612 MAC revision: 76502000 [ 30.467534] mt76x0 2-2:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 201308221655 [ 30.789455] mt76x0 2-2:1.0: loading FW - ILM 68716 + IVB 64 [ 30.844588] mt76x0 2-2:1.0: loading FW - DLM 11476 [ 31.172677] mt76x0 2-2:1.0: Firmware running! [ 31.378879] mt76x0 2-2:1.0: MCU not ready [ 31.393770] BBP version f000f200 [ 31.410935] mt76x0 2-2:1.0: EEPROM ver:02 fae:01 [ 31.411086] mt76x0 2-2:1.0: NIC_CONF0: fd11 NIC_CONF1: 3084 [ 31.411088] mt76x0 2-2:1.0: Has 2GHZ 1 5GHZ 1 [ 31.411089] mt76x0 2-2:1.0: PA Type 1 [ 31.411090] mt76x0 2-2:1.0: REG 2GHZ 0 REG 5GHZ 9 [ 31.411092] mt76x0 2-2:1.0: EEPROM country region 00 (channels 1-11) [ 31.416308] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' [ 31.417285] usbcore: registered new interface driver mt76x0 What would you like next? -Zero > > Thanks > Stanislaw >
Re: mt76x0 bug report
On Thu, Sep 6, 2018 at 11:43 AM Lorenzo Bianconi wrote: > > > > > On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka > > wrote: > > > > > > On Wed, Sep 05, 2018 at 08:52:18PM +, Sid Hayn wrote: > > > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi > > > > wrote: > > > > > > > > > > > > > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > > > > > > > > > I've noticed two additional issues in my testing. > > > > > > > > > > > > First issue, is that it appears the mt76x0 devices don't work > > > > > > properly > > > > > > in monitor mode. Sometimes they seem to monitor one channel > > > > > > properly, > > > > > > but nothing else. The mt76x2u works great, channel control, lots of > > > > > > packets, etc. > > > > > > > > > > Could you elaborate a little bit please? how can you reproduce the > > > > > issue? > > > > > just add an interface in monitor mode and run a scan? > > > > > > > > Correct, standard stuff, use iw to create a monitor mode interface, > > > > use iw to remove managed mode interface, run some tool such as kismet > > > > or airodump-ng or even wireshark. > > > > > > But what exactly are the syptomps, I don't understand what you mean by > > > "mt76x0 devices don't work properly in monitor mode" ? > > > > Basically, when I put a device using mt76x0 into monitor mode (adding > > a monitor interface with iw and removing the managed interface) it > > will not report packets on any channel, or sometimes it will report > > packets on one channel but not any others. I can switch channels as > > much, for example hopping channel 1-11, but it will only see packets > > on channel 7 and report no other packets on any other channels. In my > > actual test case it was channel 44 that successfully reported packets, > > but even that mostly doesn't work. I suspect the reason it reported > > packets on channel 44 in one of my tests is because the channel was > > set to 44 while in managed mode (connected to an AP). If I put the > > device in monitor mode before connecting to any AP, it reports packets > > on no channels. As such, I'm suspecting this has something to do with > > channel control in monitor mode. > > What about if you do not remove the managed interface and sniff on the > monitor one? Actions like that have caused great problems in the past, as the kernel won't allow channel control of a monitor interface at all when there is a managed interface on the same phy (afaik). But just for fun and codepath testing here are two test scenarios: Test 1: "iwconfig t2u mode monitor" Sees nothing on any channel, no packets reported Test 2(requested test): "iw phy phy11 interface add t2uhmon type monitor" Sees nothing on any channel, no packets reported. Despite having a monitor and managed interface on the same phy, iwconfig is reporting that the channel is changing as requested. So perhaps my above "afaik" comment is partially outdated. For both tests the interface was not used to connect to any ap prior to or during testing. Thanks, Zero > > Regards, > Lorenzo > > > > > > > > > I guess it depends on eeprom values. Could you please enable debug > > > > > messages a paste > > > > > syslog output? > > > > > > > > I don't see a mediatek specific debug near the driver selection in > > > > menuconfig, what debug messages do you want me to enable and how? > > > > > > You need to uncomment this line: > > > > > > # ccflags-y := -DDEBUG > > > > > > in drivers/net/wireless/mediatek/mt76/mt76x0/Makefile > > > > found it. this box takes a few min to rebuild a kernel, so I'll get > > back with this response later today hopefully. > > > > Thanks, > > Zero > > > > > > Thanks > > > Stanislaw > > >
Re: mt76x0 bug report
On Thu, Sep 6, 2018 at 5:32 AM Stanislaw Gruszka wrote: > > On Wed, Sep 05, 2018 at 08:52:18PM +0000, Sid Hayn wrote: > > On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi > > wrote: > > > > > > > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > > > > > I've noticed two additional issues in my testing. > > > > > > > > First issue, is that it appears the mt76x0 devices don't work properly > > > > in monitor mode. Sometimes they seem to monitor one channel properly, > > > > but nothing else. The mt76x2u works great, channel control, lots of > > > > packets, etc. > > > > > > Could you elaborate a little bit please? how can you reproduce the issue? > > > just add an interface in monitor mode and run a scan? > > > > Correct, standard stuff, use iw to create a monitor mode interface, > > use iw to remove managed mode interface, run some tool such as kismet > > or airodump-ng or even wireshark. > > But what exactly are the syptomps, I don't understand what you mean by > "mt76x0 devices don't work properly in monitor mode" ? Basically, when I put a device using mt76x0 into monitor mode (adding a monitor interface with iw and removing the managed interface) it will not report packets on any channel, or sometimes it will report packets on one channel but not any others. I can switch channels as much, for example hopping channel 1-11, but it will only see packets on channel 7 and report no other packets on any other channels. In my actual test case it was channel 44 that successfully reported packets, but even that mostly doesn't work. I suspect the reason it reported packets on channel 44 in one of my tests is because the channel was set to 44 while in managed mode (connected to an AP). If I put the device in monitor mode before connecting to any AP, it reports packets on no channels. As such, I'm suspecting this has something to do with channel control in monitor mode. > > > > I guess it depends on eeprom values. Could you please enable debug > > > messages a paste > > > syslog output? > > > > I don't see a mediatek specific debug near the driver selection in > > menuconfig, what debug messages do you want me to enable and how? > > You need to uncomment this line: > > # ccflags-y := -DDEBUG > > in drivers/net/wireless/mediatek/mt76/mt76x0/Makefile found it. this box takes a few min to rebuild a kernel, so I'll get back with this response later today hopefully. Thanks, Zero > > Thanks > Stanislaw >
Re: mt76x0 bug report
On Tue, Sep 4, 2018 at 5:11 PM Lorenzo Bianconi wrote: > > > > > I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. > > > > I've noticed two additional issues in my testing. > > > > First issue, is that it appears the mt76x0 devices don't work properly > > in monitor mode. Sometimes they seem to monitor one channel properly, > > but nothing else. The mt76x2u works great, channel control, lots of > > packets, etc. > > Could you elaborate a little bit please? how can you reproduce the issue? > just add an interface in monitor mode and run a scan? Correct, standard stuff, use iw to create a monitor mode interface, use iw to remove managed mode interface, run some tool such as kismet or airodump-ng or even wireshark. > > > > > Second issue, and frankly a very minor one, is that the TP-Link T1U > > (which is a 5GHz only device) still thinks it has support for 2.4GHz, > > both in managed and monitor mode. > > I guess it depends on eeprom values. Could you please enable debug > messages a paste > syslog output? I don't see a mediatek specific debug near the driver selection in menuconfig, what debug messages do you want me to enable and how? Thanks, Zero > > > > > Lastly, I already mentioned in the other thread, but it would be > > awesome if firmware version was available to ethtool. > > > > Ack, I will take care of it > Regards, > > Lorenzo > > > Thanks for all your hard work on this, > > Zero
mt76x0 bug report
I have one mt76x2u (Alfa AWUS036ACM) and a few mt76x0. I've noticed two additional issues in my testing. First issue, is that it appears the mt76x0 devices don't work properly in monitor mode. Sometimes they seem to monitor one channel properly, but nothing else. The mt76x2u works great, channel control, lots of packets, etc. Second issue, and frankly a very minor one, is that the TP-Link T1U (which is a 5GHz only device) still thinks it has support for 2.4GHz, both in managed and monitor mode. Lastly, I already mentioned in the other thread, but it would be awesome if firmware version was available to ethtool. Thanks for all your hard work on this, Zero
Re: [PATCH 4.19] mt76x0: fix remove_interface
confirmed, I didn't intentionally remove the interface, but I do see something about the interface being removed in wpa_supplicant output. Thanks, Zero On Tue, Sep 4, 2018 at 10:23 AM Stanislaw Gruszka wrote: > > On Mon, Sep 03, 2018 at 09:36:37AM -0400, Sid Hayn wrote: > > Best I can say is that it seemed to happen after a failed connection. It > > would connect and disconnect a few times and work fine, but if it failed to > > connect for any reason (mostly mismatched settings between AP and > > wpa_supplicant.conf) then the bug would occur. So, wpa_supplicant would up > > the interface, try to connect, fail, down the interface and exit, then the > > next loop of my script (with a different conf file) would start and > > wpa_supplicant would be unable to up the interface. > > > > For bug fixes please always try to describe the bug and symptoms. I can > > > add it this time. From the other thread I saw that 'ifconfig up' failed > > > like this: > > > > > > SIOCSIFFLAGS: No space left on device > > > > > > But in what cases did that happen? (I assume not always) > > Problem will happen when we remove interface more than 8 times. > I'm not sure at how this can be triggerd execpt by doing: > > iw dev interface add type > iw dev del > > but looks somehow this is triggerd by Sid scripts > by just by using wpa_supplicant and ifconfig. > > Regards > Stanislaw
Re: [PATCH 4.19] mt76x0: fix remove_interface
Best I can say is that it seemed to happen after a failed connection.
It would connect and disconnect a few times and work fine, but if it
failed to connect for any reason (mostly mismatched settings between
AP and wpa_supplicant.conf) then the bug would occur. So,
wpa_supplicant would up the interface, try to connect, fail, down the
interface and exit, then the next loop of my script (with a different
conf file) would start and wpa_supplicant would be unable to up the
interface.
Hope that made any sense, because it didn't to me :-)
-Zero
On Mon, Sep 3, 2018 at 12:48 PM Kalle Valo wrote:
>
> Stanislaw Gruszka writes:
>
> > We wrongly use wcid_mask instead of vif_mask
> >
> > Fixes: 95e444098a7b ("mt76x0: main file")
> > Reported-and-tested-by: Sid Hayn
> > Signed-off-by: Stanislaw Gruszka
>
> For bug fixes please always try to describe the bug and symptoms. I can
> add it this time. From the other thread I saw that 'ifconfig up' failed
> like this:
>
> SIOCSIFFLAGS: No space left on device
>
> But in what cases did that happen? (I assume not always)
>
> --
> Kalle Valo
Re: [PATCH v2 00/17] mt76 patches 2018-08-24 v2
YES. That fixed the issue for me. Confirmed across 4 affected devices and 1 unaffected device (mt76x2u driver). After this patch the issue is resolved. Thanks for working with me. I haven't completed all my testing, but the only other thing I've noticed so far is that firmware version isn't available in ethtool, while the majority of devices it is. If you can please squeeze that in before 4.19 drops it would be great to help with tracking and debugging when needed. Thanks, Zero On Sat, Sep 1, 2018 at 7:48 AM Stanislaw Gruszka wrote: > > On Wed, Aug 29, 2018 at 02:26:44AM +0000, Sid Hayn wrote: > > dhcpcd_prestartinterface: t2uh: No space left on device > > t2uh: waiting for carrier > > > > the same happens with just ifconfig up: > > > > SIOCSIFFLAGS: No space left on device > > I think I found bug that could result in this. Please test > below patch: > > https://github.com/sgruszka/wireless-drivers-next/commit/be446879afd6b0e315691e379a2aa4412f05884e.patch > > Thanks > Stanislaw
Re: [PATCH v2 00/17] mt76 patches 2018-08-24 v2
I rebuilt wireless-testing (which updated today) with
CONFIG_DEBUG_KMEMLEAK=y. I am still able to replicate the issue, and
presently have 4 devices in the "No space left on device" state.
This is from /sys/kernel/debug/kmemleak:
unreferenced object 0x9183f9a4d000 (size 2048):
comm "iwconfig", pid 14872, jiffies 4295540797 (age 1233.338s)
hex dump (first 32 bytes):
46 00 00 00 00 00 00 00 05 00 00 00 00 00 00 00 F...
12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[<3ec4c8c4>] sta_set_sinfo+0x5d2/0x890 [mac80211]
[<8bbf0699>] ieee80211_get_station+0x4b/0x70 [mac80211]
[<30cbddbc>] cfg80211_wext_giwrate+0xdb/0x140 [cfg80211]
[<1e9277be>] ioctl_standard_call+0x49/0xd0
[<a0eeae49>] wext_handle_ioctl+0xbe/0x120
[<832bf9a4>] sock_ioctl+0x164/0x360
[<d3578d89>] do_vfs_ioctl+0xa3/0x6c0
[<36a4185e>] ksys_ioctl+0x6b/0x80
[<e8443423>] __x64_sys_ioctl+0x11/0x20
[<e2ddce89>] do_syscall_64+0x50/0xf0
[<5d6a8051>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[<e724c32b>] 0x
None of my scripts directly use iwconfig, but it is possible that
wpa_supplicant or dhcpcd invoke it (although a grep of their source
code indicates they do not). In case it matters, this is what my
wpa_supplicant invokation looks like:
wpa_supplicant -Dnl80211 -i ${interface} -c test_config/${conffile}
I am leaving the system in this state for now, I can resume from
broken or reboot to working for whatever testing you suggest next.
This is a test rig, so it takes a few but I'm happy to rebuild
whatever you want however you want it to debug this.
Thanks,
Zero
On Wed, Aug 29, 2018 at 10:27 AM Stanislaw Gruszka wrote:
>
> Hi Sid
>
> On Wed, Aug 29, 2018 at 02:26:44AM +, Sid Hayn wrote:
> > Thanks for working on this, I have a small stack of different devices
> > covered by this driver which I'm excited to test with.
> >
> > I'm running wireless-testing which may or may not be fully up to date
> > on the patches you have sent (head is at
> > c9cd161770dd1866207b70d41ec03c9a26eea94f from Aug 13th), so please
> > tell me if this has already been fixed. I have a script that attempts
> > to connect to 16 differently configured SSIDs using 33 different (yet
> > compatible) wpa_supplicant.conf files and reports failures to me.
> > It's hardly perfect, but it gives me an idea if something is obviously
> > broken and needs a deeper dive. When I run this script against a
> > device supported by mt76x2 or mt76x0 I get an unusual error.
> > Everything goes fine, connect, dhcp, disconnect, connect, dhcp,
> > disconnect, but after about 5 or 6 connections I start getting errors
> > like this during wpa_supplicant:
> >
> > Could not set interface t2uh flags (UP): No space left on device
> > nl80211: Could not set interface 't2uh' UP
> > nl80211: deinit ifname=t2uh disabled_11b_rates=0
> > t2uh: Failed to initialize driver interface
> >
> > and then this with dhcpcd:
> >
> > dhcpcd_prestartinterface: t2uh: No space left on device
> > t2uh: waiting for carrier
> >
> > the same happens with just ifconfig up:
> >
> > SIOCSIFFLAGS: No space left on device
>
> This looks like some memory leak, not sure where, but it quite probable
> that is in the m76x{0,2} driver. You can check periodically using 'free'
> command (or in more details by 'cat /proc/meminfo') if memory is
> leaking. Then compile kernel with CONFIG_DEBUG_KMEMLEAK to see where
> the leak happen.
>
> Regards
> Stanislaw
>
Re: [PATCH v2 00/17] mt76 patches 2018-08-24 v2
Stanislaw et al,
Thanks for working on this, I have a small stack of different devices
covered by this driver which I'm excited to test with.
I'm running wireless-testing which may or may not be fully up to date
on the patches you have sent (head is at
c9cd161770dd1866207b70d41ec03c9a26eea94f from Aug 13th), so please
tell me if this has already been fixed. I have a script that attempts
to connect to 16 differently configured SSIDs using 33 different (yet
compatible) wpa_supplicant.conf files and reports failures to me.
It's hardly perfect, but it gives me an idea if something is obviously
broken and needs a deeper dive. When I run this script against a
device supported by mt76x2 or mt76x0 I get an unusual error.
Everything goes fine, connect, dhcp, disconnect, connect, dhcp,
disconnect, but after about 5 or 6 connections I start getting errors
like this during wpa_supplicant:
Could not set interface t2uh flags (UP): No space left on device
nl80211: Could not set interface 't2uh' UP
nl80211: deinit ifname=t2uh disabled_11b_rates=0
t2uh: Failed to initialize driver interface
and then this with dhcpcd:
dhcpcd_prestartinterface: t2uh: No space left on device
t2uh: waiting for carrier
the same happens with just ifconfig up:
SIOCSIFFLAGS: No space left on device
I see nothing useful in dmesg, and this happens after multiple
successful connections. I've used this test setup before, and never
seen anything like this. I will be happy to provide more detail if
requested, but for now here is a list of the tested device which
exhibit this behavior (named for my convenience to the model):
phy1036acm mt76x2u MediaTek Inc.
phy0pau0a mt76x0 MediaTek Inc.
phy2t1u mt76x0
phy3t2u mt76x0 Ralink Technology, Corp.
MT7610U ("Archer T2U" 2.4G+5G WLAN Adapter
phy4t2uhmt76x0 Ralink Technology, Corp.
MT7610U ("Archer T2U" 2.4G+5G WLAN Adapter
Last thing I can think of, the tests were not conducted
simultaneously, meaning they didn't all start or fail at once. I had
multiple successful connections with each one before they
independently failed.
Hope that helps.
Thanks,
Zero_Chaos
(apologies if you got this twice, original bounced from ML)
On Mon, Aug 27, 2018 at 2:58 PM Stanislaw Gruszka wrote:
>
> This is the begin work of integration between mt76x0 and mt76x2.
>
> Further development can be seen here:
> https://github.com/sgruszka/wireless-drivers-next/commits/mt76x0-draft-v2
>
> v1 -> v2:
> - rename mt76xx to mt76x02 to reflect that common code is for mt76x0
> and mt76x2 only, not for new chips.
> - fixup 'stucture typo' in one patch
>
> Stanislaw Gruszka (17):
> mt76: unify wait_for_mac
> mt76: rename mt76x2_regs.h
> mt76: merge mt76x0/regs.h into mt76x02_regs.h
> mt76: create new mt76x02-lib module for common mt76x{0,2} code
> mt76: fix mt76x02-lib module license
> mt76: unify mac_get_key_info
> mt76: add helpers for register access with mt76_dev struct
> mt76: unify mac_shared_key_setup
> mt76: unify mt76x02_mac_wcid_set_key
> mt76: unify mac_wcid_setup
> mt76: use mac_wcid_set_drop in mt76x0
> mt76x0: use mt76_wcid_free in mt76x0
> mt76: unify mt76x02_vif struct
> mt76: unify sta structure part 1
> mt76: unify sta structure part 2
> mt76x0: initalize custom tx queues
> mt76x0: use mt76x02_sta and mt76x02_tx_status
>
> drivers/net/wireless/mediatek/mt76/Kconfig | 6 +
> drivers/net/wireless/mediatek/mt76/Makefile| 3 +
> drivers/net/wireless/mediatek/mt76/mac80211.c | 1 +
> drivers/net/wireless/mediatek/mt76/mt76.h | 13 +
> drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 37 +-
> drivers/net/wireless/mediatek/mt76/mt76x0/mac.c| 126 +---
> drivers/net/wireless/mediatek/mt76/mt76x0/mac.h| 8 +-
> drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 127 ++--
> drivers/net/wireless/mediatek/mt76/mt76x0/mcu.c| 4 +-
> drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.h | 35 +-
> drivers/net/wireless/mediatek/mt76/mt76x0/regs.h | 651
> drivers/net/wireless/mediatek/mt76/mt76x0/trace.h | 4 +-
> drivers/net/wireless/mediatek/mt76/mt76x0/tx.c | 8 +-
> drivers/net/wireless/mediatek/mt76/mt76x0/usb.c| 5 +-
> drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 157 +
> drivers/net/wireless/mediatek/mt76/mt76x02_mac.h | 85 +++
> drivers/net/wireless/mediatek/mt76/mt76x02_regs.h | 685
> +
> drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 55 ++
> drivers/net/wireless/mediatek/mt76/mt76x02_util.h | 25 +
> drivers/net/wireless/mediatek/mt76/mt76x2.h| 50 +-
> drivers/net/wireless/mediatek/mt76/mt76x2_common.c | 99 +--
> drivers/net/wireless/mediatek/mt76/mt76x2_init.c | 15 +-
> .../wireless/mediatek/mt76/mt76x2_init_common.c| 4 +-
> drivers/net/wireless/mediatek/mt76/mt76x2_mac.c| 4 +-
>
