[9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[sl]

http://helpful.cat-v.org/Blog/2023/06/03/0/

sl

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[hiro]

> In lieu of actual code fixes, it’s always possible to fall back to an Ethernet to WiFi bridge. One major benefit of this approach, even on machines with working mPCIe cards, is vastly greater speeds in general. For example, the IOgear GWU637 supports 300mpbs on 2.4GHz and works fine with every WiFi network I’ve tested it on. Just velcro it or something similar onto your machine and try not to trip over the cables.

what is the tput result for the "300mbps" bridge?

On 6/4/23, sl@stanleylieber.com <sl@stanleylieber.com> wrote:
> http://helpful.cat-v.org/Blog/2023/06/03/0/
>
> sl
>

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[sl]

> what is the tput result for the "300mbps" bridge?

x1 yoga 3rd gen w/ ethernet to wifi bridge:

; cat /n/rachael/usr/bin/* | tput
406.34 KB/s
406.86 KB/s
433.90 KB/s
392.23 KB/s
411.39 KB/s
426.37 KB/s
412.73 KB/s
405.03 KB/s
415.13 KB/s
419.22 KB/s
418.93 KB/s
418.68 KB/s
420.32 KB/s
415.44 KB/s
420.81 KB/s
426.01 KB/s
427.78 KB/s
431.57 KB/s
435.38 KB/s
438.81 KB/s
440.77 KB/s
441.46 KB/s
441.40 KB/s
442.68 KB/s
443.21 KB/s
444.32 KB/s
446.82 KB/s
448.58 KB/s
449.94 KB/s
451.21 KB/s
452.39 KB/s
453.76 KB/s
454.07 KB/s

thanks, i've added this to the article.

sl

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[hiro]

so, like a factor 5.
2.4ghz wifi is useless for me here even with linux/windows/android. i
live in a higher density area with too much interference from
neighbors.
5ghz stuff otoh has much more regular latencies, i.e. less jitter from
re-transmissions after collisions. probably mainly bec. the
attenuation in our brick walls is a lot higher for 5ghz (unlike for
2.4ghz).
also, there's less other crap l ike bluetooth on the 5ghz band. 2.4ghz
is way too overcrowded.
the big big big downside though is that there aren't many usable bands
in 5ghz that aren't plagued by DFS procedures, also making all but 4
channels practically unusable in my area. still, for me, 5ghz still
helps a lot, just it isn't good enough when you don't have nice brick
walls (i.e. it's great in old european 100 years old houses. but sucks
in america).

i have high hopes for wifi6E or wifi7 devices with full 6ghz band
support. i think once there is a driver and hostapd support for this
on linux/bsd, it will become very much worth the effort to try and
support it fully.
6ghz stuff might finally become universally useful internationally.

On 6/4/23, sl@stanleylieber.com <sl@stanleylieber.com> wrote:
>> what is the tput result for the "300mbps" bridge?
>
> x1 yoga 3rd gen w/ ethernet to wifi bridge:
>
> ; cat /n/rachael/usr/bin/* | tput
> 406.34 KB/s
> 406.86 KB/s
> 433.90 KB/s
> 392.23 KB/s
> 411.39 KB/s
> 426.37 KB/s
> 412.73 KB/s
> 405.03 KB/s
> 415.13 KB/s
> 419.22 KB/s
> 418.93 KB/s
> 418.68 KB/s
> 420.32 KB/s
> 415.44 KB/s
> 420.81 KB/s
> 426.01 KB/s
> 427.78 KB/s
> 431.57 KB/s
> 435.38 KB/s
> 438.81 KB/s
> 440.77 KB/s
> 441.46 KB/s
> 441.40 KB/s
> 442.68 KB/s
> 443.21 KB/s
> 444.32 KB/s
> 446.82 KB/s
> 448.58 KB/s
> 449.94 KB/s
> 451.21 KB/s
> 452.39 KB/s
> 453.76 KB/s
> 454.07 KB/s
>
> thanks, i've added this to the article.
>
> sl
>

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[Stanley Lieber]

On June 4, 2023 3:32:15 PM EDT, hiro <23hiro@gmail.com> wrote:
>so, like a factor 5.
>2.4ghz wifi is useless for me here even with linux/windows/android. i
>live in a higher density area with too much interference from
>neighbors.
>5ghz stuff otoh has much more regular latencies, i.e. less jitter from
>re-transmissions after collisions. probably mainly bec. the
>attenuation in our brick walls is a lot higher for 5ghz (unlike for
>2.4ghz).
>also, there's less other crap l ike bluetooth on the 5ghz band. 2.4ghz
>is way too overcrowded.
>the big big big downside though is that there aren't many usable bands
>in 5ghz that aren't plagued by DFS procedures, also making all but 4
>channels practically unusable in my area. still, for me, 5ghz still
>helps a lot, just it isn't good enough when you don't have nice brick
>walls (i.e. it's great in old european 100 years old houses. but sucks
>in america).
>
>i have high hopes for wifi6E or wifi7 devices with full 6ghz band
>support. i think once there is a driver and hostapd support for this
>on linux/bsd, it will become very much worth the effort to try and
>support it fully.
>6ghz stuff might finally become universally useful internationally.
>
>On 6/4/23, sl@stanleylieber.com <sl@stanleylieber.com> wrote:
>>> what is the tput result for the "300mbps" bridge?
>>
>> x1 yoga 3rd gen w/ ethernet to wifi bridge:
>>
>> ; cat /n/rachael/usr/bin/* | tput
>> 406.34 KB/s
>> 406.86 KB/s
>> 433.90 KB/s
>> 392.23 KB/s
>> 411.39 KB/s
>> 426.37 KB/s
>> 412.73 KB/s
>> 405.03 KB/s
>> 415.13 KB/s
>> 419.22 KB/s
>> 418.93 KB/s
>> 418.68 KB/s
>> 420.32 KB/s
>> 415.44 KB/s
>> 420.81 KB/s
>> 426.01 KB/s
>> 427.78 KB/s
>> 431.57 KB/s
>> 435.38 KB/s
>> 438.81 KB/s
>> 440.77 KB/s
>> 441.46 KB/s
>> 441.40 KB/s
>> 442.68 KB/s
>> 443.21 KB/s
>> 444.32 KB/s
>> 446.82 KB/s
>> 448.58 KB/s
>> 449.94 KB/s
>> 451.21 KB/s
>> 452.39 KB/s
>> 453.76 KB/s
>> 454.07 KB/s
>>
>> thanks, i've added this to the article.
>>
>> sl
>>
>

i get different kinds of transient problems depending on different combinations of factors, but the disparity between mpcie and m.2 cards is pretty consistent. i don't know if the type of pci connection really matters at all, or if it's just a coincidence that these newer cards suddenly perform so much worse precisely when they switched to m.2.

i haven't researched ethernet to wifi bridges methodically. the iogear thing worked well enough that i didn't continue buying new devices. it seems likely there are more options than just 2.4ghz, but this thing is very small and fairly cheap and actually works for my use case.

yes, wifi sucks, but the same hardware us usable for my tasks on other operating systems, but sucks with 9front. this to me suggests that wifi sucking isn't the whole story.

sl

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[hiro]

> i get different kinds of transient problems depending on different
> combinations of factors, but the disparity between mpcie and m.2 cards is
> pretty consistent. i don't know if the type of pci connection really matters
> at all, or if it's just a coincidence that these newer cards suddenly
> perform so much worse precisely when they switched to m.2.
>

i'm 99% sure it's coincidence, the pcie version or connector shape
shouldn't matter.

> yes, wifi sucks, but the same hardware us usable for my tasks on other
> operating systems, but sucks with 9front. this to me suggests that wifi
> sucking isn't the whole story.

latency hurts our 9p throughput even more if it is combined with the
typical wifi packet-loss/retransmissions. that's definitely unique to
9p and thus 9front.

apart from that, our drivers lack higher throughput modes like HT and VHT.

i pointed out before that ath5k was generally quite nice hardware,
might be worth targeting, but the more we wait, the more it's worth
skipping all this stuff and going straight to devices that support the
6ghz band instead.

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[mkf9]

sl@stanleylieber.com wrote:
> http://helpful.cat-v.org/Blog/2023/06/03/0/
> 
> sl
> 
Nice,

btw iwn 2200 also works, uses fw from 2000.

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[sl]

> btw iwn 2200 also works, uses fw from 2000.

thanks!

sl

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[sl]

> i'm 99% sure it's coincidence, the pcie version or connector shape
> shouldn't matter.

i can now verify this empirically:

Update 2023.07.07: I told an inadvertent lie above, claiming that no
M.2 cards are fast in 9front.  In fact, the Intel 6235 is an M.2 NGFF
card, and it works great.  Years ago I had recorded this fact[0] after
installing one in my ThinkPad T431s, and then we even bragged about
it[1] in the body of a 9front release announcement.  At some point I
forgot it existed.  One day, after writing the original version of
this post, I was perusing old sysinfo entries and re-noticed the
designation.  I acquired another example, installed it in my ThinkPad
X1 Yoga 3rd Gen, and it performs similar to the mPCIE cards examined
above.  That is to say, exhibiting much faster throughput than any
opther M.2 card I've tried.

So far, I've failed to find any other Intel M.2 cards prior to the
7260.

sl

[0] http://plan9.stanleylieber.com/hardware/thinkpad/t431s/20aa-000bus/sysinfo
[1] http://9front.org/releases/2017/02/21/0/

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[kemal]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

> > i'm 99% sure it's coincidence, the pcie version or connector shape
> > shouldn't matter.
it both does and doesn't
intel changed the firmware significantly in the 7000 series, which
coincides with intel's mpcie->m2 switch in wifi cards
there are both 6000 series m2 cards as you mentioned and 7000 series
mpcie cards (7260-7265 have mpcie versions to my knowledge)
so this problem is about 7000+ series of cards
(3000 series are 1x1 versions of 7000)

because of this a different code path exists for initialization,
there's probably
some bug in it. i checked the latest patch i prepared a long time ago
for 7260 support and i realized there was a change i made that i forgot
about (maybe i didn't send that patch at all, i don't remember...)
the calibration commands in the main firmware initialization doesn't include
type+length in the command itself and simply sends the calibration block
it may have caused the firmware to ignore calibration commands, which
would result in botched calibration+slow speeds.
(although if this was the case i'd expect the firmware returning a error
to the driver, so i'm not sure on this)
i prepared a patch to include this change

i also cleaned up fw capability checking and added pci ids for 3165-3168
as those should work out of the box with the current code

i can't test this patch, so i will attach it for those who want to test

it can get pushed if it works

[-- Attachment #2: etheriwl.diff --]
[-- Type: application/octet-stream, Size: 4453 bytes --]

diff f6ac182f86bf0bcc777a76db50f94227ef6f7962 uncommitted
--- a/sys/src/9/port/etheriwl.c
+++ b/sys/src/9/port/etheriwl.c
@@ -330,25 +330,14 @@
 };
 
 /*
- * uCode TLV api
- */
-enum {
-	/* api[0] */
-	UcodeApiSta	= 1<<30,
-};
-
-/*
  * uCode capabilities
  */
 enum {
-	/* capa[0] */
-	UcodeCapLar	= 1<<1,
+	UcodeApiSta	= 30,
 
-	/* capa[1] */
-	UcodeCapQuota	= 1<<12,
-	
-	/* capa[2] */
-	UcodeCapLar2	= 1<<9,
+	UcodeCapaLar	= 1,
+	UcodeCapaQuota	= 44,
+	UcodeCapaLar2	= 73,
 };
 
 enum {
@@ -658,8 +647,6 @@
 	Type6005	= 11,	/* also Centrino Advanced-N 6030, 6235 */
 	Type2030	= 12,
 	Type2000	= 16,
-
-	Type7260	= 20,
 };
 
 static struct ratetab {
@@ -721,6 +708,8 @@
 
 #define csr32r(c, r)	(*((c)->nic+((r)/4)))
 #define csr32w(c, r, v)	(*((c)->nic+((r)/4)) = (v))
+/* macro to help with ctlr->fw->(api|capa) */
+#define isset(a, i)	((a)[(i)/32] & 1U<<(i)%32)
 
 static uint
 get16(uchar *p){
@@ -1114,7 +1103,8 @@
 	}
 
 	/* Enable the oscillator to count wake up time for L1 exit. (weird W/A) */
-	if(ctlr->type == Type7260){
+	switch(ctlr->pdev->did){
+	case 0x08b1: case 0x08b2: case 0x08b3: case 0x08b4: /* Wireless 7260/3160 */
 		if((err = niclock(ctlr)) != nil)
 			return err;
 
@@ -2014,7 +2004,7 @@
 	*p++ = mcc[0];
 	*p++ = 0;
 	*p++ = 0;	// reserved
-	if(ctlr->fw->capa[2] & UcodeCapLar2){
+	if(isset(ctlr->fw->capa, UcodeCapaLar2)){
 		p += 4;
 		p += 5*4;
 	}
@@ -2407,7 +2397,7 @@
 		p += 2;			/* sleep_tx_count */
 		p++;			/* sleep state flags */
 
-		*p++ = ctlr->fw->api[0] & UcodeApiSta ? type : 0;		/* station_type */
+		*p++ = isset(ctlr->fw->api, UcodeApiSta) ? type : 0;		/* station_type */
 
 		p += 2;			/* assoc id */
 
@@ -2416,7 +2406,7 @@
 		put32(p, 1<<0);
 		p += 4;			/* tfd_queue_mask */
 
-		if(ctlr->fw->api[0] & UcodeApiSta){
+		if(isset(ctlr->fw->api, UcodeApiSta)){
 			p += 2;		/* rx_ba_window */
 			p++;		/* sp_length */
 			p++;		/* uapsd_acs */
@@ -2750,7 +2740,7 @@
 	uchar c[4*(3*4)], *p;
 	int i;
 
-	if((ctlr->fw->capa[1] & UcodeCapQuota) == 0)
+	if(!isset(ctlr->fw->capa, UcodeCapaQuota))
 		return nil;
 
 	i = 0;
@@ -2883,6 +2873,38 @@
 }
 
 static char*
+sendcalibdata(Ctlr *ctlr)
+{
+	Block *b;
+	uchar c[4];
+	char *err;
+	int i;
+
+	for(i = 0; i < sizeof(ctlr->calib.cmd); i++){
+		if((b = ctlr->calib.cmd[i]) == nil)
+			continue;
+		if(b == ctlr->calib.cfg)
+			put16(c, 1);
+		else if(b == ctlr->calib.nch)
+			put16(c, 2);
+		else if(ctlr->calib.cmd+i < ctlr->calib.papd+nelem(ctlr->calib.papd))
+			put16(c, 4);
+		else if(ctlr->calib.cmd+i < ctlr->calib.txp+nelem(ctlr->calib.txp))
+			put16(c, 5);
+		put16(c+2, BLEN(b));
+		
+		b = copyblock(b, BLEN(b));
+		if((err = qcmd(ctlr, 4, 108, c, sizeof(c), b)) != nil){
+			freeb(b);
+			return err;
+		}
+		if((err = flushq(ctlr, 4)) != nil)
+			return err;
+	}
+	return nil;
+}
+
+static char*
 postboot7000(Ctlr *ctlr)
 {
 	char *err;
@@ -2914,21 +2936,9 @@
 			ctlr->calib.done = 1;
 		}
 	} else {
-		Block *b;
-		int i;
+		if((err = sendcalibdata(ctlr)) != nil)
+			return err;
 
-		for(i = 0; i < nelem(ctlr->calib.cmd); i++){
-			if((b = ctlr->calib.cmd[i]) == nil)
-				continue;
-			b = copyblock(b, BLEN(b));
-			if((qcmd(ctlr, 4, 108, nil, 0, b)) != nil){
-				freeb(b);
-				return err;
-			}
-			if((err = flushq(ctlr, 4)) != nil)
-				return err;
-		}
-
 		if((err = sendphyconfig(ctlr,
 			ctlr->fw->physku,
 			ctlr->fw->main.defcalib.flowmask,
@@ -2947,7 +2957,7 @@
 			print("can't update device power: %s\n", err);
 			return err;
 		}
-		if(ctlr->fw->capa[0] & UcodeCapLar)
+		if(!isset(ctlr->fw->capa, UcodeCapaLar))
 			if((err = sendmccupdate(ctlr, "ZZ")) != nil)
 				return err;
 		if((err = disablebeaconfilter(ctlr)) != nil){
@@ -4421,7 +4431,7 @@
 	int family;
 	
 	pdev = nil;
-	while(pdev = pcimatch(pdev, Vintel, 0)) {
+	while(pdev = pcimatch(pdev, 0x8086, 0)) {
 		Ctlr *ctlr;
 		void *mem;
 		
@@ -4467,6 +4477,7 @@
 			fwname = "iwm-7260-17";
 			break;
 		case 0x08b3:	/* Wireless AC 3160 */
+		case 0x08b4:	/* Wireless AC 3160 */
 			family = 7000;
 			fwname = "iwm-3160-17";
 			break;
@@ -4474,6 +4485,15 @@
 		case 0x095b:	/* Wireless AC 7265 */
 			family = 7000;
 			fwname = "iwm-7265-17";
+			break;
+		case 0x3165:	/* Wireless AC 3165 */
+		case 0x3166:	/* Wireless AC 3165 */
+			family = 7000;
+			fwname = "iwm-7265D-29";
+			break;
+		case 0x24fb:	/* Wireless AC 3168 */
+			family = 7000;
+			fwname = "iwm-3168-29";
 			break;
 		case 0x24f3:	/* Wireless AC 8260 */
 			family = 8000;

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[kemal]

2023-07-22 22:53 GMT+03:00, kemal <kemalinanc8@gmail.com>:
>> > i'm 99% sure it's coincidence, the pcie version or connector shape
>> > shouldn't matter.
> it both does and doesn't
> intel changed the firmware significantly in the 7000 series, which
> coincides with intel's mpcie->m2 switch in wifi cards
> there are both 6000 series m2 cards as you mentioned and 7000 series
> mpcie cards (7260-7265 have mpcie versions to my knowledge)
> so this problem is about 7000+ series of cards
> (3000 series are 1x1 versions of 7000)
>
> because of this a different code path exists for initialization,
> there's probably
> some bug in it. i checked the latest patch i prepared a long time ago
> for 7260 support and i realized there was a change i made that i forgot
> about (maybe i didn't send that patch at all, i don't remember...)
> the calibration commands in the main firmware initialization doesn't
> include
> type+length in the command itself and simply sends the calibration block
> it may have caused the firmware to ignore calibration commands, which
> would result in botched calibration+slow speeds.
> (although if this was the case i'd expect the firmware returning a error
> to the driver, so i'm not sure on this)
> i prepared a patch to include this change
>
> i also cleaned up fw capability checking and added pci ids for 3165-3168
> as those should work out of the box with the current code
>
> i can't test this patch, so i will attach it for those who want to test
>
> it can get pushed if it works
>

my mail didn't end up in /n/lists/9front, so the mail server may have
ate my mail. i'm going to reply to my original message and upload
my patch to okturing instead of attaching it, hoping that it will get
sent
http://okturing.com/src/16441/body

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[kemal]

2023-07-23 0:30 GMT+03:00, kemal <kemalinanc8@gmail.com>:
> 2023-07-22 22:53 GMT+03:00, kemal <kemalinanc8@gmail.com>:
>>> > i'm 99% sure it's coincidence, the pcie version or connector shape
>>> > shouldn't matter.
>> it both does and doesn't
>> intel changed the firmware significantly in the 7000 series, which
>> coincides with intel's mpcie->m2 switch in wifi cards
>> there are both 6000 series m2 cards as you mentioned and 7000 series
>> mpcie cards (7260-7265 have mpcie versions to my knowledge)
>> so this problem is about 7000+ series of cards
>> (3000 series are 1x1 versions of 7000)
>>
>> because of this a different code path exists for initialization,
>> there's probably
>> some bug in it. i checked the latest patch i prepared a long time ago
>> for 7260 support and i realized there was a change i made that i forgot
>> about (maybe i didn't send that patch at all, i don't remember...)
>> the calibration commands in the main firmware initialization doesn't
>> include
>> type+length in the command itself and simply sends the calibration block
>> it may have caused the firmware to ignore calibration commands, which
>> would result in botched calibration+slow speeds.
>> (although if this was the case i'd expect the firmware returning a error
>> to the driver, so i'm not sure on this)
>> i prepared a patch to include this change
>>
>> i also cleaned up fw capability checking and added pci ids for 3165-3168
>> as those should work out of the box with the current code
>>
>> i can't test this patch, so i will attach it for those who want to test
>>
>> it can get pushed if it works
>>
>
> my mail didn't end up in /n/lists/9front, so the mail server may have
> ate my mail. i'm going to reply to my original message and upload
> my patch to okturing instead of attaching it, hoping that it will get
> sent
> http://okturing.com/src/16441/body
>

i don't see it again, sorry for bothering if the previous 2 mails
actually turn out to be sent, i'm going to try again

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[qwx]

On Sun Jul 23 00:17:14 +0200 2023, kemalinanc8@gmail.com wrote:
> 2023-07-23 0:30 GMT+03:00, kemal <kemalinanc8@gmail.com>:
> > 2023-07-22 22:53 GMT+03:00, kemal <kemalinanc8@gmail.com>:
> >>> > i'm 99% sure it's coincidence, the pcie version or connector shape
> >>> > shouldn't matter.
> >> it both does and doesn't
> >> intel changed the firmware significantly in the 7000 series, which
> >> coincides with intel's mpcie->m2 switch in wifi cards
> >> there are both 6000 series m2 cards as you mentioned and 7000 series
> >> mpcie cards (7260-7265 have mpcie versions to my knowledge)
> >> so this problem is about 7000+ series of cards
> >> (3000 series are 1x1 versions of 7000)
> >>
> >> because of this a different code path exists for initialization,
> >> there's probably
> >> some bug in it. i checked the latest patch i prepared a long time ago
> >> for 7260 support and i realized there was a change i made that i forgot
> >> about (maybe i didn't send that patch at all, i don't remember...)
> >> the calibration commands in the main firmware initialization doesn't
> >> include
> >> type+length in the command itself and simply sends the calibration block
> >> it may have caused the firmware to ignore calibration commands, which
> >> would result in botched calibration+slow speeds.
> >> (although if this was the case i'd expect the firmware returning a error
> >> to the driver, so i'm not sure on this)
> >> i prepared a patch to include this change
> >>
> >> i also cleaned up fw capability checking and added pci ids for 3165-3168
> >> as those should work out of the box with the current code
> >>
> >> i can't test this patch, so i will attach it for those who want to test
> >>
> >> it can get pushed if it works
> >>
> >
> > my mail didn't end up in /n/lists/9front, so the mail server may have
> > ate my mail. i'm going to reply to my original message and upload
> > my patch to okturing instead of attaching it, hoping that it will get
> > sent
> > http://okturing.com/src/16441/body
> >
> 
> i don't see it again, sorry for bothering if the previous 2 mails
> actually turn out to be sent, i'm going to try again

I got the first and third email; usually it takes a bit of time for
them to show up in /n/lists.  I also received my last email twice.

Anyway, thanks!  I can test your patch on my x240 and x250.

Cheers,
qwx

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[Stanley Lieber]

On July 22, 2023 5:49:45 PM EDT, kemal <kemalinanc8@gmail.com> wrote:
>2023-07-23 0:30 GMT+03:00, kemal <kemalinanc8@gmail.com>:
>> 2023-07-22 22:53 GMT+03:00, kemal <kemalinanc8@gmail.com>:
>>>> > i'm 99% sure it's coincidence, the pcie version or connector shape
>>>> > shouldn't matter.
>>> it both does and doesn't
>>> intel changed the firmware significantly in the 7000 series, which
>>> coincides with intel's mpcie->m2 switch in wifi cards
>>> there are both 6000 series m2 cards as you mentioned and 7000 series
>>> mpcie cards (7260-7265 have mpcie versions to my knowledge)
>>> so this problem is about 7000+ series of cards
>>> (3000 series are 1x1 versions of 7000)
>>>
>>> because of this a different code path exists for initialization,
>>> there's probably
>>> some bug in it. i checked the latest patch i prepared a long time ago
>>> for 7260 support and i realized there was a change i made that i forgot
>>> about (maybe i didn't send that patch at all, i don't remember...)
>>> the calibration commands in the main firmware initialization doesn't
>>> include
>>> type+length in the command itself and simply sends the calibration block
>>> it may have caused the firmware to ignore calibration commands, which
>>> would result in botched calibration+slow speeds.
>>> (although if this was the case i'd expect the firmware returning a error
>>> to the driver, so i'm not sure on this)
>>> i prepared a patch to include this change
>>>
>>> i also cleaned up fw capability checking and added pci ids for 3165-3168
>>> as those should work out of the box with the current code
>>>
>>> i can't test this patch, so i will attach it for those who want to test
>>>
>>> it can get pushed if it works
>>>
>>
>> my mail didn't end up in /n/lists/9front, so the mail server may have
>> ate my mail. i'm going to reply to my original message and upload
>> my patch to okturing instead of attaching it, hoping that it will get
>> sent
>> http://okturing.com/src/16441/body
>>
>
>i don't see it again, sorry for bothering if the previous 2 mails
>actually turn out to be sent, i'm going to try again
>

i received both mails.

sl

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[kemal]

2023-07-23 1:57 GMT+03:00, Stanley Lieber <sl@stanleylieber.com>:
> i received both mails.
>
> sl
>
oh, sorry about that.

2023-07-23 1:22 GMT+03:00, qwx@sciops.net <qwx@sciops.net>:
> I got the first and third email; usually it takes a bit of time for
> them to show up in /n/lists.  I also received my last email twice.
>
> Anyway, thanks!  I can test your patch on my x240 and x250.
>
> Cheers,
> qwx
>
i'm used to the mailing lists delay, but i didn't know that /n/lists didn't
show the mails right away...

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[ori]

Quoth kemal <kemalinanc8@gmail.com>:
>
> my mail didn't end up in /n/lists/9front, so the mail server may have
> ate my mail. i'm going to reply to my original message and upload
> my patch to okturing instead of attaching it, hoping that it will get
> sent
> http://okturing.com/src/16441/body

this breaks wireless on my t460s (Intel Wireless 8260, 8086:24f3).

Before, it would often give me firmware crashes, but with this it
does it on every bind:

	 #l1: fatal firmware error
	 lastcmd: 108 (0x6c)
	 error:  id 2b12, trm_hw_status 000002f0 00000000,
	         branchlink2 0002395c, interruptlink 0003867a 00000000,
	         errordata 80087cca 7acdf1f6 00000000
	 #l1: flushq: broken

happy to help debug, but not sure where to start.

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[kemal]

[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]

2023-07-24 5:35 GMT+03:00, ori@eigenstate.org <ori@eigenstate.org>:
> Quoth kemal <kemalinanc8@gmail.com>:
>>
>> my mail didn't end up in /n/lists/9front, so the mail server may have
>> ate my mail. i'm going to reply to my original message and upload
>> my patch to okturing instead of attaching it, hoping that it will get
>> sent
>> http://okturing.com/src/16441/body
>
> this breaks wireless on my t460s (Intel Wireless 8260, 8086:24f3).
>
> Before, it would often give me firmware crashes, but with this it
> does it on every bind:
>
> 	 #l1: fatal firmware error
> 	 lastcmd: 108 (0x6c)
> 	 error:  id 2b12, trm_hw_status 000002f0 00000000,
> 	         branchlink2 0002395c, interruptlink 0003867a 00000000,
> 	         errordata 80087cca 7acdf1f6 00000000
> 	 #l1: flushq: broken
>
> happy to help debug, but not sure where to start.
>
>

first of all, thank you for testing!

as for what happens here, it errors on the command i changed. firmware
makes the situation worse by sending us an unknown error id (0x2b12),
but i at least know that it's not because we're sending a bad command but
because firmware breaks for a cryptic reason. just for reference,
i'll leave the error id table from openbsd here:

static struct {
	const char *name;
	uint8_t num;
} advanced_lookup[] = {
	{ "NMI_INTERRUPT_WDG", 0x34 },
	{ "SYSASSERT", 0x35 },
	{ "UCODE_VERSION_MISMATCH", 0x37 },
	{ "BAD_COMMAND", 0x38 },
	{ "BAD_COMMAND", 0x39 },
	{ "NMI_INTERRUPT_DATA_ACTION_PT", 0x3C },
	{ "FATAL_ERROR", 0x3D },
	{ "NMI_TRM_HW_ERR", 0x46 },
	{ "NMI_INTERRUPT_TRM", 0x4C },
	{ "NMI_INTERRUPT_BREAK_POINT", 0x54 },
	{ "NMI_INTERRUPT_WDG_RXF_FULL", 0x5C },
	{ "NMI_INTERRUPT_WDG_NO_RBD_RXF_FULL", 0x64 },
	{ "NMI_INTERRUPT_HOST", 0x66 },
	{ "NMI_INTERRUPT_LMAC_FATAL", 0x70 },
	{ "NMI_INTERRUPT_UMAC_FATAL", 0x71 },
	{ "NMI_INTERRUPT_OTHER_LMAC_FATAL", 0x73 },
	{ "NMI_INTERRUPT_ACTION_PT", 0x7C },
	{ "NMI_INTERRUPT_UNKNOWN", 0x84 },
	{ "NMI_INTERRUPT_INST_ACTION_PT", 0x86 },
	{ "ADVANCED_SYSASSERT", 0 },
};
(unknown errors are ADVANCED_SYSASSERT)

sadly, the rest of the error is useless as no one except intel knows the
firmwares internals. i want to know why it fails, so i added some debug
prints to deduce something.
diff with debug prints attached.

for reference, this is what openbsd does:

int
iwm_send_phy_db_cmd(struct iwm_softc *sc, uint16_t type, uint16_t length,
    void *data)
{
	struct iwm_phy_db_cmd phy_db_cmd;
	struct iwm_host_cmd cmd = {
		.id = IWM_PHY_DB_CMD,
		.flags = IWM_CMD_ASYNC,
	};

	phy_db_cmd.type = le16toh(type);
	phy_db_cmd.length = le16toh(length);

	cmd.data[0] = &phy_db_cmd;
	cmd.len[0] = sizeof(struct iwm_phy_db_cmd);
	cmd.data[1] = data;
	cmd.len[1] = length;

	return iwm_send_cmd(sc, &cmd);
}

and this is the structure:

struct iwm_phy_db_cmd {
	uint16_t type;
	uint16_t length;
	uint8_t data[];
} __packed;

(data is unused)

[-- Attachment #2: etheriwl.diff --]
[-- Type: text/plain, Size: 4579 bytes --]

diff f6ac182f86bf0bcc777a76db50f94227ef6f7962 uncommitted
--- a/sys/src/9/port/etheriwl.c
+++ b/sys/src/9/port/etheriwl.c
@@ -330,25 +330,14 @@
 };
 
 /*
- * uCode TLV api
- */
-enum {
-	/* api[0] */
-	UcodeApiSta	= 1<<30,
-};
-
-/*
  * uCode capabilities
  */
 enum {
-	/* capa[0] */
-	UcodeCapLar	= 1<<1,
+	UcodeApiSta	= 30,
 
-	/* capa[1] */
-	UcodeCapQuota	= 1<<12,
-	
-	/* capa[2] */
-	UcodeCapLar2	= 1<<9,
+	UcodeCapaLar	= 1,
+	UcodeCapaQuota	= 44,
+	UcodeCapaLar2	= 73,
 };
 
 enum {
@@ -658,8 +647,6 @@
 	Type6005	= 11,	/* also Centrino Advanced-N 6030, 6235 */
 	Type2030	= 12,
 	Type2000	= 16,
-
-	Type7260	= 20,
 };
 
 static struct ratetab {
@@ -721,6 +708,8 @@
 
 #define csr32r(c, r)	(*((c)->nic+((r)/4)))
 #define csr32w(c, r, v)	(*((c)->nic+((r)/4)) = (v))
+/* macro to help with ctlr->fw->(api|capa) */
+#define isset(a, i)	((a)[(i)/32] & 1U<<(i)%32)
 
 static uint
 get16(uchar *p){
@@ -1114,7 +1103,8 @@
 	}
 
 	/* Enable the oscillator to count wake up time for L1 exit. (weird W/A) */
-	if(ctlr->type == Type7260){
+	switch(ctlr->pdev->did){
+	case 0x08b1: case 0x08b2: case 0x08b3: case 0x08b4: /* Wireless 7260/3160 */
 		if((err = niclock(ctlr)) != nil)
 			return err;
 
@@ -2014,7 +2004,7 @@
 	*p++ = mcc[0];
 	*p++ = 0;
 	*p++ = 0;	// reserved
-	if(ctlr->fw->capa[2] & UcodeCapLar2){
+	if(isset(ctlr->fw->capa, UcodeCapaLar2)){
 		p += 4;
 		p += 5*4;
 	}
@@ -2407,7 +2397,7 @@
 		p += 2;			/* sleep_tx_count */
 		p++;			/* sleep state flags */
 
-		*p++ = ctlr->fw->api[0] & UcodeApiSta ? type : 0;		/* station_type */
+		*p++ = isset(ctlr->fw->api, UcodeApiSta) ? type : 0;		/* station_type */
 
 		p += 2;			/* assoc id */
 
@@ -2416,7 +2406,7 @@
 		put32(p, 1<<0);
 		p += 4;			/* tfd_queue_mask */
 
-		if(ctlr->fw->api[0] & UcodeApiSta){
+		if(isset(ctlr->fw->api, UcodeApiSta)){
 			p += 2;		/* rx_ba_window */
 			p++;		/* sp_length */
 			p++;		/* uapsd_acs */
@@ -2750,7 +2740,7 @@
 	uchar c[4*(3*4)], *p;
 	int i;
 
-	if((ctlr->fw->capa[1] & UcodeCapQuota) == 0)
+	if(!isset(ctlr->fw->capa, UcodeCapaQuota))
 		return nil;
 
 	i = 0;
@@ -2883,6 +2873,41 @@
 }
 
 static char*
+sendcalibdata(Ctlr *ctlr)
+{
+	Block *b;
+	uchar c[4];
+	char *err;
+	int i;
+
+	for(i = 0; i < sizeof(ctlr->calib.cmd); i++){
+		if((b = ctlr->calib.cmd[i]) == nil){
+			print("iwl: calib %d empty", i);
+			continue;
+		}
+		if(b == ctlr->calib.cfg)
+			put16(c, 1);
+		else if(b == ctlr->calib.nch)
+			put16(c, 2);
+		else if(ctlr->calib.cmd+i < ctlr->calib.papd+nelem(ctlr->calib.papd))
+			put16(c, 4);
+		else if(ctlr->calib.cmd+i < ctlr->calib.txp+nelem(ctlr->calib.txp))
+			put16(c, 5);
+		put16(c+2, BLEN(b));
+		print("iwl: calib %d to be sent: type %uhd len %uhd", i, get16(c), get16(c+2));
+		
+		b = copyblock(b, BLEN(b));
+		if((err = qcmd(ctlr, 4, 108, c, sizeof(c), b)) != nil){
+			freeb(b);
+			return err;
+		}
+		if((err = flushq(ctlr, 4)) != nil)
+			return err;
+	}
+	return nil;
+}
+
+static char*
 postboot7000(Ctlr *ctlr)
 {
 	char *err;
@@ -2914,21 +2939,9 @@
 			ctlr->calib.done = 1;
 		}
 	} else {
-		Block *b;
-		int i;
+		if((err = sendcalibdata(ctlr)) != nil)
+			return err;
 
-		for(i = 0; i < nelem(ctlr->calib.cmd); i++){
-			if((b = ctlr->calib.cmd[i]) == nil)
-				continue;
-			b = copyblock(b, BLEN(b));
-			if((qcmd(ctlr, 4, 108, nil, 0, b)) != nil){
-				freeb(b);
-				return err;
-			}
-			if((err = flushq(ctlr, 4)) != nil)
-				return err;
-		}
-
 		if((err = sendphyconfig(ctlr,
 			ctlr->fw->physku,
 			ctlr->fw->main.defcalib.flowmask,
@@ -2947,7 +2960,7 @@
 			print("can't update device power: %s\n", err);
 			return err;
 		}
-		if(ctlr->fw->capa[0] & UcodeCapLar)
+		if(!isset(ctlr->fw->capa, UcodeCapaLar))
 			if((err = sendmccupdate(ctlr, "ZZ")) != nil)
 				return err;
 		if((err = disablebeaconfilter(ctlr)) != nil){
@@ -4421,7 +4434,7 @@
 	int family;
 	
 	pdev = nil;
-	while(pdev = pcimatch(pdev, Vintel, 0)) {
+	while(pdev = pcimatch(pdev, 0x8086, 0)) {
 		Ctlr *ctlr;
 		void *mem;
 		
@@ -4467,6 +4480,7 @@
 			fwname = "iwm-7260-17";
 			break;
 		case 0x08b3:	/* Wireless AC 3160 */
+		case 0x08b4:	/* Wireless AC 3160 */
 			family = 7000;
 			fwname = "iwm-3160-17";
 			break;
@@ -4474,6 +4488,15 @@
 		case 0x095b:	/* Wireless AC 7265 */
 			family = 7000;
 			fwname = "iwm-7265-17";
+			break;
+		case 0x3165:	/* Wireless AC 3165 */
+		case 0x3166:	/* Wireless AC 3165 */
+			family = 7000;
+			fwname = "iwm-7265D-29";
+			break;
+		case 0x24fb:	/* Wireless AC 3168 */
+			family = 7000;
+			fwname = "iwm-3168-29";
 			break;
 		case 0x24f3:	/* Wireless AC 8260 */
 			family = 8000;

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[kemal]

[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]

2023-07-24 12:58 GMT+03:00, kemal <kemalinanc8@gmail.com>:
> 2023-07-24 5:35 GMT+03:00, ori@eigenstate.org <ori@eigenstate.org>:
>> Quoth kemal <kemalinanc8@gmail.com>:
>>>
>>> my mail didn't end up in /n/lists/9front, so the mail server may have
>>> ate my mail. i'm going to reply to my original message and upload
>>> my patch to okturing instead of attaching it, hoping that it will get
>>> sent
>>> http://okturing.com/src/16441/body
>>
>> this breaks wireless on my t460s (Intel Wireless 8260, 8086:24f3).
>>
>> Before, it would often give me firmware crashes, but with this it
>> does it on every bind:
>>
>> 	 #l1: fatal firmware error
>> 	 lastcmd: 108 (0x6c)
>> 	 error:  id 2b12, trm_hw_status 000002f0 00000000,
>> 	         branchlink2 0002395c, interruptlink 0003867a 00000000,
>> 	         errordata 80087cca 7acdf1f6 00000000
>> 	 #l1: flushq: broken
>>
>> happy to help debug, but not sure where to start.
>>
>>
>
> first of all, thank you for testing!
>
> as for what happens here, it errors on the command i changed. firmware
> makes the situation worse by sending us an unknown error id (0x2b12),
> but i at least know that it's not because we're sending a bad command but
> because firmware breaks for a cryptic reason. just for reference,
> i'll leave the error id table from openbsd here:
>
> static struct {
> 	const char *name;
> 	uint8_t num;
> } advanced_lookup[] = {
> 	{ "NMI_INTERRUPT_WDG", 0x34 },
> 	{ "SYSASSERT", 0x35 },
> 	{ "UCODE_VERSION_MISMATCH", 0x37 },
> 	{ "BAD_COMMAND", 0x38 },
> 	{ "BAD_COMMAND", 0x39 },
> 	{ "NMI_INTERRUPT_DATA_ACTION_PT", 0x3C },
> 	{ "FATAL_ERROR", 0x3D },
> 	{ "NMI_TRM_HW_ERR", 0x46 },
> 	{ "NMI_INTERRUPT_TRM", 0x4C },
> 	{ "NMI_INTERRUPT_BREAK_POINT", 0x54 },
> 	{ "NMI_INTERRUPT_WDG_RXF_FULL", 0x5C },
> 	{ "NMI_INTERRUPT_WDG_NO_RBD_RXF_FULL", 0x64 },
> 	{ "NMI_INTERRUPT_HOST", 0x66 },
> 	{ "NMI_INTERRUPT_LMAC_FATAL", 0x70 },
> 	{ "NMI_INTERRUPT_UMAC_FATAL", 0x71 },
> 	{ "NMI_INTERRUPT_OTHER_LMAC_FATAL", 0x73 },
> 	{ "NMI_INTERRUPT_ACTION_PT", 0x7C },
> 	{ "NMI_INTERRUPT_UNKNOWN", 0x84 },
> 	{ "NMI_INTERRUPT_INST_ACTION_PT", 0x86 },
> 	{ "ADVANCED_SYSASSERT", 0 },
> };
> (unknown errors are ADVANCED_SYSASSERT)
>
> sadly, the rest of the error is useless as no one except intel knows the
> firmwares internals. i want to know why it fails, so i added some debug
> prints to deduce something.
> diff with debug prints attached.
>
> for reference, this is what openbsd does:
>
> int
> iwm_send_phy_db_cmd(struct iwm_softc *sc, uint16_t type, uint16_t length,
>     void *data)
> {
> 	struct iwm_phy_db_cmd phy_db_cmd;
> 	struct iwm_host_cmd cmd = {
> 		.id = IWM_PHY_DB_CMD,
> 		.flags = IWM_CMD_ASYNC,
> 	};
>
> 	phy_db_cmd.type = le16toh(type);
> 	phy_db_cmd.length = le16toh(length);
>
> 	cmd.data[0] = &phy_db_cmd;
> 	cmd.len[0] = sizeof(struct iwm_phy_db_cmd);
> 	cmd.data[1] = data;
> 	cmd.len[1] = length;
>
> 	return iwm_send_cmd(sc, &cmd);
> }
>
> and this is the structure:
>
> struct iwm_phy_db_cmd {
> 	uint16_t type;
> 	uint16_t length;
> 	uint8_t data[];
> } __packed;
>
> (data is unused)
>

sorry. after staring at the code for a bit, i realised that
our code kept the type+length part of the calib block sent
by the firmware. for some reason, openbsd+linux seperates
that and sends it in the command buffer.

i aligned the behavior, but this shouldn't change anything, and
this is probably not related at all to the speed issue we're
experiencing

may you send a snippet of the firmware crashes you experience?

diff attached

[-- Attachment #2: etheriwl.diff --]
[-- Type: text/plain, Size: 4249 bytes --]

diff f6ac182f86bf0bcc777a76db50f94227ef6f7962 uncommitted
--- a/sys/src/9/port/etheriwl.c
+++ b/sys/src/9/port/etheriwl.c
@@ -330,25 +330,14 @@
 };
 
 /*
- * uCode TLV api
- */
-enum {
-	/* api[0] */
-	UcodeApiSta	= 1<<30,
-};
-
-/*
  * uCode capabilities
  */
 enum {
-	/* capa[0] */
-	UcodeCapLar	= 1<<1,
+	UcodeApiSta	= 30,
 
-	/* capa[1] */
-	UcodeCapQuota	= 1<<12,
-	
-	/* capa[2] */
-	UcodeCapLar2	= 1<<9,
+	UcodeCapaLar	= 1,
+	UcodeCapaQuota	= 44,
+	UcodeCapaLar2	= 73,
 };
 
 enum {
@@ -658,8 +647,6 @@
 	Type6005	= 11,	/* also Centrino Advanced-N 6030, 6235 */
 	Type2030	= 12,
 	Type2000	= 16,
-
-	Type7260	= 20,
 };
 
 static struct ratetab {
@@ -721,6 +708,8 @@
 
 #define csr32r(c, r)	(*((c)->nic+((r)/4)))
 #define csr32w(c, r, v)	(*((c)->nic+((r)/4)) = (v))
+/* macro to help with ctlr->fw->(api|capa) */
+#define isset(a, i)	((a)[(i)/32] & 1U<<(i)%32)
 
 static uint
 get16(uchar *p){
@@ -1114,7 +1103,8 @@
 	}
 
 	/* Enable the oscillator to count wake up time for L1 exit. (weird W/A) */
-	if(ctlr->type == Type7260){
+	switch(ctlr->pdev->did){
+	case 0x08b1: case 0x08b2: case 0x08b3: case 0x08b4: /* Wireless 7260/3160 */
 		if((err = niclock(ctlr)) != nil)
 			return err;
 
@@ -2014,7 +2004,7 @@
 	*p++ = mcc[0];
 	*p++ = 0;
 	*p++ = 0;	// reserved
-	if(ctlr->fw->capa[2] & UcodeCapLar2){
+	if(isset(ctlr->fw->capa, UcodeCapaLar2)){
 		p += 4;
 		p += 5*4;
 	}
@@ -2407,7 +2397,7 @@
 		p += 2;			/* sleep_tx_count */
 		p++;			/* sleep state flags */
 
-		*p++ = ctlr->fw->api[0] & UcodeApiSta ? type : 0;		/* station_type */
+		*p++ = isset(ctlr->fw->api, UcodeApiSta) ? type : 0;		/* station_type */
 
 		p += 2;			/* assoc id */
 
@@ -2416,7 +2406,7 @@
 		put32(p, 1<<0);
 		p += 4;			/* tfd_queue_mask */
 
-		if(ctlr->fw->api[0] & UcodeApiSta){
+		if(isset(ctlr->fw->api, UcodeApiSta)){
 			p += 2;		/* rx_ba_window */
 			p++;		/* sp_length */
 			p++;		/* uapsd_acs */
@@ -2750,7 +2740,7 @@
 	uchar c[4*(3*4)], *p;
 	int i;
 
-	if((ctlr->fw->capa[1] & UcodeCapQuota) == 0)
+	if(!isset(ctlr->fw->capa, UcodeCapaQuota))
 		return nil;
 
 	i = 0;
@@ -2883,6 +2873,31 @@
 }
 
 static char*
+sendcalibdata(Ctlr *ctlr)
+{
+	Block *b;
+	uchar c[4];
+	char *err;
+	int i;
+
+	for(i = 0; i < sizeof(ctlr->calib.cmd); i++){
+		if((b = ctlr->calib.cmd[i]) == nil)
+			continue;
+		/* send type+length in the command */
+		memmove(c, b->rp, sizeof(c));
+		b = copyblock(b, BLEN(b));
+		b->rp += sizeof(c);
+		if((err = qcmd(ctlr, 4, 108, c, sizeof(c), b)) != nil){
+			freeb(b);
+			return err;
+		}
+		if((err = flushq(ctlr, 4)) != nil)
+			return err;
+	}
+	return nil;
+}
+
+static char*
 postboot7000(Ctlr *ctlr)
 {
 	char *err;
@@ -2914,21 +2929,9 @@
 			ctlr->calib.done = 1;
 		}
 	} else {
-		Block *b;
-		int i;
+		if((err = sendcalibdata(ctlr)) != nil)
+			return err;
 
-		for(i = 0; i < nelem(ctlr->calib.cmd); i++){
-			if((b = ctlr->calib.cmd[i]) == nil)
-				continue;
-			b = copyblock(b, BLEN(b));
-			if((qcmd(ctlr, 4, 108, nil, 0, b)) != nil){
-				freeb(b);
-				return err;
-			}
-			if((err = flushq(ctlr, 4)) != nil)
-				return err;
-		}
-
 		if((err = sendphyconfig(ctlr,
 			ctlr->fw->physku,
 			ctlr->fw->main.defcalib.flowmask,
@@ -2947,7 +2950,7 @@
 			print("can't update device power: %s\n", err);
 			return err;
 		}
-		if(ctlr->fw->capa[0] & UcodeCapLar)
+		if(!isset(ctlr->fw->capa, UcodeCapaLar))
 			if((err = sendmccupdate(ctlr, "ZZ")) != nil)
 				return err;
 		if((err = disablebeaconfilter(ctlr)) != nil){
@@ -4421,7 +4424,7 @@
 	int family;
 	
 	pdev = nil;
-	while(pdev = pcimatch(pdev, Vintel, 0)) {
+	while(pdev = pcimatch(pdev, 0x8086, 0)) {
 		Ctlr *ctlr;
 		void *mem;
 		
@@ -4467,6 +4470,7 @@
 			fwname = "iwm-7260-17";
 			break;
 		case 0x08b3:	/* Wireless AC 3160 */
+		case 0x08b4:	/* Wireless AC 3160 */
 			family = 7000;
 			fwname = "iwm-3160-17";
 			break;
@@ -4474,6 +4478,15 @@
 		case 0x095b:	/* Wireless AC 7265 */
 			family = 7000;
 			fwname = "iwm-7265-17";
+			break;
+		case 0x3165:	/* Wireless AC 3165 */
+		case 0x3166:	/* Wireless AC 3165 */
+			family = 7000;
+			fwname = "iwm-7265D-29";
+			break;
+		case 0x24fb:	/* Wireless AC 3168 */
+			family = 7000;
+			fwname = "iwm-3168-29";
 			break;
 		case 0x24f3:	/* Wireless AC 8260 */
 			family = 8000;

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[Steve simon]

Not really helpful, but of all devices to have a problem with, intel is one of the better.
They are usually quite helpful with datasheets and support.

It might be worth trying to find someone there.

-Steve


> On 24 Jul 2023, at 12:55, kemal <kemalinanc8@gmail.com> wrote:
> 
> 2023-07-24 12:58 GMT+03:00, kemal <kemalinanc8@gmail.com>:
>> 2023-07-24 5:35 GMT+03:00, ori@eigenstate.org <ori@eigenstate.org>:
>>> Quoth kemal <kemalinanc8@gmail.com>:
>>>> 
>>>> my mail didn't end up in /n/lists/9front, so the mail server may have
>>>> ate my mail. i'm going to reply to my original message and upload
>>>> my patch to okturing instead of attaching it, hoping that it will get
>>>> sent
>>>> http://okturing.com/src/16441/body
>>> 
>>> this breaks wireless on my t460s (Intel Wireless 8260, 8086:24f3).
>>> 
>>> Before, it would often give me firmware crashes, but with this it
>>> does it on every bind:
>>> 
>>>  #l1: fatal firmware error
>>>  lastcmd: 108 (0x6c)
>>>  error:  id 2b12, trm_hw_status 000002f0 00000000,
>>>          branchlink2 0002395c, interruptlink 0003867a 00000000,
>>>          errordata 80087cca 7acdf1f6 00000000
>>>  #l1: flushq: broken
>>> 
>>> happy to help debug, but not sure where to start.
>>> 
>>> 
>> 
>> first of all, thank you for testing!
>> 
>> as for what happens here, it errors on the command i changed. firmware
>> makes the situation worse by sending us an unknown error id (0x2b12),
>> but i at least know that it's not because we're sending a bad command but
>> because firmware breaks for a cryptic reason. just for reference,
>> i'll leave the error id table from openbsd here:
>> 
>> static struct {
>> const char *name;
>> uint8_t num;
>> } advanced_lookup[] = {
>> { "NMI_INTERRUPT_WDG", 0x34 },
>> { "SYSASSERT", 0x35 },
>> { "UCODE_VERSION_MISMATCH", 0x37 },
>> { "BAD_COMMAND", 0x38 },
>> { "BAD_COMMAND", 0x39 },
>> { "NMI_INTERRUPT_DATA_ACTION_PT", 0x3C },
>> { "FATAL_ERROR", 0x3D },
>> { "NMI_TRM_HW_ERR", 0x46 },
>> { "NMI_INTERRUPT_TRM", 0x4C },
>> { "NMI_INTERRUPT_BREAK_POINT", 0x54 },
>> { "NMI_INTERRUPT_WDG_RXF_FULL", 0x5C },
>> { "NMI_INTERRUPT_WDG_NO_RBD_RXF_FULL", 0x64 },
>> { "NMI_INTERRUPT_HOST", 0x66 },
>> { "NMI_INTERRUPT_LMAC_FATAL", 0x70 },
>> { "NMI_INTERRUPT_UMAC_FATAL", 0x71 },
>> { "NMI_INTERRUPT_OTHER_LMAC_FATAL", 0x73 },
>> { "NMI_INTERRUPT_ACTION_PT", 0x7C },
>> { "NMI_INTERRUPT_UNKNOWN", 0x84 },
>> { "NMI_INTERRUPT_INST_ACTION_PT", 0x86 },
>> { "ADVANCED_SYSASSERT", 0 },
>> };
>> (unknown errors are ADVANCED_SYSASSERT)
>> 
>> sadly, the rest of the error is useless as no one except intel knows the
>> firmwares internals. i want to know why it fails, so i added some debug
>> prints to deduce something.
>> diff with debug prints attached.
>> 
>> for reference, this is what openbsd does:
>> 
>> int
>> iwm_send_phy_db_cmd(struct iwm_softc *sc, uint16_t type, uint16_t length,
>>    void *data)
>> {
>> struct iwm_phy_db_cmd phy_db_cmd;
>> struct iwm_host_cmd cmd = {
>> .id = IWM_PHY_DB_CMD,
>> .flags = IWM_CMD_ASYNC,
>> };
>> 
>> phy_db_cmd.type = le16toh(type);
>> phy_db_cmd.length = le16toh(length);
>> 
>> cmd.data[0] = &phy_db_cmd;
>> cmd.len[0] = sizeof(struct iwm_phy_db_cmd);
>> cmd.data[1] = data;
>> cmd.len[1] = length;
>> 
>> return iwm_send_cmd(sc, &cmd);
>> }
>> 
>> and this is the structure:
>> 
>> struct iwm_phy_db_cmd {
>> uint16_t type;
>> uint16_t length;
>> uint8_t data[];
>> } __packed;
>> 
>> (data is unused)
>> 
> 
> sorry. after staring at the code for a bit, i realised that
> our code kept the type+length part of the calib block sent
> by the firmware. for some reason, openbsd+linux seperates
> that and sends it in the command buffer.
> 
> i aligned the behavior, but this shouldn't change anything, and
> this is probably not related at all to the speed issue we're
> experiencing
> 
> may you send a snippet of the firmware crashes you experience?
> 
> diff attached
> <etheriwl.diff>

Re: [9front] Free Carrots #6: Tools For Fighting WiFi Inequality

[kemal]

2023-07-24 15:08 GMT+03:00, Steve simon <steve@quintile.net>:
> Not really helpful, but of all devices to have a problem with, intel is one
> of the better.
> They are usually quite helpful with datasheets and support.
>
> It might be worth trying to find someone there.
>
> -Steve
>

from what i see in openbsd's cvs commit log, it seems like they can
get help from intel when they get stuck

we may try contacting them if we identify the bug and can't fix it