mt7603 continues to interrupt MT7621 cpu after radio0 is disabled
Open
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:

Steps to reproduce:
- Ensure mt7603/radio0 and mt76x2/radio1 are enabled in Luci
- 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"'
- Disable mt7603/radio0 in Luci
- Then disable mt76x2/radio1 in Luci
- Note interrupt behaviour
- Reenable mt7603/radio0 and mt76x2/radio1 in Luci
- 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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