25.12.0rc2: mt7921u "vendor request failed"

I have two nearly-identical x86 OpenWrt boxes in service, one with 24.10.5 and one with 25.12.0rc2 installed. Both have an mt7921u-based USB wifi adaptor used to provide a 2.4Ghz AP for a few IoT devices. The 24.10-based box worked flawlessly in this capacity for over a year. The second, 25.12-based box develops a problem after around (give or take) three days of continuous operation, where the wifi goes down, and the kernel emits copious log lines like the following:

[288466.570120] mt7921u 3-5:1.0: vendor request req:63 off:d7ec failed:-110
[288469.770051] mt7921u 3-5:1.0: vendor request req:63 off:d7e0 failed:-110
[288472.959988] mt7921u 3-5:1.0: vendor request req:63 off:d7f0 failed:-110
[288476.159921] mt7921u 3-5:1.0: vendor request req:63 off:d7e4 failed:-110
[288479.369764] mt7921u 3-5:1.0: vendor request req:63 off:d7f4 failed:-110
[288482.569806] mt7921u 3-5:1.0: vendor request req:63 off:d7e8 failed:-110
[288485.779639] mt7921u 3-5:1.0: vendor request req:63 off:d7f8 failed:-110
[288488.989586] mt7921u 3-5:1.0: vendor request req:63 off:d02c failed:-110
[288492.199581] mt7921u 3-5:1.0: vendor request req:63 off:d054 failed:-110
[288495.419513] mt7921u 3-5:1.0: vendor request req:63 off:d058 failed:-110
[288498.619448] mt7921u 3-5:1.0: vendor request req:63 off:53b8 failed:-110
[288501.839393] mt7921u 3-5:1.0: vendor request req:63 off:53c4 failed:-110
[288505.049333] mt7921u 3-5:1.0: vendor request req:66 off:53c4 failed:-110
[288508.279242] mt7921u 3-5:1.0: vendor request req:63 off:d02c failed:-110
[288511.509187] mt7921u 3-5:1.0: vendor request req:63 off:d054 failed:-110
[288514.729125] mt7921u 3-5:1.0: vendor request req:63 off:d058 failed:-110
[288517.939048] mt7921u 3-5:1.0: vendor request req:63 off:53b8 failed:-110
[288521.138980] mt7921u 3-5:1.0: vendor request req:63 off:53c4 failed:-110

Swapping the USB wifi adapters between the two hosts has no effect; it seems like any of the adapters will contract this strange disease on 25.12 after a while, given enough exposure. Replugging the USB wifi device does nothing, but rebooting the host will. (I just did so and can't tell if there are any OTHER kernel messages screamed into dmesg right when the problem starts to afflict the device, due to log buffer size - or rather, a lack thereof.)

Any ideas how to debug/diagnose this issue?

Obligatory system details:

# ubus call system board
{
        "kernel": "6.12.63",
        "hostname": "lag17",
        "system": "Intel(R) N97",
        "model": "Default string Default string",
        "board_name": "default-string-default-string",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "25.12.0-rc2",
                "firmware_url": "https://downloads.openwrt.org/",
                "revision": "r32429-d76c64ad00",
                "target": "x86/64",
                "description": "OpenWrt 25.12.0-rc2 r32429-d76c64ad00",
                "builddate": "1767653330"
        }
}
# lsusb -v -d 0e8d:7961

Bus 003 Device 002: ID 0e8d:7961 MediaTek Inc. Wireless_Device
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0e8d MediaTek Inc.
  idProduct          0x7961 Wireless_Device
  bcdDevice            1.00
  iManufacturer           2 MediaTek Inc.
  iProduct                3 Wireless_Device
  iSerial                 4 000000000
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0051
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          5 Config_01
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           9
      bInterfaceClass       255 [unknown]
      bInterfaceSubClass    255 [unknown]
      bInterfaceProtocol    255 
      iInterface              1 WiFi_If
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x08  EP 8 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x06  EP 6 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x07  EP 7 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x09  EP 9 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval               1
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x0016
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x0000f11e
      BESL Link Power Management (LPM) Supported
    BESL value      256 us 
    Deep BESL value    61440 us 
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat         180 micro seconds
Device Status:     0x0002
  (Bus Powered)
  Remote Wakeup Enabled

Thanks for any pointers! :slight_smile:

Add more -v parameters to check power budgets.

Additional -vs do not change/extend the output on my system. So I guess MaxPower 100mA it is :slight_smile:

I noticed I left out this potentially relevant bit of info that gets logged upon hardware init:

[   12.410633] mt7921u 3-5:1.0: HW/SW Version: 0x8a108a10, Build Time: 20231109190918a
[   12.442559] mt7921u 3-5:1.0: WM Firmware Version: ____010000, Build Time: 20231109190959

I have set up remote logging on the affected host now, let's see if there'll be anything interesting in the ringbuffer before the "vendor request" flood goes off...

So this just happened again last night, even though I disabled any host-initated power saving (wie powertop --auto-tune) this uptime around. There is no other related message in dmesg output before the device flunks out like described above.

I upgraded to rc3, and will see if that changes anything.

I did notice that I have to fully power-cycle the USB wifi adaptor after this happens to make it work again (i.e., unplug, plug in again) - it will not register on the USB after a simple reboot.

Try other USB port - from lsusb -t being alone on new USB bus - certainly not together with active storage or gigabit net.

You might actually want un-powertop whole usb tree driving the wifi card.

Could be hardware power issue.

mainboards vary a lot regarding available USB power wiring per port.

It could be that one board has the 5v power of 2 USB ports combined, while the other has not. So that as long as only a single device is attached, if can consume twice of the amperes of what is actually allowed in the USB host spec.

There are also mainboards that do not deliver the max amperes of what a single USB port would be allowed per spec.

Try a different host port, a Y adapter (that merges the power of 2 host ports to a single USB device or an USB hub that has its own power supply, to see if that resolves it.

Thanks for these sensible suggestions, I will try implementing that once the problem occurs again on rc3, and report back in this thread :slight_smile: