iaxwifi200: fails to bind

[korli]

this is on acer swift 114-32 hrev56235

KERN: register_domain(4, link)
KERN: openbsd wlan_control: 9235, 78 (not supported)
KERN: register_domain(9, unix)
KERN: openbsd wlan_control: 9235, 16 (not supported)
KERN: iwx: SCAN -> INIT
KERN: Last message repeated 2 times.
KERN: openbsd wlan_control: 9235, 78 (not supported)
KERN: openbsd wlan_control: 9235, 16 (not supported)
KERN: iwx: SCAN -> INIT
KERN: Last message repeated 2 times.

[korli]

kdl screenshot

[korli]

syslog tail 25

[korli]

part of syslog indicates:

could not read firmware ...
failed to load init firmware

[korli]

the laptop is about this one (except the SSD maybe): ​https://linux-hardware.org/?probe=ca66ed7272

Device:	00:14.3
Class:	Network controller [0280]
Vendor:	Intel Corporation [8086]
Device:	Device [4df0]
SVendor:	Intel Corporation [8086]
SDevice:	Device [0074]
Rev:	01

[korli]

Ah, updating intel_wifi_firmwares, it loads better but fails to bind.

[korli]

Same with updated wpa_supplicant.

[korli]

syslog after updates

[waddlesplash]

The crash is the same as #17811 really, it's common to both OpenBSD drivers. Actually I have an idea of how to fix it and will work on that in the next few days.

As to what else might be going wrong for you, I'm not sure. You can edit ​this line to add IFF_DEBUG to the flags to get more information about what is happening. I do see the expected iwx: SCAN -> INIT but nothing else happens.

If IFF_DEBUG provides nothing of real interest, please test to see the driver works on OpenBSD.

[waddlesplash]

I suspect this is related to #17820 somehow.

I traced through the idualwifi driver and determined that we are getting packets dropped in odd places. Example: ping works for a few seconds, then stops working for a few seconds, then in iwm_receive_frame the first check fails and then ierrors is incremented; then ping works again for a few seconds more.

This seems like some kind of buffer handling problem, but I don't know where, probably above this. If you have any ideas or see problems with how the driver is using DMA and mbuf APIs that are incorrect vs. OpenBSD, that may help with diagnosing it (note there are sometimes subtly different semantics of OpenBSD mbuf functions)...

[waddlesplash]

I noticed an inconsistency that I corrected in hrev56238 but at least on my end I still see problems like this ticket and #17814 which seems somehow related. Still no idea what the problem might be.

[waddlesplash]

If you have another device (probably Linux or OpenBSD) which you can run in MONITOR mode to see what frames are actually being exchanged, I am told that can be helpful (i.e. see if the device is failing to send or failing to receive data.)

My guess is that the receive end is the problem, given #17814, which when I saw it happen just had no more data received, nor even ierrors incremented by the driver.

[waddlesplash]

I tested with 4GB memory limit and bounce buffers totally disabled; no change at all. I also tested (under iwm) with multiframe RX disabled, also no changed. I checked all the mbuf routines the driver uses and they all seem to have the same semantics between FreeBSD and OpenBSD as far as I can tell. So, I'm again at a loss for what to do to investigate this.

Perhaps RX needs to be fully traced from notif_intr all the way through?

[pulkomandy]

I'm getting a similar problem this weekend with my parent's wifi network, while mine at home was working fine a few days ago.

I can't tell yet if it's a regression in between, or some difference between the access points. I'll test again when I'm back home this evening.

[waddlesplash]

I booted into hrev56160 and checked out the very first commit of the driver and built them, and got the same behavior: massive packet loss and eventually things stop working altogether. So, I don't think it's a regression, then?

[waddlesplash]

Here's an example of the packet loss with some debugging added or turned on. The "fail, not command ack" messages come from a dprintf I added to the early return in iwm_cmd_done.

I found some slight oversights while auditing the code, but none of them appear to be at all related to this problem. There's still severe packet loss, which manifests itself either as a failure to connect like in this ticket, or eventually a total disconnect as in the other related tickets noted.

I'm still quite lost as to what the problem could be.

[waddlesplash]

Just now I connected and have apparently no packet loss and good latency, so it seems there is somehow a "luck" factor indeed.

[waddlesplash]

Well, all traffic stopped anyway after the 280th ping, so it seems that problem remains anyway.

[waddlesplash]

Please don't bother attaching any additional logs here unless I specifically request them. None of the actual diagnostic messages even appear in the syslog by default.

[waddlesplash]

Please retest after hrev56258; it may fix this.

[waddlesplash]

(For join failures, retry connecting a few times and see if it eventually succeeds.)

[waddlesplash]

mbrumbelow reports this is still occurring on his iaxwifi device following that change. Unfortunately I don't have any such devices myself to test with.

[korli]

I tested with hrev56262, no change.

[waddlesplash]

Please upgrade your wpa_supplicant package (to at least version "2.10.haiku.2") and retest.

[korli]

Looks good with hrev56391 and wpa_supplicant upgraded.