Re: Kernel panic in ieee80211_chan2mode <- SIOCS80211 ioctl

On Wed, 9 Sep 2026, Bjoern A. Zeeb wrote:

> On Wed, 9 Sep 2026, Marcin Cieslak wrote:
>
>> On Tue, 8 Sep 2026, Bjoern A. Zeeb wrote:
>> 
>>> On Tue, 8 Sep 2026, Marcin Cieslak wrote:
>>> 
>>>> This is amd64 current as of 067ae9850f05a27239c28ae5819e4016e997cff2
>>>> 
>>>> brcmfmac0@pci0:2:0:0:	class=0x028000 rev=0x05 hdr=0x00 
>>>> vendor=0x14e4 device=0x43a3 subvendor=0x106b subdevice=0x0159
>>>> 
>>>> 
>>>> (running the vibe coded driver as of 
>>>> 9adbe774d3be91827d628fbd811daf63512acb6d)
>>> 
>>> Generally I'd not support this but ask to report it to the vibe coding 
>>> repo...
>>> 
>>> Here's some ideas though.
>>> 
>>>> #20 0xffffffff80e525f2 in ieee80211_setup_rates (ni=0x33443836,
>>>>    ni@entry=0xfffffe00fa139000, rates=<optimized out>,
>>> 
>>> Can you print ni details here on frame 20 and frame 19?
>>> 
>> 
>> #20 0xffffffff80e525f2 in ieee80211_setup_rates (ni=0x33443836, 
>> ni@entry=0xfffffe00fa139000, rates=<optimized out>, 
>> xrates=xrates@entry=0xfffffe00f8af19e7 "3", flags=-2048, flags@entry=1) at 
>> /usr/src/sys/net80211/ieee80211_input.c:450
>> 450		return ieee80211_fix_rate(ni, rs, flags);
>> Cannot access memory at address 0x33443836
>> 
>> #19 0xffffffff80e7014f in ieee80211_fix_rate (ni=0xfffffe00fa139000, 
>> nrs=0xfffffe00fa1392a5, flags=1) at 
>> /usr/src/sys/net80211/ieee80211_proto.c:650
>> 650		ucastrate = 
>> vap->iv_txparms[ieee80211_chan2mode(ni->ni_chan)].ucastrate;
> ...
>> rs_rates = "\000\020\000\000\025f1\006\000\000D401C"}, ni_chan = 
>> 0x33443836,
>
> ni_chan gets assigned based on the value passed in ieee80211_sta_join(),
> which was optimized out.
>
>>>> #22 0xffffffff80e576dc in setmlme_assoc_sta (vap=0xfffff80025bdd000,
>>>>     mac=0xfffffe00f8af1962 "\324\001_h\323lower-deck",
>>>>     ssid_len=<optimized out>, ssid=<optimized out>)
>>>>     at /usr/src/sys/net80211/ieee80211_ioctl.c:1693
>>>> ...
>>>>             se_intval = 100, se_capinfo = 1057, se_chan = 
>>>> 0xfffffe00f9409a40,
>>>> ...
>>> 
>>> Can you also print se_chan details here?
>
> That means the lookup which was found in setmlme_assoc_sta()
> passes &lookup.se in.
> So the likelyhood is that scan results were wrong; and brcmfmac
> needs to synthesize those.

Not sure I understand but I'll try to read the source

I wonder if it would work to single step the kernel (last time
I did it with firewire attachd).

> Where's the source of the AI written driver?

https://github.com/narqo/freebsd-brcmfmac

I am running 9adbe774d3be91827d628fbd811daf63512acb6d with my patch

https://github.com/saper/freebsd-brcmfmac/tree/no_debug_printf

Thank you...