How to test MediaTek mt7921!

Hi,

I have tried to get all the noise and minimal other changes into main and
stable/15 which are needed for Mediatek mt7921 support and I am down to
the last 4 reviews up so people can start testing Mediatek mt7921
(that includes mt7920 and mt7922 aka. AMD RZ616; it does NOT include
mt7925! see the last item of the email).  If you want to test please read
to the end.

The reviews are the following:
 	https://reviews.freebsd.org/D58320 LinuxKPI: Add PAGE_IS_LKPI_PAGE for Linux struct page instead of vm_page
 	https://reviews.freebsd.org/D58498 LinuxKPI: turn on PAGE_IS_LKPI_PAGE
 	https://reviews.freebsd.org/D58479 mt76: mt7921: update man page
 	https://reviews.freebsd.org/D58499 mt76: hook up to the build, for now only compile core and mt7921 modules

They should apply to main and stable/15, with stable/15 needing an extra MFC of
 	7925256edc74 fwget: update MediaTek firmware listings to match ports
as well, which I'll do end of the week.

I have not yet tried stable/15 myself but will do so by the end of week as well
then.

D58320 is the one which needs thorough review from people who do understand
more than me of the VM subsystem;  as dumbbell indicates drm-kmod works for
him on his development branches, which is quite cool.  Whether or not the
concept of what I have done will hold up is a different story.  I hope someone
will optmize it.

Page pools are stripped down in the tree to essentially not pool, not reuse
pages but alloc/free each one.  Once the PAGE_IS_LKPI_PAGE changes are sorted
we can start adding pooling as well.


* How to apply these changes?   If you are a developer or if you are using arc
you can just apply them to your tree as it fits your workflow.
If not, there is also a link on the reviews on the right side "Download raw
diff" and then you can apply them in order.
If you have trouble doing so, please let us know and we can help each other.
Beware that if the man page gets reviewed I might commit that so you do no
longer need it;  if any of the others will go in I hope to announce that.
There are no pre-compiled images or the like at this point.


* Please run fwget (on main) *before* rebooting into the new kernel!  This
assumes you have the updated fwget already.  If you do not please update
that first; if you are on stable/15 you need to cherry-pick the above hash
yourself and rebuild/install fwget.
Or you manually install the wifi-firmware-mt76-kmod-mt7921 package (again
before booting into the new kernel) in the meantime (works on both branches).


* Caveat:  if you are using drm-kmod you will have to re-compile it yourself
along with your kernel (or after installing but before booting a new one).
You cannot use a precompiled package!  You can also only use drm-kmod
6.6-lts, 6.12-lts or drm-kmod master.  If you rely on an older version that
is not supported! (*)
This is because the change from struct vm_page to Linux struct page also need
changes in drm-kmod and in those versions the #ifdefs are prepared.

(*) I may have a patch for 6.1-lts still lying around.  Let me know if you
want to test.


* In theory the module should be auto-detected and loaded by devmatch, it will
load firmware from /boot/firmware and you can create an interface as you would
normally do for mt79210.  This is all the same as iwlwifi or rtw88/rtw89 work.
There is nothing else you need to do than adjust your rc.conf and possibly
configure wpa_supplicant.conf; here's a sample for rc.conf -- adjust
regdomain/country and IPv4/IPv6 to your needs!  It's the normal stuff
which is true for all other wireless too.

wlans_mt79210="wlan0"
create_args_wlan0="wlanmode sta regdomain etsi country DE"
ifconfig_wlan0="up WPA"
ifconfig_wlan0_ipv6="inet6 -ifdisabled accept_rtadv"

The driver should support 802.11a/b/g/n/ac:

wlan790: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
         options=0
         ether c8:a3:e8:xx:xx:xx
         groups: wlan
         ssid fbsdmt76 channel 100 (5500 MHz 11a vht/160) bssid vv:vv:vv:xx:xx:xx
         regdomain ETSI country DE authmode WPA2/802.11i privacy ON
         deftxkey UNDEF AES-CCM 3:128-bit AES-CCM ucast:128-bit txpower 26
         bmiss 7 mcastrate 6 mgmtrate 6 scanvalid 60 ampdulimit 64k
         -amsdutx amsdurx shortgi -ldpctx ldpcrx -uapsd vht vht40 vht80 vht160
         -vht80p80 wme roaming MANUAL
         parent interface: mt79210
         media: IEEE 802.11 Wireless Ethernet VHT mode 11ac
         status: associated
         nd6 options=863<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_RADR,STABLEADDR>


* In practise testing over different access points and radio environments (more or
less noisy) it performs more or less and more or less stable.  I had iperf runs
running for hours and I had them fail after several seconds.

If it re-loads firmware something went wrong and a simple down/up (not a restart
hammer may do);
if you see messages similar to "mt79210: Message 00020003 (seq 6) timeout",
you will have to reboot (cold; power off, wait 5s, power on) -- urban myth or
real solution of the internet;  you can find a lot of these for the problems
people have and had on Linux.


* I have observed a TX skb leak once and I could not reproduce it;  so I am not sure
if there is still something lingering with the driver or if it was one of the
conditions where it stopped TXing but still dequeued the packets;
it will look like this (I marked the numbers for mbuf/skb header/skb data):

# netstat -m
415466/4159/419625 mbufs in use (current/cache/total)
414116/4338/418454/507360 mbuf clusters in use (current/cache/total/max)
414115/1683 mbuf+clusters out of packet secondary zone in use (current/cache)
^^^^^^
# vmstat -m | grep lkpiskb
             Type  Use Memory Req Size(s)
          lkpiskb 414119 1696231424 14974840
                  ^^^^^^
  # vmstat -z | grep -i skbuff
ITEM                   SIZE   LIMIT     USED     FREE      REQ FAIL SLEEP XDOM
skbuff:                1808,      0,  414119,    9781,14992857,   0,   0,   0
                                       ^^^^^^


* As of end of last year you can also pass the PCI device into bhyve, in case
you want to do that for initial testing.


* If anything goes wrong boot into single user and add
   devmatch_blacklist="${devmatch_blacklist} if_mt7921"
   to rc.conf, which will prevent the driver from being automatically loaded.


* If you have made it to here:  in case of problems please follow-up here mentioning
   384753 in the first lines of the email, follow-up on PR 264300 or create a
   new wireless PR blocking 273623.



* mt7925 and the other chipsets.
   mt7925 needs an update to the LinuxKPI IDR implementation, which is also used
   by a lot of semi-native drivers in src.git.
   As soon as that review is out I'll also enable that driver.  Until then please
   be patient.
   mt7915 needs IDR and likely some software scanning work, which will come when
   I find time, as will the other chipsets (mt7615 is old but still interesting
   as people are working on SoC support and mt7996) then see support.


I've been staring at all this for way too long so have fun (I hope).  For all
other questions simply reply to this email (but don't fully quote it if possible).

I may take a day or two to reply these days!

Lots of health and joy,
/bz

-- 
Bjoern A. Zeeb                                                     r15:7