openwrt / openwrt/mt76

mt7603 continues to interrupt MT7621 cpu after radio0 is disabled

Open
#135 17 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
888
Forks
436
PR merge metrics
No merged PRs in 30d

Description

Test Device:

OpenWrt GCC 5.5.0 r5484-69d22a6 (buildbot)
MediaTek MT7621 Netgear WNDR3700v5

Video:

interupts

Steps to reproduce:
  1. Ensure mt7603/radio0 and mt76x2/radio1 are enabled in Luci
  2. Open a new SSH connection and continually check /proc/interrupts using watch command
opkg update && opkg install procps-ng-watch
watch -c -n 0.1 'cat /proc/interrupts | grep "mt76"'
  1. Disable mt7603/radio0 in Luci
  2. Then disable mt76x2/radio1 in Luci
  3. Note interrupt behaviour
  4. Reenable mt7603/radio0 and mt76x2/radio1 in Luci
  5. Open another SSH connection and run the commands whilst monitoring interrupts
wifi down radio0
wifi up radio0
wifi down radio1
wifi up radio1
Observations
  • The mt7603 processor interrupts increment when radio0 is disabled in Luci
  • The mt7603 processor interrupts do not increment using Wifi down command
  • The mt76x2 processor interrupts do not increment in /proc/interrupts when it's radio1 is disabled using Luci or via wifi down command
Questions:
  • Is it expected behaviour for the mt7603 driver to interrupt even when its radio is disabled in Luci?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the Luci and wifi down/up sequences on the listed MT7621 device while watching /proc/interrupts for mt76 entries. Compare mt7603 and mt76x2 behavior after each radio is disabled; done means determining whether the mt7603 interrupts are expected and documenting or addressing the confirmed behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
embedded-iot, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.