This is a tentative fix for a long-standing issue [1] with MT7601U devices. In
my case, this is what I see in the dmesg when I plug the device in:
[ 660.810386] usb 1-7: new high-speed USB device number 119 using ehci-pci
[ 661.031390] usb 1-7: New USB device found, idVendor=148f,
idProduct=7601, bcdDevice= 0.00
[ 661.031400] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 661.031404] usb 1-7: Product: 802.11 n WLAN
[ 661.031408] usb 1-7: Manufacturer: MediaTek
[ 661.031411] usb 1-7: SerialNumber: 1.0
[ 661.200379] usb 1-7: reset high-speed USB device number 119 using ehci-pci
[ 661.403137] mt7601u 1-7:1.0: ASIC revision: 76010001 MAC revision: 76010500
[ 661.404566] mt7601u 1-7:1.0: Firmware Version: 0.1.00 Build: 7640
Build time: 201302052146____
[ 661.828765] mt7601u 1-7:1.0: EEPROM ver:0d fae:00
[ 662.005518] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71
[ 662.005525] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4!
[ 662.010015] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71
[ 662.010020] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4!
[ 662.014269] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71
[ 662.014275] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4!
[ 662.018516] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71
[ 662.018521] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4!
[ 662.022768] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71
[ 662.022775] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4!
[ 662.022779] mt7601u 1-7:1.0: Error: mt7601u_mcu_wait_resp timed out
[ 662.350350] mt7601u 1-7:1.0: Vendor request req:07 off:0080 failed:-71
[ 662.650344] mt7601u 1-7:1.0: Vendor request req:02 off:0080 failed:-71
[ 662.950339] mt7601u 1-7:1.0: Vendor request req:02 off:0080 failed:-71
[ 662.950389] mt7601u: probe of 1-7:1.0 failed with error -110
[ 662.950850] usb 1-7: USB disconnect, device number 119
This loops continuously. The device never comes up.
Turns out, this issue has been narrowed down to a possible calibration
problem [2]. Stanislaw repeatedly asked if disabling DPD calibration only
(keeping the RXIQ calibration) would fix the problem, but nobody seems to have
paid attention. :) Additionally, he asked for contents of
/sys/kernel/debug/ieee80211/phy0/mt7601u/eeprom_param, so here they are:
RF freq offset: 5f
RSSI offset: 0 0
Reference temp: f9
LNA gain: 0
Reg channels: 1-14
Per rate power:
raw:05 bw20:05 bw40:05
raw:05 bw20:05 bw40:05
raw:03 bw20:03 bw40:03
raw:03 bw20:03 bw40:03
raw:04 bw20:04 bw40:04
raw:00 bw20:00 bw40:00
raw:00 bw20:00 bw40:00
raw:00 bw20:00 bw40:00
raw:02 bw20:02 bw40:02
raw:00 bw20:00 bw40:00
Per channel power:
tx_power ch1:0c ch2:0c
tx_power ch3:0b ch4:0b
tx_power ch5:0a ch6:0a
tx_power ch7:0a ch8:0a
tx_power ch9:0a ch10:0a
tx_power ch11:0a ch12:0a
tx_power ch13:0a ch14:0a
The attached patch fixes the driver for me. Sending as RFC because this will
probably warrant some kind of quirk to be fixed correctly. Besides, there's an
additional DPD calibration in mt7601u_temp_comp, which I haven't touched, since
it seems a bit more convoluted. The driver works for me regardless (I've sent
this email through one of my MT7601U adapters).
[1] https://github.com/kuba-moo/mt7601u/issues/64
[2] https://github.com/kuba-moo/mt7601u/issues/64#issuecomment-352250127
Signed-off-by: Rui Salvaterra <[email protected]>
---
drivers/net/wireless/mediatek/mt7601u/phy.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/phy.c b/drivers/net/wireless/mediatek/mt7601u/phy.c
index 8a00f6a75ca9..daa6a042f2c7 100644
--- a/drivers/net/wireless/mediatek/mt7601u/phy.c
+++ b/drivers/net/wireless/mediatek/mt7601u/phy.c
@@ -589,8 +589,6 @@ void mt7601u_phy_recalibrate_after_assoc(struct mt7601u_dev *dev)
if (test_bit(MT7601U_STATE_REMOVED, &dev->state))
return;
- mt7601u_mcu_calibrate(dev, MCU_CAL_DPD, dev->curr_temp);
-
mt7601u_rxdc_cal(dev);
}
@@ -1157,9 +1155,6 @@ static int mt7601u_init_cal(struct mt7601u_dev *dev)
if (ret)
return ret;
ret = mt7601u_mcu_calibrate(dev, MCU_CAL_RXIQ, 0);
- if (ret)
- return ret;
- ret = mt7601u_mcu_calibrate(dev, MCU_CAL_DPD, dev->dpd_temp);
if (ret)
return ret;
--
2.31.1
On Tue, May 04, 2021 at 10:28:28PM +0100, Rui Salvaterra wrote:
> This is a tentative fix for a long-standing issue [1] with MT7601U devices. In
> my case, this is what I see in the dmesg when I plug the device in:
>
> [ 660.810386] usb 1-7: new high-speed USB device number 119 using ehci-pci
> [ 661.031390] usb 1-7: New USB device found, idVendor=148f,
> idProduct=7601, bcdDevice= 0.00
> [ 661.031400] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ 661.031404] usb 1-7: Product: 802.11 n WLAN
> [ 661.031408] usb 1-7: Manufacturer: MediaTek
> [ 661.031411] usb 1-7: SerialNumber: 1.0
> [ 661.200379] usb 1-7: reset high-speed USB device number 119 using ehci-pci
> [ 661.403137] mt7601u 1-7:1.0: ASIC revision: 76010001 MAC revision: 76010500
> [ 661.404566] mt7601u 1-7:1.0: Firmware Version: 0.1.00 Build: 7640
> Build time: 201302052146____
> [ 661.828765] mt7601u 1-7:1.0: EEPROM ver:0d fae:00
> [ 662.005518] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71
> [ 662.005525] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4!
> [ 662.010015] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71
> [ 662.010020] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4!
> [ 662.014269] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71
> [ 662.014275] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4!
> [ 662.018516] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71
> [ 662.018521] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4!
> [ 662.022768] mt7601u 1-7:1.0: Error: MCU resp urb failed:-71
> [ 662.022775] mt7601u 1-7:1.0: Error: MCU resp evt:0 seq:5-4!
> [ 662.022779] mt7601u 1-7:1.0: Error: mt7601u_mcu_wait_resp timed out
> [ 662.350350] mt7601u 1-7:1.0: Vendor request req:07 off:0080 failed:-71
> [ 662.650344] mt7601u 1-7:1.0: Vendor request req:02 off:0080 failed:-71
> [ 662.950339] mt7601u 1-7:1.0: Vendor request req:02 off:0080 failed:-71
> [ 662.950389] mt7601u: probe of 1-7:1.0 failed with error -110
> [ 662.950850] usb 1-7: USB disconnect, device number 119
>
> This loops continuously. The device never comes up.
> Turns out, this issue has been narrowed down to a possible calibration
> problem [2]. Stanislaw repeatedly asked if disabling DPD calibration only
> (keeping the RXIQ calibration) would fix the problem, but nobody seems to have
> paid attention. :) Additionally, he asked for contents of
> /sys/kernel/debug/ieee80211/phy0/mt7601u/eeprom_param, so here they are:
>
> RF freq offset: 5f
> RSSI offset: 0 0
> Reference temp: f9
> LNA gain: 0
> Reg channels: 1-14
> Per rate power:
> raw:05 bw20:05 bw40:05
> raw:05 bw20:05 bw40:05
> raw:03 bw20:03 bw40:03
> raw:03 bw20:03 bw40:03
> raw:04 bw20:04 bw40:04
> raw:00 bw20:00 bw40:00
> raw:00 bw20:00 bw40:00
> raw:00 bw20:00 bw40:00
> raw:02 bw20:02 bw40:02
> raw:00 bw20:00 bw40:00
> Per channel power:
> tx_power ch1:0c ch2:0c
> tx_power ch3:0b ch4:0b
> tx_power ch5:0a ch6:0a
> tx_power ch7:0a ch8:0a
> tx_power ch9:0a ch10:0a
> tx_power ch11:0a ch12:0a
> tx_power ch13:0a ch14:0a
>
> The attached patch fixes the driver for me. Sending as RFC because this will
> probably warrant some kind of quirk to be fixed correctly. Besides, there's an
> additional DPD calibration in mt7601u_temp_comp, which I haven't touched, since
> it seems a bit more convoluted. The driver works for me regardless (I've sent
> this email through one of my MT7601U adapters).
I'm not sure if DPD calibration is needed. Maybe is ok to disable it for
all MT7601U devices. However safer fix would be doing it only for
devices that know to need it for work. For example: add dev->no_dpd_cal
variable, set it based on USB ID (using usb_device_id->driver_info) and
do not perfrom calibration when it's set.
Also please clarify "work again" in the topic. Have your device ever
worked with mt7601u driver in some older kernel version?
Stanislaw
Hi, Stanislaw,
On Wed, 5 May 2021 at 05:50, Stanislaw Gruszka <[email protected]> wrote:
>
> I'm not sure if DPD calibration is needed. Maybe is ok to disable it for
> all MT7601U devices. However safer fix would be doing it only for
> devices that know to need it for work. For example: add dev->no_dpd_cal
> variable, set it based on USB ID (using usb_device_id->driver_info) and
> do not perfrom calibration when it's set.
Hm… the struct usb_device already contains a u32 quirks. Shouldn't it
be used instead, or is it used for an entirely different set of
quirks?
> Also please clarify "work again" in the topic. Have your device ever
> worked with mt7601u driver in some older kernel version?
Personally, my devices never worked. I ordered a bunch of them
dirt-cheap from AliExpress, in early 2019. I needed one for my RPi,
running OpenWrt 19.07 (Linux 4.19), but it failed the same way. I
thought it might be a problem with the driver on ARM, I replaced it
with a Ralink adapter and it worked fine. I hadn't used the devices
until a couple of days ago, when I needed to connect a x86 machine and
saw the exact same error I had seen on the Pi.
Thanks
Rui
Hi
On Wed, May 05, 2021 at 09:01:52AM +0100, Rui Salvaterra wrote:
> On Wed, 5 May 2021 at 05:50, Stanislaw Gruszka <[email protected]> wrote:
> >
> > I'm not sure if DPD calibration is needed. Maybe is ok to disable it for
> > all MT7601U devices. However safer fix would be doing it only for
> > devices that know to need it for work. For example: add dev->no_dpd_cal
> > variable, set it based on USB ID (using usb_device_id->driver_info) and
> > do not perfrom calibration when it's set.
>
> Hm… the struct usb_device already contains a u32 quirks. Shouldn't it
> be used instead, or is it used for an entirely different set of
> quirks?
Yes, those u32 quirks are used to change behaviour of usb-core module
and we should not interfere with them. We need quirk for mt7601u driver.
> > Also please clarify "work again" in the topic. Have your device ever
> > worked with mt7601u driver in some older kernel version?
>
> Personally, my devices never worked. I ordered a bunch of them
> dirt-cheap from AliExpress, in early 2019. I needed one for my RPi,
> running OpenWrt 19.07 (Linux 4.19), but it failed the same way. I
> thought it might be a problem with the driver on ARM, I replaced it
> with a Ralink adapter and it worked fine. I hadn't used the devices
> until a couple of days ago, when I needed to connect a x86 machine and
> saw the exact same error I had seen on the Pi.
Ok, please correct the topic of the patch when you'll be posting next
version.
Thanks
Stanislaw
Hi again, Stanislaw,
I was meanwhile wondering if we could try and unconditionally drop the
DPD calibration from the driver, and see if anyone complains. You said
it yourself [1] the vendor driver has DPD calibration under
conditional compilation (I don't know which conditions, though, I
haven't looked at it). As far as testing is concerned, all my devices
are 148f:7601, so it would be nice for people with other USB IDs to
test them.
[1] https://github.com/kuba-moo/mt7601u/issues/64#issuecomment-479801642
On Wed, 5 May 2021 at 10:25, Stanislaw Gruszka <[email protected]> wrote:
>
> Yes, those u32 quirks are used to change behaviour of usb-core module
> and we should not interfere with them. We need quirk for mt7601u driver.
Right, thanks for clarifying.
> Ok, please correct the topic of the patch when you'll be posting next
> version.
Will do.
Thanks,
Rui
Hi
On Wed, May 05, 2021 at 10:38:58AM +0100, Rui Salvaterra wrote:
> Hi again, Stanislaw,
>
> I was meanwhile wondering if we could try and unconditionally drop the
> DPD calibration from the driver, and see if anyone complains. You said
> it yourself [1] the vendor driver has DPD calibration under
> conditional compilation (I don't know which conditions, though, I
> haven't looked at it). As far as testing is concerned, all my devices
> are 148f:7601, so it would be nice for people with other USB IDs to
> test them.
>
> [1] https://github.com/kuba-moo/mt7601u/issues/64#issuecomment-479801642
I don't know if it's safe to remove DPD calibration in mt7601u driver
for all supported devices. Possibly it is. I don't have my device any
longer, but as far I remember removing DPD was harmless for my device.
But can not assure that this does not break support for some other
devices or cause not easy to notice issue like performance drop on
some specific conditions.
Regards
Stanislaw
Hi, again,
Well, this was "fun"… I rebased my patch on top of 5.13-rc1 and now my
MT7601U adapters are broken again. I tried different combinations of
mine and the the last two upstream patches [1][2], but the result is
the same, so now I have no idea of what's going on.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/mediatek/mt7601u?h=v5.13-rc1&id=87fce88658ba047ae62e83497d3f3c5dc22fa6f9
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/mediatek/mt7601u?h=v5.13-rc1&id=670d9e53886c942b7f29c475b2b494278e586921
Thanks,
Rui
On 11/05/2021 11:13, Rui Salvaterra wrote:
> Hi, again,
>
> Well, this was "fun"… I rebased my patch on top of 5.13-rc1 and now my
> MT7601U adapters are broken again. I tried different combinations of
> mine and the the last two upstream patches [1][2], but the result is
> the same, so now I have no idea of what's going on.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/mediatek/mt7601u?h=v5.13-rc1&id=87fce88658ba047ae62e83497d3f3c5dc22fa6f9
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/mediatek/mt7601u?h=v5.13-rc1&id=670d9e53886c942b7f29c475b2b494278e586921
If reverting the above patches does not work, I suspect a bisect is
required to corner the exact reason.
>
> Thanks,
> Rui
>
Hi, Colin,
On Tue, 11 May 2021 at 11:16, Colin Ian King <[email protected]> wrote:
>
> If reverting the above patches does not work, I suspect a bisect is
> required to corner the exact reason.
Sure, I was just trying to be as lazy as possible, but I guess there's
no way around it. :)
Thanks,
Rui
On 11/05/2021 11:21, Rui Salvaterra wrote:
> Hi, Colin,
>
> On Tue, 11 May 2021 at 11:16, Colin Ian King <[email protected]> wrote:
>>
>> If reverting the above patches does not work, I suspect a bisect is
>> required to corner the exact reason.
>
> Sure, I was just trying to be as lazy as possible, but I guess there's
> no way around it. :)
Lazy is good when it works :-) I'm all for that.
>
> Thanks,
> Rui
>
Hi, again,
So much for bisecting. Turns out, while trying to bisect on a faster
machine, I discovered my MT7601U adapters are also broken on 5.12,
with my patch. They're working on a Pentium D 950 and broken on an
i7-4770R. The only obvious differences I see are the CPU speeds and
USB controllers (USB 2.0 vs 3.0).
Since there's only a certain amount of weirdness I can handle on one
day, I'm stepping back on this one, for now.
Thanks,
Rui