idualwifi almost useless

[donn]

Lenovo Thinkpad T480s, idualwifi7260/0 gets 50 kbs download.

This ca. 8000 times less than Linux on the very same computer, and 600 times less than the idualwifi7260/0 on my T450s.

The hw rev is different between the two idualwifis, but the big difference is that the T450s is running hrev57707, and the T480s is running hrev57909 (+dirty, probably my fault when I knocked that glass over!) Running from USB on the T450s, hrev57909 gets the same miserable performance - download 0.05 Mbps.

With a realtek USB wifi, the T480s gets comparable transfer speeds with idualwifi on hrev57707, 30 Mbps or so.

[waddlesplash]

Please attach a syslog.

[waddlesplash]

Hmm, I don't see anything relevant in the syslog.

I have some idualwifi hardware here, I'll see if I can reproduce.

[donn]

with idualwifi supposedly configured, but not functioning.

[donn]

idualwifi running, a few errors with WebPositive

[waddlesplash]

I can't reproduce this. I tested with the latest hrev57921 on a 7265D device, and get speeds generally in the Mbits/sec over LAN as well as to the package servers.

I did some fixes yesterday to system timer code that could possibly affect this depending on what other applications you have running on the system, can you please retest? If the problem persists, some information on what hrev it began closer to (as that's a relatively large range) would be helpful.

[vidrep]

I’m having the same issue after updating to hrev57921. My idualwifi 7260 indicates that it is connected, but there is apparently not a connection, as I cannot access websites.

[waddlesplash]

Vidrep, anything in syslog?

[vidrep]

I tried again, and it did not work. Then after waiting several minutes, it started working. I have attached the syslog.

[vidrep]

It takes more than four minutes to load the Haiku home page in Webpositive after the network indicates that it is "ready". After that, it appears to function normally.

[donn]

The last nightly that works reasonably well is hrev57881.

Note that, here, the problem is that large transfers are slow. It may or may not function normally, depending on what that means. Ping speed is not bad, actually a little better than NetBSD reports, and it can be used for light weight web usage, but data transfer is in the POTS modem range. Where before href57898, it ran about 1000 times faster.

[donn]

Built with IWM_DEBUG there's a little info about paging configuration.

[waddlesplash]

The problem is almost certainly a regression from the new TCP code, not one in iwm. If you are adept with packet captures, can you take a look and see what you notice in one?

[donn]

with IWM_DEBUG

[waddlesplash]

Well, I suppose the problem may also be hrev57885, if you tested with a version that included that but none of the newer TCP changes.

None of the paging information has much that's interesting.

[waddlesplash]

I just noticed a potential oversight in that commit. If you would please test with this patch and see if it fixes the problem:

diff --git a/src/libs/compat/freebsd_network/bus_dma.cpp b/src/libs/compat/freebsd_network/bus_dma.cpp
index de9454bd6a..49872c1a25 100644
--- a/src/libs/compat/freebsd_network/bus_dma.cpp
+++ b/src/libs/compat/freebsd_network/bus_dma.cpp
@@ -210,8 +210,17 @@ bus_dmamap_destroy(bus_dma_tag_t dmat, bus_dmamap_t map)
 
 
 static int
-_allocate_dmamem(bus_dma_tag_t dmat, phys_size_t size, void** vaddr, int mflags)
+_allocate_dmamem(bus_dma_tag_t dmat, phys_size_t size, void** vaddr, int flags)
 {
+	int mflags;
+	if (flags & BUS_DMA_NOWAIT)
+		mflags = M_NOWAIT;
+	else
+		mflags = M_WAITOK;
+
+	if (flags & BUS_DMA_ZERO)
+		mflags |= M_ZERO;
+
 	// FreeBSD uses standard malloc() for the case where size <= PAGE_SIZE,
 	// but we want to keep DMA'd memory a bit more separate, so we always use
 	// contigmalloc.
@@ -255,15 +264,6 @@ extern "C" int
 bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddr, int flags,
 	bus_dmamap_t* mapp)
 {
-	int mflags;
-	if (flags & BUS_DMA_NOWAIT)
-		mflags = M_NOWAIT;
-	else
-		mflags = M_WAITOK;
-
-	if (flags & BUS_DMA_ZERO)
-		mflags |= M_ZERO;
-
 	// FreeBSD does not permit the "mapp" argument to be NULL, but we do
 	// (primarily for the OpenBSD shims.)
 	if (mapp != NULL) {
@@ -273,7 +273,7 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddr, int flags,
 		(*mapp)->buffer_type = bus_dmamap::BUFFER_PROHIBITED;
 	}
 
-	int status = _allocate_dmamem(dmat, dmat->maxsize, vaddr, mflags);
+	int status = _allocate_dmamem(dmat, dmat->maxsize, vaddr, flags);
 	if (status != 0 && mapp != NULL)
 		bus_dmamap_destroy(dmat, *mapp);
 	return status;

[donn]

700 packets, tcpdump default options

[donn]

I don't see any difference, built with that patch.

[waddlesplash]

Can you try reverting the above patch as well as b390890110acea661707aeb5cd607af366e5d977 and see if it makes any difference?

[waddlesplash]

01:02:58.555441 IP truncated-ip - 1410 bytes missing!

There's a lot of that in the log; that looks like the problem. My guess is that b390890110acea661707aeb5cd607af366e5d977 really did break something, but I don't know what that could be here.

[waddlesplash]

There was another oversight in the mapping logic besides the one fixed in the patch above; fixed in hrev57932.

[donn]

I pulled that - hrev57936 - and I'm sorry to say the problem is still with me. Including the truncated-ip. Specifically, largish transfers take 3 tries. The first two get only 38 bytes of the request, whatever the request size - 530 to 1448. The third time is a charm, but that's 1/2 second after the failures, for a rate of under 30kbs.

There's a lot of that, but some large transfers happen on the first try, and in that case I don't see any delay. I don't notice any cases of only 1 truncation error - either 0, or 2.

[waddlesplash]

There was a silly typo in the new receive code. Please retest after hrev57938, it should now be fixed.

[donn]

Got it! This is fixed. Not only works, but works quite a bit better than before, or on NetBSD - transfer speeds are kind of variable from one run to another at the moment, but I had one near 200 Mbps and none less than 70 Mbps, download. Thanks!

[waddlesplash]

Thanks for testing!