Intel AX201 driver errors due to broken driver

Hi,
I think when I bought the new Lenovo Thinkpad X1 Yoga (Gen 6) I was able to use hcxdumptool without any issues. Now, after a few months using the laptop, when I tried again, I got many driver errors and it seems like injection is not working as good as before. Of course, in the meantime there have been BIOS updates, kernel updates, firmware updates... so it's hard for me to debug this.
Maybe here someone can help me to debug and try to find the real issue here, and open a bug in the proper project upstream (Lenovo support, linux kernel, iwlwifi...).
This laptop has an Intel AX201 chipset. Please let me know what logs or information would be useful to share here and I will try to share as soon as possible. For the moment I copy-paste what I see in dmesg error messages when I call hcxdumptool.
[ 1566.917386] RIP: 0033:0x7f6620e3b59b
[ 1566.917392] Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a5 a8 0c 00 f7 d8 64 89 01 48
[ 1566.917395] RSP: 002b:00007ffc67e86bb8 EFLAGS: 00000246 ORIG_RAX:<PHONE_NUMBER>000010
[ 1566.917401] RAX: ffffffffffffffda RBX:<PHONE_NUMBER>0000a9 RCX: 00007f6620e3b59b
[ 1566.917404] RDX:<PHONE_NUMBER>407da0 RSI:<PHONE_NUMBER>008b04 RDI:<PHONE_NUMBER>000003
[ 1566.917406] RBP:<PHONE_NUMBER>000025 R08:<PHONE_NUMBER>000002 R09: 006e6f6d33663032
[ 1566.917408] R10:<PHONE_NUMBER>00001a R11:<PHONE_NUMBER>000246 R12:<PHONE_NUMBER>407da0
[ 1566.917410] R13:<PHONE_NUMBER>000003 R14:<PHONE_NUMBER>3f4040 R15: 00007ffc67e87de7
[ 1566.917417] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1566.917420] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1566.917447] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1566.917450] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1566.917456] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1566.917458] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1566.917464] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1566.917466] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1574.321266] iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.
[ 1574.322399] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[ 1574.322401] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 6
[ 1574.322404] iwlwifi 0000:00:14.3: Loaded firmware version: 62.49eeb572.0 QuZ-a0-hr-b0-62.ucode
[ 1574.322407] iwlwifi 0000:00:14.3: 0x0000125F | ADVANCED_SYSASSERT
[ 1574.322411] iwlwifi 0000:00:14.3: 0x0080A210 | trm_hw_status0
[ 1574.322413] iwlwifi 0000:00:14.3: 0x00000000 | trm_hw_status1
[ 1574.322415] iwlwifi 0000:00:14.3: 0x004CAEFE | branchlink2
[ 1574.322417] iwlwifi 0000:00:14.3: 0x000015E2 | interruptlink1
[ 1574.322418] iwlwifi 0000:00:14.3: 0x000015E2 | interruptlink2
[ 1574.322420] iwlwifi 0000:00:14.3: 0x00000001 | data1
[ 1574.322422] iwlwifi 0000:00:14.3: 0xDEADBEEF | data2
[ 1574.322424] iwlwifi 0000:00:14.3: 0xDEADBEEF | data3
[ 1574.322426] iwlwifi 0000:00:14.3: 0x00000000 | beacon time
[ 1574.322428] iwlwifi 0000:00:14.3: 0x002095BC | tsf low
[ 1574.322429] iwlwifi 0000:00:14.3: 0x00000000 | tsf hi
[ 1574.322431] iwlwifi 0000:00:14.3: 0x00000000 | time gp1
[ 1574.322433] iwlwifi 0000:00:14.3: 0x0020FC23 | time gp2
[ 1574.322435] iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
[ 1574.322436] iwlwifi 0000:00:14.3: 0x0000003E | uCode version major
[ 1574.322438] iwlwifi 0000:00:14.3: 0x49EEB572 | uCode version minor
[ 1574.322440] iwlwifi 0000:00:14.3: 0x00000351 | hw version
[ 1574.322442] iwlwifi 0000:00:14.3: 0x00489004 | board version
[ 1574.322444] iwlwifi 0000:00:14.3: 0x801DFC27 | hcmd
[ 1574.322446] iwlwifi 0000:00:14.3: 0x24020000 | isr0
[ 1574.322447] iwlwifi 0000:00:14.3: 0x01000000 | isr1
[ 1574.322449] iwlwifi 0000:00:14.3: 0x00B00002 | isr2
[ 1574.322451] iwlwifi 0000:00:14.3: 0x00C0000D | isr3
[ 1574.322452] iwlwifi 0000:00:14.3: 0x00000000 | isr4
[ 1574.322454] iwlwifi 0000:00:14.3: 0x0106001C | last cmd Id
[ 1574.322456] iwlwifi 0000:00:14.3: 0x0000AD62 | wait_event
[ 1574.322458] iwlwifi 0000:00:14.3: 0x00000080 | l2p_control
[ 1574.322459] iwlwifi 0000:00:14.3: 0x00010034 | l2p_duration
[ 1574.322461] iwlwifi 0000:00:14.3: 0x0000003F | l2p_mhvalid
[ 1574.322463] iwlwifi 0000:00:14.3: 0x00008000 | l2p_addr_match
[ 1574.322465] iwlwifi 0000:00:14.3: 0x0000000B | lmpm_pmg_sel
[ 1574.322467] iwlwifi 0000:00:14.3: 0x00000000 | timestamp
[ 1574.322469] iwlwifi 0000:00:14.3: 0x00D0D020 | flow_handler
[ 1574.322586] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[ 1574.322588] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 7
[ 1574.322590] iwlwifi 0000:00:14.3: 0x20000070 | NMI_INTERRUPT_LMAC_FATAL
[ 1574.322592] iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
[ 1574.322594] iwlwifi 0000:00:14.3: 0x80454C8A | umac branchlink2
[ 1574.322595] iwlwifi 0000:00:14.3: 0x80473A88 | umac interruptlink1
[ 1574.322597] iwlwifi 0000:00:14.3: 0x80466C8A | umac interruptlink2
[ 1574.322599] iwlwifi 0000:00:14.3: 0x00000400 | umac data1
[ 1574.322601] iwlwifi 0000:00:14.3: 0x80466C8A | umac data2
[ 1574.322602] iwlwifi 0000:00:14.3: 0x00000000 | umac data3
[ 1574.322604] iwlwifi 0000:00:14.3: 0x0000003E | umac major
[ 1574.322606] iwlwifi 0000:00:14.3: 0x49EEB572 | umac minor
[ 1574.322607] iwlwifi 0000:00:14.3: 0x0020FC51 | frame pointer
[ 1574.322609] iwlwifi 0000:00:14.3: 0xC0887EF4 | stack pointer
[ 1574.322611] iwlwifi 0000:00:14.3: 0x00080119 | last host cmd
[ 1574.322612] iwlwifi 0000:00:14.3: 0x00200040 | isr status reg
[ 1574.322779] iwlwifi 0000:00:14.3: IML/ROM dump:
[ 1574.322780] iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
[ 1574.322867] iwlwifi 0000:00:14.3: 0x00006082 | IML/ROM data1
[ 1574.322906] iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
[ 1574.322952] iwlwifi 0000:00:14.3: Fseq Registers:
[ 1574.322983] iwlwifi 0000:00:14.3: 0x20000000 | FSEQ_ERROR_CODE
[ 1574.323008] iwlwifi 0000:00:14.3: 0x80290033 | FSEQ_TOP_INIT_VERSION
[ 1574.323035] iwlwifi 0000:00:14.3: 0x00090006 | FSEQ_CNVIO_INIT_VERSION
[ 1574.323061] iwlwifi 0000:00:14.3: 0x0000A482 | FSEQ_OTP_VERSION
[ 1574.323088] iwlwifi 0000:00:14.3: 0x00000003 | FSEQ_TOP_CONTENT_VERSION
[ 1574.323114] iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
[ 1574.323139] iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
[ 1574.323164] iwlwifi 0000:00:14.3: 0x01300504 | FSEQ_CNVR_ID
[ 1574.323190] iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
[ 1574.323218] iwlwifi 0000:00:14.3: 0x01300504 | CNVR_AUX_MISC_CHIP
[ 1574.323247] iwlwifi 0000:00:14.3: 0x05B0905B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[ 1574.323283] iwlwifi 0000:00:14.3: 0x0000025B | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[ 1574.324934] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
[ 1574.324942] ieee80211 phy0: Hardware restart was requested
[ 1574.325047] iwlwifi 0000:00:14.3: FW error in SYNC CMD REMOVE_STA
[ 1574.325054] CPU: 2 PID: 3505 Comm: hcxdumptool Not tainted 5.13.13-arch1-1 #1
[ 1574.325059] Hardware name: LENOVO 20XYCTO1WW/20XYCTO1WW, BIOS N32ET68W (1.44 ) 07/16/2021
[ 1574.325062] Call Trace:
[ 1574.325069]  dump_stack+0x76/0x94
[ 1574.325081]  iwl_trans_txq_send_hcmd+0x47f/0x490 [iwlwifi]
[ 1574.325114]  ? do_wait_intr_irq+0xc0/0xc0
[ 1574.325121]  iwl_trans_send_cmd+0x84/0xe0 [iwlwifi]
[ 1574.325147]  iwl_mvm_send_cmd_pdu+0x5c/0xa0 [iwlmvm]
[ 1574.325172]  iwl_mvm_rm_sta_common+0x58/0xc0 [iwlmvm]
[ 1574.325194]  iwl_mvm_rm_snif_sta+0x3b/0x70 [iwlmvm]
[ 1574.325212]  __iwl_mvm_unassign_vif_chanctx.constprop.0+0xc1/0x160 [iwlmvm]
[ 1574.325228]  iwl_mvm_unassign_vif_chanctx+0x2e/0x40 [iwlmvm]
[ 1574.325244]  ieee80211_assign_vif_chanctx+0x88/0x480 [mac80211]
[ 1574.325318]  __ieee80211_vif_release_channel+0x4f/0x130 [mac80211]
[ 1574.325371]  ieee80211_vif_release_channel+0x3a/0x50 [mac80211]
[ 1574.325420]  ieee80211_set_monitor_channel+0x5d/0x140 [mac80211]
[ 1574.325475]  cfg80211_set_monitor_channel+0x56/0x120 [cfg80211]
[ 1574.325538]  __cfg80211_wext_siwfreq+0x176/0x1b0 [cfg80211]
[ 1574.325599]  ioctl_standard_call+0x4a/0x100
[ 1574.325605]  wext_handle_ioctl+0x15e/0x1a0
[ 1574.325610]  sock_ioctl+0x244/0x360
[ 1574.325617]  __x64_sys_ioctl+0x7f/0xb0
[ 1574.325625]  do_syscall_64+0x5e/0x80
[ 1574.325630]  ? do_syscall_64+0x6e/0x80
[ 1574.325633]  ? syscall_exit_to_user_mode+0x23/0x50
[ 1574.325638]  ? do_syscall_64+0x6e/0x80
[ 1574.325641]  ? do_syscall_64+0x6e/0x80
[ 1574.325644]  ? syscall_exit_to_user_mode+0x23/0x50
[ 1574.325648]  ? do_syscall_64+0x6e/0x80
[ 1574.325651]  ? do_syscall_64+0x6e/0x80
[ 1574.325654]  ? do_syscall_64+0x6e/0x80
[ 1574.325656]  ? do_syscall_64+0x6e/0x80
[ 1574.325660]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 1574.325667] RIP: 0033:0x7f6620e3b59b
[ 1574.325673] Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a5 a8 0c 00 f7 d8 64 89 01 48
[ 1574.325676] RSP: 002b:00007ffc67e86ba8 EFLAGS: 00000246 ORIG_RAX:<PHONE_NUMBER>000010
[ 1574.325682] RAX: ffffffffffffffda RBX:<PHONE_NUMBER>46f8c0 RCX: 00007f6620e3b59b
[ 1574.325684] RDX:<PHONE_NUMBER>407de0 RSI:<PHONE_NUMBER>008b04 RDI:<PHONE_NUMBER>000003
[ 1574.325687] RBP:<PHONE_NUMBER>407060 R08:<PHONE_NUMBER>000002 R09: 006e6f6d33663032
[ 1574.325689] R10:<PHONE_NUMBER>00001a R11:<PHONE_NUMBER>000246 R12:<PHONE_NUMBER>000003
[ 1574.325691] R13:<PHONE_NUMBER>3f4040 R14:<PHONE_NUMBER>407de0 R15:<PHONE_NUMBER>407300
[ 1574.325713] iwlwifi 0000:00:14.3: Failed to remove station. Id=1
[ 1574.325717] iwlwifi 0000:00:14.3: Failed sending remove station
[ 1574.325721] iwlwifi 0000:00:14.3: Failed to send binding (action:3): -5
[ 1574.325735] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1574.325744] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1574.325746] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1574.325772] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1574.325773] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1574.325778] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1574.325780] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1574.325784] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1574.325786] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1574.325790] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1574.325792] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1574.325797] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1574.325798] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1574.325803] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1574.325805] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1580.581586] iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.
[ 1580.581698] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[ 1580.581700] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 6
[ 1580.581703] iwlwifi 0000:00:14.3: Loaded firmware version: 62.49eeb572.0 QuZ-a0-hr-b0-62.ucode
[ 1580.581706] iwlwifi 0000:00:14.3: 0x00000034 | NMI_INTERRUPT_WDG
[ 1580.581710] iwlwifi 0000:00:14.3: 0x000022F3 | trm_hw_status0
[ 1580.581712] iwlwifi 0000:00:14.3: 0x00000000 | trm_hw_status1
[ 1580.581714] iwlwifi 0000:00:14.3: 0x004CAEFE | branchlink2
[ 1580.581716] iwlwifi 0000:00:14.3: 0x000143CC | interruptlink1
[ 1580.581718] iwlwifi 0000:00:14.3: 0x000143CC | interruptlink2
[ 1580.581720] iwlwifi 0000:00:14.3: 0x004C9C06 | data1
[ 1580.581722] iwlwifi 0000:00:14.3: 0x00000000 | data2
[ 1580.581724] iwlwifi 0000:00:14.3: 0x00000000 | data3
[ 1580.581726] iwlwifi 0000:00:14.3: 0x00000000 | beacon time
[ 1580.581728] iwlwifi 0000:00:14.3: 0x00000000 | tsf low
[ 1580.581729] iwlwifi 0000:00:14.3: 0x00000000 | tsf hi
[ 1580.581731] iwlwifi 0000:00:14.3: 0x00000000 | time gp1
[ 1580.581733] iwlwifi 0000:00:14.3: 0x00065B71 | time gp2
[ 1580.581735] iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
[ 1580.581737] iwlwifi 0000:00:14.3: 0x0000003E | uCode version major
[ 1580.581739] iwlwifi 0000:00:14.3: 0x49EEB572 | uCode version minor
[ 1580.581741] iwlwifi 0000:00:14.3: 0x00000351 | hw version
[ 1580.581743] iwlwifi 0000:00:14.3: 0x00489004 | board version
[ 1580.581745] iwlwifi 0000:00:14.3: 0x8053FC12 | hcmd
[ 1580.581747] iwlwifi 0000:00:14.3: 0x62EA8400 | isr0
[ 1580.581749] iwlwifi 0000:00:14.3: 0x40000000 | isr1
[ 1580.581750] iwlwifi 0000:00:14.3: 0x08F80002 | isr2
[ 1580.581752] iwlwifi 0000:00:14.3: 0x04C37FDC | isr3
[ 1580.581754] iwlwifi 0000:00:14.3: 0x00000000 | isr4
[ 1580.581756] iwlwifi 0000:00:14.3: 0x00120148 | last cmd Id
[ 1580.581758] iwlwifi 0000:00:14.3: 0x004C9C06 | wait_event
[ 1580.581760] iwlwifi 0000:00:14.3: 0x00000000 | l2p_control
[ 1580.581762] iwlwifi 0000:00:14.3: 0x00001C20 | l2p_duration
[ 1580.581764] iwlwifi 0000:00:14.3: 0x00000000 | l2p_mhvalid
[ 1580.581765] iwlwifi 0000:00:14.3: 0x00000000 | l2p_addr_match
[ 1580.581767] iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
[ 1580.581769] iwlwifi 0000:00:14.3: 0x00000000 | timestamp
[ 1580.581771] iwlwifi 0000:00:14.3: 0x00001854 | flow_handler
[ 1580.581827] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[ 1580.581829] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 7
[ 1580.581832] iwlwifi 0000:00:14.3: 0x20000070 | NMI_INTERRUPT_LMAC_FATAL
[ 1580.581834] iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
[ 1580.581836] iwlwifi 0000:00:14.3: 0x80454C8A | umac branchlink2
[ 1580.581838] iwlwifi 0000:00:14.3: 0x80473A88 | umac interruptlink1
[ 1580.581840] iwlwifi 0000:00:14.3: 0x80473A88 | umac interruptlink2
[ 1580.581842] iwlwifi 0000:00:14.3: 0x00000400 | umac data1
[ 1580.581843] iwlwifi 0000:00:14.3: 0x80473A88 | umac data2
[ 1580.581845] iwlwifi 0000:00:14.3: 0x00000000 | umac data3
[ 1580.581847] iwlwifi 0000:00:14.3: 0x0000003E | umac major
[ 1580.581849] iwlwifi 0000:00:14.3: 0x49EEB572 | umac minor
[ 1580.581851] iwlwifi 0000:00:14.3: 0x00065BC8 | frame pointer
[ 1580.581853] iwlwifi 0000:00:14.3: 0xC0886270 | stack pointer
[ 1580.581854] iwlwifi 0000:00:14.3: 0x001B0119 | last host cmd
[ 1580.581856] iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
[ 1580.581891] iwlwifi 0000:00:14.3: IML/ROM dump:
[ 1580.581892] iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
[ 1580.581908] iwlwifi 0000:00:14.3: 0x00006071 | IML/ROM data1
[ 1580.581919] iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
[ 1580.581973] iwlwifi 0000:00:14.3: Fseq Registers:
[ 1580.581979] iwlwifi 0000:00:14.3: 0x20000000 | FSEQ_ERROR_CODE
[ 1580.581986] iwlwifi 0000:00:14.3: 0x80290033 | FSEQ_TOP_INIT_VERSION
[ 1580.582004] iwlwifi 0000:00:14.3: 0x00090006 | FSEQ_CNVIO_INIT_VERSION
[ 1580.582010] iwlwifi 0000:00:14.3: 0x0000A482 | FSEQ_OTP_VERSION
[ 1580.582016] iwlwifi 0000:00:14.3: 0x00000003 | FSEQ_TOP_CONTENT_VERSION
[ 1580.582022] iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
[ 1580.582028] iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
[ 1580.582035] iwlwifi 0000:00:14.3: 0x01300504 | FSEQ_CNVR_ID
[ 1580.582041] iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
[ 1580.582051] iwlwifi 0000:00:14.3: 0x01300504 | CNVR_AUX_MISC_CHIP
[ 1580.582062] iwlwifi 0000:00:14.3: 0x05B0905B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[ 1580.582083] iwlwifi 0000:00:14.3: 0x0000025B | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[ 1580.582266] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
[ 1580.582274] ieee80211 phy0: Hardware restart was requested
[ 1580.582377] iwlwifi 0000:00:14.3: FW error in SYNC CMD REMOVE_STA
[ 1580.582383] CPU: 2 PID: 3505 Comm: hcxdumptool Not tainted 5.13.13-arch1-1 #1
[ 1580.582388] Hardware name: LENOVO 20XYCTO1WW/20XYCTO1WW, BIOS N32ET68W (1.44 ) 07/16/2021
[ 1580.582391] Call Trace:
[ 1580.582395]  dump_stack+0x76/0x94
[ 1580.582406]  iwl_trans_txq_send_hcmd+0x47f/0x490 [iwlwifi]
[ 1580.582447]  ? do_wait_intr_irq+0xc0/0xc0
[ 1580.582453]  iwl_trans_send_cmd+0x84/0xe0 [iwlwifi]
[ 1580.582481]  iwl_mvm_send_cmd_pdu+0x5c/0xa0 [iwlmvm]
[ 1580.582505]  iwl_mvm_rm_sta_common+0x58/0xc0 [iwlmvm]
[ 1580.582528]  iwl_mvm_rm_snif_sta+0x3b/0x70 [iwlmvm]
[ 1580.582548]  __iwl_mvm_unassign_vif_chanctx.constprop.0+0xc1/0x160 [iwlmvm]
[ 1580.582567]  iwl_mvm_unassign_vif_chanctx+0x2e/0x40 [iwlmvm]
[ 1580.582585]  ieee80211_assign_vif_chanctx+0x88/0x480 [mac80211]
[ 1580.582661]  __ieee80211_vif_release_channel+0x4f/0x130 [mac80211]
[ 1580.582718]  ieee80211_vif_release_channel+0x3a/0x50 [mac80211]
[ 1580.582771]  ieee80211_set_monitor_channel+0x5d/0x140 [mac80211]
[ 1580.582829]  cfg80211_set_monitor_channel+0x56/0x120 [cfg80211]
[ 1580.582895]  __cfg80211_wext_siwfreq+0x176/0x1b0 [cfg80211]
[ 1580.582961]  ioctl_standard_call+0x4a/0x100
[ 1580.582968]  wext_handle_ioctl+0x15e/0x1a0
[ 1580.582973]  sock_ioctl+0x244/0x360
[ 1580.582980]  __x64_sys_ioctl+0x7f/0xb0
[ 1580.582988]  do_syscall_64+0x5e/0x80
[ 1580.582993]  ? syscall_exit_to_user_mode+0x23/0x50
[ 1580.582998]  ? do_syscall_64+0x6e/0x80
[ 1580.583002]  ? do_syscall_64+0x6e/0x80
[ 1580.583005]  ? do_syscall_64+0x6e/0x80
[ 1580.583008]  ? do_syscall_64+0x6e/0x80
[ 1580.583011]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 1580.583018] RIP: 0033:0x7f6620e3b59b
[ 1580.583024] Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a5 a8 0c 00 f7 d8 64 89 01 48
[ 1580.583029] RSP: 002b:00007ffc67e86ba8 EFLAGS: 00000246 ORIG_RAX:<PHONE_NUMBER>000010
[ 1580.583034] RAX: ffffffffffffffda RBX:<PHONE_NUMBER>46f8c0 RCX: 00007f6620e3b59b
[ 1580.583037] RDX:<PHONE_NUMBER>407de0 RSI:<PHONE_NUMBER>008b04 RDI:<PHONE_NUMBER>000003
[ 1580.583040] RBP:<PHONE_NUMBER>407060 R08:<PHONE_NUMBER>000002 R09: 006e6f6d33663032
[ 1580.583042] R10:<PHONE_NUMBER>00001a R11:<PHONE_NUMBER>000246 R12:<PHONE_NUMBER>000003
[ 1580.583044] R13:<PHONE_NUMBER>3f4040 R14:<PHONE_NUMBER>407de0 R15:<PHONE_NUMBER>407300
[ 1580.583054] iwlwifi 0000:00:14.3: Failed to remove station. Id=1
[ 1580.583058] iwlwifi 0000:00:14.3: Failed sending remove station
[ 1580.583062] iwlwifi 0000:00:14.3: Failed to send binding (action:3): -5
[ 1580.583076] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1580.583085] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1580.583087] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1580.583116] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1580.583118] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1580.583123] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1580.583125] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1580.583130] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1580.583132] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1580.583138] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1580.583140] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1580.583145] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1580.583147] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1580.583152] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1580.583154] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1580.959388] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[ 1580.959390] iwlwifi 0000:00:14.3: Failed to add PHY context
[ 1585.691559] device wlp0s20f3mon left promiscuous mode

By the way, I am running Arch Linux, and I tried with official pacakges linux (5.13.13) and linux-lts (5.10.61), as well as compiled linux-mainline (5.14.0). With all I get similar error messages.
I also realized that initialization phase takes too long and it puts one core to work 100% for a few seconds. I don't think that was the case in the past, and using airmon-ng to enable monitor mode seems to work better for me now.

As you noticed correctly this a firmware or driver issue.
It is either caused by firmware (I assume this)
"Microcode SW error detected."
"FW error in SYNC CMD REMOVE_STA"
or by driver
"PHY ctxt cmd error."
but not by hcxdumptool
"hcxdumptool Not tainted 5.13.13-arch1-1 #1"
There is nothing I can do, except to suggest to report this issue on
https://bugzilla.kernel.org/
There have been several several problems running Intel chipsets in the past.
So I decided to print a warning in README.md Adapter section
https://github.com/ZerBea/hcxdumptool#readme
Not recommended WiFi chipsets:
    Intel PRO/Wireless
    Broadcom
    Realtek RTL8811AU, RTL8812AU, RTL 8814AU (due to NETLINK dependency)

BTW:
Running airmon-ng is not a good idea due to NETLINK dependency.
airmon-ng is running iw and iw is running NETLINK.
You can see this if you enable iw debugging:
$ sudo iw --debug dev wlp0s20f3 set type monitor

which will show you that NETLINK is in use.
Here is an example of the debugging output of iw:
$ sudo iw --debug dev wlp39s0f3u1u1u2 set type monitor
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 36
    .type = 33 <0x21>
    .flags = 5 <REQUEST,ACK>
    .seq =<PHONE_NUMBER>
    .port = -1778364009
  [GENERIC NETLINK HEADER] 4 octets
    .cmd = 6
    .version = 0
    .unused = 0
  [PAYLOAD] 16 octets
    08 00 03 00 03 00 00 00 08 00 05 00 06 00 00 00 ................
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 36
    .type = 2 <ERROR>
    .flags = 256 <ROOT>
    .seq =<PHONE_NUMBER>
    .port = -1778364009
  [ERRORMSG] 20 octets
    .error = 0 "Erfolg"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .type = 33 <0x21>
    .flags = 5 <REQUEST,ACK>
    .seq =<PHONE_NUMBER>
    .port = -1778364009
---------------------------  END NETLINK MESSAGE   ---------------------------

versus hcxdumptool monitor mode via ioctl() system calls:
$ sudo hcxdumptool -m wlp39s0f3u1u1u2
setting interface wlp39s0f3u1u1u2 to monitor mode

hcxdumptool driver test:
$ sudo hcxdumptool -i wlp39s0f3u1u1u2 --check_driver
initialization of hcxdumptool 6.2.0-33-g5297097...
starting driver test...
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...

and hcxdumptool full packet injection test:
$ sudo hcxdumptool -i wlp39s0f3u1u1u2 --check_injection
initialization of hcxdumptool 6.2.0-33-g5297097...
starting antenna test and packet injection test (that can take up to two minutes)...
available channels: 1,2,3,4,5,6,7,8,9,10,11,12,13,14
packet injection is working on 2.4GHz!
injection ratio: 44% (BEACON: 204 PROBERESPONSE: 90)
your injection ratio is average, but there is still room for improvement
antenna ratio: 91% (NETWORK: 34 PROBERESPONSE: 31)
your antenna ratio is huge - say kids what time is it?

terminating...

You can run all three commands and check dmesg after each command to figure out what happens.
Do not use airmon-ng or iw before the test.

Thanks for the help! I guess I will open first a bug report in Arch, as recommended in https://bugzilla.kernel.org/, and if they tell me to open a bug directly at the kernel bugzilla, then I will do that.
Just out of curiosity, why is so bad to use NETLINK instead of ioctl calls?

hcxdumptool/hcxlabtool is running high performance attacks. To control the device, fast system calls are mandatory.
Here is a good explanation:
https://www.quora.com/What-are-the-differences-between-netlink-sockets-and-ioctl-calls?share=1

In addition to that, we have to create and evaluate additional NETLINK headers. That produce overhead and will cost CPU cycles which we don't have on a Raspberry Pi.

You mentioned airmon-ng. That let me assume you are familiar with the aircrack-ng suite.
To figure out if the driver has a problem, running NETLINK to init the device you can do the following test:
Get aircrack-ng source.
Configure aircrack-ng without libnl dependency by passing --disable-libnl to configure
Put interface  wlp0s20f3 to monitor mode.
Then run an injection test  by aireplay-ng -9 wlp0s20f3
https://www.aircrack-ng.org/doku.php?id=injection_test
See aireplay-ng messages and dmesg, what happens.

First of all, thank you very much for keep writing here even though it is clear not a hcxdumptool issue. I will open a bug in Arch when I have a bit more of time. But for the moment I did what you just told me, and I copy here the outputs:
dmesg
[  469.638086] device wlp0s20f3mon entered promiscuous mode
[  471.490675] iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.
[  471.491702] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[  471.491703] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 6
[  471.491704] iwlwifi 0000:00:14.3: Loaded firmware version: 62.49eeb572.0 QuZ-a0-hr-b0-62.ucode
[  471.491705] iwlwifi 0000:00:14.3: 0x00004217 | ADVANCED_SYSASSERT
[  471.491706] iwlwifi 0000:00:14.3: 0x00A022F0 | trm_hw_status0
[  471.491707] iwlwifi 0000:00:14.3: 0x00000000 | trm_hw_status1
[  471.491707] iwlwifi 0000:00:14.3: 0x004CAEFE | branchlink2
[  471.491708] iwlwifi 0000:00:14.3: 0x000015E2 | interruptlink1
[  471.491709] iwlwifi 0000:00:14.3: 0x000015E2 | interruptlink2
[  471.491709] iwlwifi 0000:00:14.3: 0x044E00B4 | data1
[  471.491710] iwlwifi 0000:00:14.3: 0x00000010 | data2
[  471.491710] iwlwifi 0000:00:14.3: 0xDEADBEEF | data3
[  471.491711] iwlwifi 0000:00:14.3: 0x00000000 | beacon time
[  471.491711] iwlwifi 0000:00:14.3: 0x013E8CC1 | tsf low
[  471.491712] iwlwifi 0000:00:14.3: 0x00000000 | tsf hi
[  471.491712] iwlwifi 0000:00:14.3: 0x00000000 | time gp1
[  471.491713] iwlwifi 0000:00:14.3: 0x013EF3EE | time gp2
[  471.491713] iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
[  471.491714] iwlwifi 0000:00:14.3: 0x0000003E | uCode version major
[  471.491714] iwlwifi 0000:00:14.3: 0x49EEB572 | uCode version minor
[  471.491715] iwlwifi 0000:00:14.3: 0x00000351 | hw version
[  471.491716] iwlwifi 0000:00:14.3: 0x00489004 | board version
[  471.491716] iwlwifi 0000:00:14.3: 0x0103001C | hcmd
[  471.491717] iwlwifi 0000:00:14.3: 0x00020000 | isr0
[  471.491717] iwlwifi 0000:00:14.3: 0x00000000 | isr1
[  471.491718] iwlwifi 0000:00:14.3: 0x08F00002 | isr2
[  471.491718] iwlwifi 0000:00:14.3: 0x00C20008 | isr3
[  471.491719] iwlwifi 0000:00:14.3: 0x00000000 | isr4
[  471.491719] iwlwifi 0000:00:14.3: 0x0103001C | last cmd Id
[  471.491720] iwlwifi 0000:00:14.3: 0x000146F8 | wait_event
[  471.491720] iwlwifi 0000:00:14.3: 0x00000080 | l2p_control
[  471.491721] iwlwifi 0000:00:14.3: 0x00000020 | l2p_duration
[  471.491721] iwlwifi 0000:00:14.3: 0x0000003F | l2p_mhvalid
[  471.491722] iwlwifi 0000:00:14.3: 0x00008000 | l2p_addr_match
[  471.491722] iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
[  471.491723] iwlwifi 0000:00:14.3: 0x00000000 | timestamp
[  471.491723] iwlwifi 0000:00:14.3: 0x00002064 | flow_handler
[  471.492304] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[  471.492305] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 7
[  471.492306] iwlwifi 0000:00:14.3: 0x20000070 | NMI_INTERRUPT_LMAC_FATAL
[  471.492307] iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
[  471.492307] iwlwifi 0000:00:14.3: 0x80454C8A | umac branchlink2
[  471.492308] iwlwifi 0000:00:14.3: 0x80473A88 | umac interruptlink1
[  471.492308] iwlwifi 0000:00:14.3: 0x80473A88 | umac interruptlink2
[  471.492309] iwlwifi 0000:00:14.3: 0x00000400 | umac data1
[  471.492310] iwlwifi 0000:00:14.3: 0x80473A88 | umac data2
[  471.492310] iwlwifi 0000:00:14.3: 0x00000000 | umac data3
[  471.492311] iwlwifi 0000:00:14.3: 0x0000003E | umac major
[  471.492311] iwlwifi 0000:00:14.3: 0x49EEB572 | umac minor
[  471.492312] iwlwifi 0000:00:14.3: 0x013EF40B | frame pointer
[  471.492312] iwlwifi 0000:00:14.3: 0xC0886270 | stack pointer
[  471.492313] iwlwifi 0000:00:14.3: 0x00250108 | last host cmd
[  471.492313] iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
[  471.492433] iwlwifi 0000:00:14.3: IML/ROM dump:
[  471.492433] iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
[  471.492520] iwlwifi 0000:00:14.3: 0x000060F0 | IML/ROM data1
[  471.492609] iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
[  471.492652] iwlwifi 0000:00:14.3: Fseq Registers:
[  471.492675] iwlwifi 0000:00:14.3: 0x20000000 | FSEQ_ERROR_CODE
[  471.492698] iwlwifi 0000:00:14.3: 0x80290033 | FSEQ_TOP_INIT_VERSION
[  471.492719] iwlwifi 0000:00:14.3: 0x00090006 | FSEQ_CNVIO_INIT_VERSION
[  471.492741] iwlwifi 0000:00:14.3: 0x0000A482 | FSEQ_OTP_VERSION
[  471.492763] iwlwifi 0000:00:14.3: 0x00000003 | FSEQ_TOP_CONTENT_VERSION
[  471.492785] iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
[  471.492807] iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
[  471.492829] iwlwifi 0000:00:14.3: 0x01300504 | FSEQ_CNVR_ID
[  471.492850] iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
[  471.492874] iwlwifi 0000:00:14.3: 0x01300504 | CNVR_AUX_MISC_CHIP
[  471.492899] iwlwifi 0000:00:14.3: 0x05B0905B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[  471.492924] iwlwifi 0000:00:14.3: 0x0000025B | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[  471.494580] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
[  471.494582] ieee80211 phy0: Hardware restart was requested
[  477.917793] iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.
[  477.919116] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[  477.919118] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 6
[  477.919122] iwlwifi 0000:00:14.3: Loaded firmware version: 62.49eeb572.0 QuZ-a0-hr-b0-62.ucode
[  477.919125] iwlwifi 0000:00:14.3: 0x00004217 | ADVANCED_SYSASSERT
[  477.919128] iwlwifi 0000:00:14.3: 0x00A0A210 | trm_hw_status0
[  477.919130] iwlwifi 0000:00:14.3: 0x00000000 | trm_hw_status1
[  477.919132] iwlwifi 0000:00:14.3: 0x004CAEFE | branchlink2
[  477.919134] iwlwifi 0000:00:14.3: 0x000015E2 | interruptlink1
[  477.919136] iwlwifi 0000:00:14.3: 0x000015E2 | interruptlink2
[  477.919138] iwlwifi 0000:00:14.3: 0x044E00B4 | data1
[  477.919140] iwlwifi 0000:00:14.3: 0x00000010 | data2
[  477.919142] iwlwifi 0000:00:14.3: 0xDEADBEEF | data3
[  477.919144] iwlwifi 0000:00:14.3: 0x00000000 | beacon time
[  477.919146] iwlwifi 0000:00:14.3: 0x0003434E | tsf low
[  477.919148] iwlwifi 0000:00:14.3: 0x00000000 | tsf hi
[  477.919149] iwlwifi 0000:00:14.3: 0x00000000 | time gp1
[  477.919151] iwlwifi 0000:00:14.3: 0x0003AAEC | time gp2
[  477.919153] iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
[  477.919155] iwlwifi 0000:00:14.3: 0x0000003E | uCode version major
[  477.919157] iwlwifi 0000:00:14.3: 0x49EEB572 | uCode version minor
[  477.919159] iwlwifi 0000:00:14.3: 0x00000351 | hw version
[  477.919160] iwlwifi 0000:00:14.3: 0x00489004 | board version
[  477.919162] iwlwifi 0000:00:14.3: 0x0100001C | hcmd
[  477.919164] iwlwifi 0000:00:14.3: 0x24020000 | isr0
[  477.919166] iwlwifi 0000:00:14.3: 0x00000080 | isr1
[  477.919168] iwlwifi 0000:00:14.3: 0x08F00002 | isr2
[  477.919169] iwlwifi 0000:00:14.3: 0x00C3200C | isr3
[  477.919171] iwlwifi 0000:00:14.3: 0x00000000 | isr4
[  477.919173] iwlwifi 0000:00:14.3: 0x0100001C | last cmd Id
[  477.919175] iwlwifi 0000:00:14.3: 0x000146F8 | wait_event
[  477.919176] iwlwifi 0000:00:14.3: 0x000000D4 | l2p_control
[  477.919178] iwlwifi 0000:00:14.3: 0x00010034 | l2p_duration
[  477.919180] iwlwifi 0000:00:14.3: 0x00000007 | l2p_mhvalid
[  477.919182] iwlwifi 0000:00:14.3: 0x00000000 | l2p_addr_match
[  477.919184] iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
[  477.919185] iwlwifi 0000:00:14.3: 0x00000000 | timestamp
[  477.919187] iwlwifi 0000:00:14.3: 0x00001858 | flow_handler
[  477.919680] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[  477.919682] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 7
[  477.919684] iwlwifi 0000:00:14.3: 0x20000070 | NMI_INTERRUPT_LMAC_FATAL
[  477.919686] iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
[  477.919688] iwlwifi 0000:00:14.3: 0x80454C8A | umac branchlink2
[  477.919690] iwlwifi 0000:00:14.3: 0xC0084D6C | umac interruptlink1
[  477.919692] iwlwifi 0000:00:14.3: 0x0102E2D2 | umac interruptlink2
[  477.919694] iwlwifi 0000:00:14.3: 0x00000400 | umac data1
[  477.919696] iwlwifi 0000:00:14.3: 0x0102E2D2 | umac data2
[  477.919698] iwlwifi 0000:00:14.3: 0x00000000 | umac data3
[  477.919699] iwlwifi 0000:00:14.3: 0x0000003E | umac major
[  477.919701] iwlwifi 0000:00:14.3: 0x49EEB572 | umac minor
[  477.919703] iwlwifi 0000:00:14.3: 0x0003AB11 | frame pointer
[  477.919705] iwlwifi 0000:00:14.3: 0xC08874E0 | stack pointer
[  477.919706] iwlwifi 0000:00:14.3: 0x00190207 | last host cmd
[  477.919708] iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
[  477.919931] iwlwifi 0000:00:14.3: IML/ROM dump:
[  477.919933] iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
[  477.919953] iwlwifi 0000:00:14.3: 0x000061CF | IML/ROM data1
[  477.919963] iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
[  477.920018] iwlwifi 0000:00:14.3: Fseq Registers:
[  477.920043] iwlwifi 0000:00:14.3: 0x20000000 | FSEQ_ERROR_CODE
[  477.920069] iwlwifi 0000:00:14.3: 0x80290033 | FSEQ_TOP_INIT_VERSION
[  477.920095] iwlwifi 0000:00:14.3: 0x00090006 | FSEQ_CNVIO_INIT_VERSION
[  477.920121] iwlwifi 0000:00:14.3: 0x0000A482 | FSEQ_OTP_VERSION
[  477.920147] iwlwifi 0000:00:14.3: 0x00000003 | FSEQ_TOP_CONTENT_VERSION
[  477.920172] iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
[  477.920198] iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
[  477.920225] iwlwifi 0000:00:14.3: 0x01300504 | FSEQ_CNVR_ID
[  477.920251] iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
[  477.920279] iwlwifi 0000:00:14.3: 0x01300504 | CNVR_AUX_MISC_CHIP
[  477.920308] iwlwifi 0000:00:14.3: 0x05B0905B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[  477.920364] iwlwifi 0000:00:14.3: 0x0000025B | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[  477.920520] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
[  477.920529] ieee80211 phy0: Hardware restart was requested

aireplay-ng -9
18:35:57  Trying broadcast probe requests...
18:35:59  No Answer...
18:35:59  Found 1 AP

18:35:59  Trying directed probe requests...
18:35:59  FC:4A:E9:70:A9:32 - channel: 10 - 'Kablonet Netmaster-A92D-G'
18:36:05   0/30:   0%

Do you see anything relevant in the dmesg that I should highlight in the bug reports in Arch/kernel?
By the way, I remember doing the same test when I got the laptop and I was getting 100% almost all the times. Also, aireplay-ng --deauth was working perfectly and now it doesn't, so I would say that currently injection is broken for AX201.

Thanks for sharing your test results.
As you can see, if aircrack-ng is compiled without libnl, packet injection is not working running AX201 driver :
18:35:59  No Answer...
and
18:36:05   0/30:   0%

Looks like init of the driver via NETLINK isn't completely done.
I've seen this problem on Realtek drivers, too:
https://github.com/aircrack-ng/rtl8812au/issues/376#issuecomment-526120499

Now I was able to totally crashed the laptop by running hcxdumptool -i wlp0s20f3 -s 1 --do_rcascan. The caps lock key led started to blink (I had to figure out what this means from Lenovo docs) and the system was totally unresponsive so I had to force a reboot by keep pressing the power button.

That sounds not good.
The iwlwifi driver need to be fixed.
There are lots of similar reports:
https://ask.fedoraproject.org/t/intel-r-wi-fi-6-ax201-driver-always-crashing-iwlwifi/10728
https://ask.fedoraproject.org/t/iwlwifi-driver-randomly-crashes-inoperable-until-reboot/12672
https://community.intel.com/t5/Wireless/iwlwifi-driver-randomly-crashes-in-Linux/m-p/643389
https://askubuntu.com/questions/1219893/iwlwifi-driver-crashing

I think, we can close this issue, because it is related to the broken driver.

Just for future reference, if someone is reading this closed issue. I open a bug report at the kernel bugzilla. Here is the link:
https://bugzilla.kernel.org/show_bug.cgi?id=214291

Good idea to report this issue on bugzilla.kernel.org.
I suspect, the issue is related to INTEL MICROCODE.

@ZerBea thanks for keeping the discussion upstream, I thought I was not going to hear from Intel at this point.

Can you please comment output of
$ hcxdumptool -i interface -C
to get a frequency list reported from the device as I did here
https://bugzilla.kernel.org/show_bug.cgi?id=214291#c7

Thanks. It looks like ioctl(SIOCSIWFREQ) failed.
To find out which ioctl() is working and which is damaged, please use iw to set monitor mode:
$ sudo ip link set dev INTERFACE down
$ sudo iw dev INTERFACE set type monitor
$ sudo ip link set dev INTERFACE up
Than do a driver test:
$ sudo hcxdumptool -i INTERFACE --check_driver
Followed by an injection test
$ sudo hcxdumptool -i INTERFACE --check_injection

[root@thinkpad ~]# ip link set dev wlp0s20f3 down
[root@thinkpad ~]# iw dev wlp0s20f3 set type monitor
[root@thinkpad ~]# ip link set dev wlp0s20f3 up
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 --check_driver
initialization of hcxdumptool 6.2.4...
starting driver test...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 --check_injection
initialization of hcxdumptool 6.2.4...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
channel 1 not available
starting antenna test and packet injection test (that can take up to two minutes)...
available channels: 2,3,4,5,6,7,8,9,10,11,12,13,40,44,48,52,56,60,64,112,116,120,124,128,132,136,140,144,149,153,157,161,165
packet injection is working on 2.4GHz!
injection ratio: 94% (BEACON: 138 PROBERESPONSE: 130)
your injection ratio is huge - say kids what time is it?
antenna ratio: 28% (NETWORK: 21 PROBERESPONSE: 6)
your antenna ratio is average, but there is still room for improvement

terminating...
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 -C
initialization of hcxdumptool 6.2.4...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
available channels:

terminating...

I rebooted the laptop before doing this, just to be sure that NETLINK is not used.
[root@thinkpad ~]# hcxdumptool -m wlp0s20f3
setting interface wlp0s20f3 to monitor mode
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 --check_driver
initialization of hcxdumptool 6.2.4...
starting driver test...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 --check_injection
initialization of hcxdumptool 6.2.4...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
starting antenna test and packet injection test (that can take up to two minutes)...
available channels: 1,2,3,4,5,6,7,8,9,10,11,12,13,60,64
packet injection is working on 2.4GHz!
injection ratio: 100% (BEACON: 56 PROBERESPONSE: 614)
your injection ratio is huge - say kids what time is it?
antenna ratio: 83% (NETWORK: 12 PROBERESPONSE: 10)
your antenna ratio is excellent, let's ride!

terminating...
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 -C
initialization of hcxdumptool 6.2.4...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
available channels:

terminating...

Thanks for the test.
It looks like the driver need NETLINK to set monitor mode and to bring the interface up - otherwise the interface will not be init completely
available channels by NETLINK init: 2,3,4,5,6,7,8,9,10,11,12,13,40,44,48,52,56,60,64,112,116,120,124,128,132,136,140,144,149,153,157,161,165
versus ioctl() init:
available channels: 1,2,3,4,5,6,7,8,9,10,11,12,13,60,64 ... than the driver crashed
I pushed an update. Please do a git pull, compile and comment output of
$ hcxdumptool -i wlp0s20f3 -C
BTW:
Can I send you a mail to the addr mentioned here:
https://github.com/iyanmv

Here it is. Ignore the warning about NetworkManager, I added the wireless device on /etc/NetworkManager/conf.d/unmanaged.conf
# ./hcxdumptool -i wlp0s20f3 -C
initialization of hcxdumptool 6.2.5-6-g5739c87...
warning possible interfere: NetworkManager is running with pid 20254

wlp0s20f3 available frequencies, channels and tx power reported by driver:
2412MHz   1 (-2147483648 dBm)
2417MHz   2 (-2147483648 dBm)
2422MHz   3 (-2147483648 dBm)
2427MHz   4 (-2147483648 dBm)
2432MHz   5 (-2147483648 dBm)
2437MHz   6 (-2147483648 dBm)
2442MHz   7 (-2147483648 dBm)
2447MHz   8 (-2147483648 dBm)
2452MHz   9 (-2147483648 dBm)
2457MHz  10 (-2147483648 dBm)
2462MHz  11 (-2147483648 dBm)
2467MHz  12 (-2147483648 dBm)
2472MHz  13 (-2147483648 dBm)
5200MHz  40 (-2147483648 dBm)
5220MHz  44 (-2147483648 dBm)
5240MHz  48 (-2147483648 dBm)
5260MHz  52 (-2147483648 dBm)
5280MHz  56 (-2147483648 dBm)
5300MHz  60 (-2147483648 dBm)
5320MHz  64 (-2147483648 dBm)
5600MHz 120 (-2147483648 dBm)
5620MHz 124 (-2147483648 dBm)
5640MHz 128 (-2147483648 dBm)
5660MHz 132 (-2147483648 dBm)
5680MHz 136 (-2147483648 dBm)
5700MHz 140 (-2147483648 dBm)
5720MHz 144 (-2147483648 dBm)
5745MHz 149 (-2147483648 dBm)
5765MHz 153 (-2147483648 dBm)
5785MHz 157 (-2147483648 dBm)
5805MHz 161 (-2147483648 dBm)
5825MHz 165 (-2147483648 dBm)

terminating...

BTW:
Can I send you a mail to the addr mentioned here:
https://github.com/iyanmv

Sure!

Thanks.
Many ioctl() system calls give incorrect values or no values.
More and more it looks like the driver need NETLINK to work as expected.

With NETLINK I see that a few more channels appear now (e.g. 36, 100, 104), but some are still missing (e.g. 38, 54). Can this be caused by some regdomain issues?
# ip link set wlp0s20f3 down
# iw wlp0s20f3 set type monitor
# ip link set wlp0s20f3 up
# ./hcxdumptool -i wlp0s20f3 -C
initialization of hcxdumptool 6.2.5-6-g5739c87...
warning possible interfere: NetworkManager is running with pid 634

interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
wlp0s20f3 available frequencies, channels and tx power reported by driver:
2412MHz   1 (-2147483648 dBm)
2417MHz   2 (-2147483648 dBm)
2422MHz   3 (-2147483648 dBm)
2427MHz   4 (-2147483648 dBm)
2432MHz   5 (-2147483648 dBm)
2437MHz   6 (-2147483648 dBm)
2442MHz   7 (-2147483648 dBm)
2447MHz   8 (-2147483648 dBm)
2452MHz   9 (-2147483648 dBm)
2457MHz  10 (-2147483648 dBm)
2462MHz  11 (-2147483648 dBm)
2467MHz  12 (-2147483648 dBm)
2472MHz  13 (-2147483648 dBm)
5180MHz  36 (-2147483648 dBm)
5200MHz  40 (-2147483648 dBm)
5220MHz  44 (-2147483648 dBm)
5240MHz  48 (-2147483648 dBm)
5260MHz  52 (-2147483648 dBm)
5280MHz  56 (-2147483648 dBm)
5300MHz  60 (-2147483648 dBm)
5320MHz  64 (-2147483648 dBm)
5500MHz 100 (-2147483648 dBm)
5520MHz 104 (-2147483648 dBm)
5540MHz 108 (-2147483648 dBm)
5560MHz 112 (-2147483648 dBm)
5580MHz 116 (-2147483648 dBm)
5600MHz 120 (-2147483648 dBm)
5620MHz 124 (-2147483648 dBm)
5640MHz 128 (-2147483648 dBm)
5660MHz 132 (-2147483648 dBm)
5680MHz 136 (-2147483648 dBm)
5700MHz 140 (-2147483648 dBm)
5720MHz 144 (-2147483648 dBm)
5745MHz 149 (-2147483648 dBm)
5765MHz 153 (-2147483648 dBm)
5785MHz 157 (-2147483648 dBm)
5805MHz 161 (-2147483648 dBm)
5825MHz 165 (-2147483648 dBm)

terminating...

No, I don't think that it is related to the regulatory domain.
It should not happen that the driver reports different channels/frequencies depending on how the monitor mode was set:
less channels if monitor mode set by ioctl()
	iwr.u.mode = IW_MODE_MONITOR;
	if(ioctl(fd_socket, SIOCSIWMODE, &iwr) < 0)

versus set monitor mode by iw using NETLINK.

Can you please test hcxlabtool which use NL80211 and RTNETLINK instead of WIRELESS EXTENSIONS):
https://github.com/ZerBea/wifi_laboratory
$ make
$ ./hcxlabtool -I interfacename
Thanks.

$ ./hcxlabtool -I wlp0s20f3

available wlan devices:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0   2 0456e5e5c112 0456e5e5c112 + wlp0s20f3        iwlwifi (NETLINK & WIRELESS EXTENSIONS)

+ monitor mode available
- no monitor mode available

available frequencies: frequency [channel] tx-power
  2412 [  1] 22.0 dBm     2417 [  2] 22.0 dBm     2422 [  3] 22.0 dBm     2427 [  4] 22.0 dBm
  2432 [  5] 22.0 dBm     2437 [  6] 22.0 dBm     2442 [  7] 22.0 dBm     2447 [  8] 22.0 dBm
  2452 [  9] 22.0 dBm     2457 [ 10] 22.0 dBm     2462 [ 11] 22.0 dBm     2467 [ 12] 22.0 dBm
  2472 [ 13] 22.0 dBm     2484 [ 14] disabled     5180 [ 36] 22.0 dBm     5200 [ 40] 22.0 dBm
  5220 [ 44] 22.0 dBm     5240 [ 48] 22.0 dBm     5260 [ 52] 22.0 dBm     5280 [ 56] 22.0 dBm
  5300 [ 60] 22.0 dBm     5320 [ 64] 22.0 dBm     5340 [ 68] disabled     5360 [ 72] disabled
  5380 [ 76] disabled     5400 [ 80] disabled     5420 [ 84] disabled     5440 [ 88] disabled
  5460 [ 92] disabled     5480 [ 96] disabled     5500 [100] 22.0 dBm     5520 [104] 22.0 dBm
  5540 [108] 22.0 dBm     5560 [112] 22.0 dBm     5580 [116] 22.0 dBm     5600 [120] 22.0 dBm
  5620 [124] 22.0 dBm     5640 [128] 22.0 dBm     5660 [132] 22.0 dBm     5680 [136] 22.0 dBm
  5700 [140] 22.0 dBm     5720 [144] 22.0 dBm     5745 [149] 22.0 dBm     5765 [153] 22.0 dBm
  5785 [157] 22.0 dBm     5805 [161] 22.0 dBm     5825 [165] 22.0 dBm     5845 [169] disabled
  5865 [173] disabled     5885 [177] disabled     5905 [181] disabled

bye-bye

Great, thanks. Now hcxlabtool should work on this driver.
BTW:
This "5905 [181] disabled" is related to your wireless regulatory domain settings.
https://github.com/aircrack-ng/aircrack-ng/discussions/2430#discussioncomment-5023204

Great! And what about hcxdumptool?

hcxdumptool is a dinosaur (due to WIRLESS EXTENSION dependency) and it is acting like a toothless tiger (too many features that slow it down).
hcxlabtool will be the successor due to full NETLINK/RTNETLINK support. With hcxlabtool I'm going back to the roots and set focus on ultra fast and effective layer 2 attack vectors.
Simply run
$ hcxlabtool
and see what will happen.

Hi @ZerBea
I missed your last comment on the kernel bugzilla but I have just tried version 6.3.0 (which I think it includes the changes to NL80211) and I can still crash my laptop.
What else do you suggest me to try? Should I continue the conversation in the kernel bug now that you have removed WEXT completely?

SInce v6.3.0 WEXT is completely removed and replaced by RTNETLINK and NL80211 (as suggested by the iwlwifi driver maintainer).
According to this
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi
packet injection is not mentioned (only sniffer mode).
or this
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_the_monitorsniffer_mode
"This will put lots of pressure on the memory subsystem, but it will allow you to hear 12K long packets. You may see firmware crashes in case you didn't set that module parameter. "
and this
https://www.intel.com/content/www/us/en/support/articles/000058933/wireless/intel-wireless-ac-products.html
it looks like this chipset/driver is not the best choice to be used as a penetration testing device.
BTW:
There are a lot of problems with this chipset:
https://duckduckgo.com/?q=ax201+crash&t=ffab&ia=web
I think it is the best to do the conversion on bugzilla, because there is nothing I can do.
MediaTek, Ralink, Realtek and Atheros drivers are working fine, so I still suspect an iwlwifi driver issue.

https://github.com/ZerBea/hcxdumptool/commit/4ba9d5bad5dd48e77532d22243d2e57d02a4d6fb

Bugzilla report:
https://bugzilla.kernel.org/show_bug.cgi?id=217051


New option: --openai.apibase [$OPENAI_API_BASE]

OpenAI integration can be activated by specifying --openai.apibase, even without the --openai.token, since some services may function without an API key (token).
Additionally:

Updated the default model to gpt-4o-mini.
Corrected several typos in the README.

Please ignore any changes that are not directly relevant.

[!WARNING]
As I am not a Go programmer, please ensure that the suggested changes are correct.

@georg3k
Right, and not only selfhosted.


Refactored registration

Significant refactoring of registration methods based on offline discussions with @broxtronix and @poolio and Noah (@d-v-b might be interested as well).
The key change is to separate the application and estimation of registration parameters through a new RegisterModel class. Performing registration will return an instantiation of this class, and it has a transform method for applying the transformations to an Images object. This makes it simple to compute parameters on one data set and apply them to another, which was previously difficult.
Other features for improved modularity and extensibility

Support simple saving / loading of registration models to / from JSON
Separate particular registration implementations into modules within an imgprocessing.regmethods package
Provide simpler constructor interface through a Register class that is separate from the base class RegisterMethod
A new run method on registration methods combines the fit and transform into a single step, which can be more efficient, and matches the old behavior, but does not expose the transformation parameters directly

Example usage

Compute parameters on one data set and apply to another

from thunder import Register

images1 = tsc.loadExample('fish-images')
images2 = images1.medianFilter(2)
ref = images2.first()[1]

model = Register('crosscorr').fit(images2, ref)
alginedimages = model.transform(images1)

Perform registration in one step

from thunder import Register

images1 = tsc.loadExample('fish-images')
ref = images1.first()[1]

alignedimages = Register('crosscorr').run(images1, ref)

Save registration model to JSON

from thunder import Register

images1 = tsc.loadExample('fish-images')
ref = images1.first()[1]

model = Register('crosscorr').fit(images1, ref)
model.save('/tmp/file.json')

model = Register.load('/tmp/file.json')

Hi Jeremy,
Thanks for putting this together! I had a handful of inline comments, and also wanted to discuss the structure of the RegisterMethod class. The current setup requires the user to compute a reference and pass that into getTransform(). What about having the ref be a class variable of RegisterMethod and broadcasting that entire RegisterMethod object. So something like:
reg = Register('crosscorr')
reg.fitReference(images)
model = reg.fit(images)

where we would have:
def fit(images):
  ...
  reg_bc = images.rdd.context.broadcast(self)
  transformations = images.rdd.mapValues(lambda im: reg_bc.value.getTransform(im)).collectAsMap()

This would let the user store more complicated information in the RegisterMethod object that may be needed by getTransform().
Minor comment -  how do you feel about changing Register to Registration?

Thanks for the review @poolio ! Great suggestions. I really liked idea of making the reference a class attribute of the registration method, I've gone ahead and made that change. I made sure that the fitReference returns self, to make it easy to chain methods, as in:
model = Register('crosscorr').fitReference(images).fit(images)
newimages = Register('crosscorr').fitReference(images).run(images)

I also added a setReference method in case the user wants to provide a reference as an array directly (which seems like to happen sometimes). And I'm happy renaming register -> registration.
The issue of using numpy arrays for the delta, and whether and how to generalize the serialization handling, are actually related and require some thought. Let's discuss that one over coffee today =)

After a final offline discussion / review with @poolio and @broxtronix , going to merge this in.


offsetItem undefined when rendering cement

Describe the bug
Getting this error Uncaught (in promise) TypeError: Cannot read property 'diameter' of undefined when trying to render a spesific combination of hole/casing/cement. I have created a branch that can be checked out to reproduce error.
To Reproduce
Steps to reproduce the behavior:

Checkout https://github.com/ooystein/esv-intersection/tree/issue-cement-offsetItem
Run storybook
Visit intersection story http://localhost:6006/?path=/story/intersection--intersection
See error in console

Expected behavior
Well design rendered
Actual behavior
Error
Desktop (please complete the following information):

OS: Linux
Browser Chrome

I tested this data on most recent master and the issue seems to be fixed!


Move ShutdownRequest to trinity.extensibility.events

What was wrong?
This is a small architectural cleanup that I just became aware of. The ShutdownRequest was introduced at trinity.events. However, I believe it is more appropriate for that to live under trinity.extensibility.events.
Reasoning:
Imagine we would rip the whole trinity.extensibility system out of Trinity to be used in other projects (No plans for that, just hypothetically!). A plugin would still be able to call self.context.shutdown_host() as it pretty much has the same meaning no matter if we are talking about the plugin system within Trinity or within a different app that uses that plugin system.
Hence, it makes more sense to have the ShutdownRequest event be part of trinity.extensibility.events as opposed to trinity.events.
In general, the less trinity.extensibility imports from outside of that namespace, the more generic it remains. While I'm not advocating for making our live harder by trying to build a generic plugin mechanism aimed to become a standalone project, at the same time I see no reason to artificially increase coupling when it isn't needed.
How was it fixed?
Moved class.
Cute Animal Picture

Mmh..the other events that are related to the plugin manager do also live in trinity.extensibility.events e.g. TrinityStartupEvent. Today, these have different base events but long term they will probably all come through the event bus.
Anyway, if nobody is convinced...BOOOO....closing.


Revert reversion of blitz changes

This includes the changes that were done in the blitz (2017), both those that were reverted after being merged in to master, and some unmerged changes.
To avoid any issues relating to the interface, an additional change has been added that restricts using the new functionality to users with a advanced_options permission, both in terms of making requests, and approving requests.

@chao-xian The tests were indeed not passing, but I've now fixed the issues :)

@chao-xian Your addition looks great :+1:


Updates for spree 3.0.0

LGTM and specs are green -- awesome work! Merging to master and 3-0-stable. :+1: :beers:

Nice work @AlessioRocco!

@brchristian @onedanshow thanks :+1:


"files_insert_input" vs "storage_files_insert_input"

Hi, thanks for providing nhost/hasura-storage and support! I'm kind of lost with this error though. I have upgraded from nhost/hasura-storage:0.3.6 (everything was working fine) to v0.6.1 and now I'm getting 403's when uploading files.
I have allowed roles "user" and "editor" to select the new field "metadata" and there is an ENV var "S3_ENDPOINT" as mentioned in the release notes. It was there all along.
This is the request I'm doing -- there is nothing particularly interesting about it, it has worked with v0.3.6:
curl 'https://example.com/v1/files' -X POST -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0' -H 'Accept: */*' -H 'Accept-Language: de,de-DE;q=0.8,en-US;q=0.5,en;q=0.3' -H 'Accept-Encoding: gzip, deflate, br, zstd' -H 'Referer: https://another.example.com/' -H 'Authorization: Bearer TOKEN' -H 'x-hasura-role: admin' -H 'Content-Type: multipart/form-data; boundary=---------------------------286635652437818198363019706553' -H 'Origin: https://another.example.com' -H 'DNT: 1' -H 'Sec-GPC: 1' -H 'Connection: keep-alive' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: cross-site' -H 'Priority: u=4' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' --data-binary $'-----------------------------286635652437818198363019706553\r\nContent-Disposition: form-data; name="file[]"; filename="filename.jpg"\r\nContent-Type: image/jpeg\r\n\r\n-----------------------------286635652437818198363019706553--\r\n'

The TOKEN is valid, that's the same I'm using for Hasura.
With nhost/hasura-storage:0.6.1 response is a HTTP status 403:
{"error":{"message":"you are not authorized"}}

Container log shows this:
time="2024-10-07T19:15:45Z" level=error msg="call completed with some errors"
client_ip=<IP_ADDRESS> errors="[problem processing request: problem initializing file
metadata: {\"networkErrors\":null,\"graphqlErrors\":[{\"message\":\"variable 'object'
 is declared as 'files_insert_input!', but used where 'storage_files_insert_input!'
is expected\",\"extensions\":{\"code\":\"validation-failed\",\"path\":
\"$.selectionSet.insertFile.args.object\"}}]}]" latency_time=16.546408ms method=POST
status_code=403 url=/v1/files

The file is not persisted in table "files" and the request does not even get passed through to S3/Minio.
I have manually tried to issue the mutation in Hasura as follows:
mutation InsertFile($object: files_insert_input!) {
  insertFile(object: $object) {
    id
  }
}

Query variables:
{
  "object": {
    "name": "example_file.txt",
    "bucketId": "default",
    "mimeType": "text/plain",
    "size": 2048
  }
}

I'm getting the same error ("variable 'object' is declared as 'files_insert_input!', but used where 'storage_files_insert_input!' is expected").
When I change files_insert_input to storage_files_insert_input it is working however, the record gets persisted.
Now, my question is why InitializeFile is using files_insert_input instead of storage_files_insert_input and what can I do to make it work? Thanks in advance!

Hello,
thanks for your message. It is using files_insert_input because that's the type name the service expects and that always expected. My guess is you modified the metadata in hasura and changed something that hasura-storage doesn't understand. Most likely by configuring the prefix "storage" to the schema. Otherwise, please, provide a minimal docker-compose file that reproduces the issue so we can take a look.


Week 1 Review Ticket

Peer Grade:
Graded By:
GitHub Pages

Overall: 4.75/5
Team

[ ] 1/1 - Scrum Team GitHub

Individual

[ ] 1/1 - GitHub review page contains code snippets
[ ] 0.75/1 - Code contains Linked Lists but Generic T is not described on pages
[ ] 1/1 - Code shows Queue Add and Delete
[ ] 1/1 - Code shows merging of 2 Queues
[ ] 1/1 - Reverse order operation is shown


Index Optimize Error on AWS RDS Instances

Receiving this error when attempting to run Index Optimize on AWS RDS.  The issue is the table is in the rdsadmin database which we do not have permissions to. "Cannot find the object "dbo.log_backup_manifest" because it does not exist or you do not have permissions."
SQL Server 2014 Standard Edition on AWS RDS
Execute SELECT @@VERSION
The latest Maintenance Solution Script
Check the header of the stored procedure
Starting the Index Optimize job through SQL Agent
Cannot find the object "dbo.log_backup_manifest" because it does not exist or you do not have permissions.

In MaintenanceSolution.sql, where the job 'IndexOptimize - USER_DATABASES' is created,
it is missing the test for @AmazonRDS = 1 which would have added the '-rdsadmin' to the @Databases parameter.
I modified my job definition as listed below to fix the issue
EXECUTE [dbo].[IndexOptimize]
@Databases = 'USER_DATABASES, -rdsadmin',
@LogToTable = 'Y'


Flutter , Visual Code Analyzer never finishing after update

After update dart extension analyzer never ending.So , autocomplete and other things does not work.How can i fix that ?
Launch Json :
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [

        {
            "name": "Flutter",
            "request": "launch",
            "type": "dart"
        }
    ]
}

Flutter Version : 1.6.6

Please provide flutter doctor -v output. May it be possible that you opened vscode while Dart was still upgrading? Is it so only on the specific project? Can you provide your VSCode version and dart extension version? Did you tried to reinstall dart and flutter extensions?
More info is needed to investigate the issue.

@BondarenkoStas Here is the flutter doctor -v output ss

I tried different project the some issues in all projects

@merdo988 I opened your project having the same versions of VS Code, flutter extension etc, but couldn't reproduce the issue. I would be hard to investigate without having exact steps to reproduce. Anyway, keeping it open. Please asks for help in StackOverflow as well or check https://flutter.dev/community for support options, probably the issue is not related to flutter itself but to your custom configuration.

@merdo988 are there any updates about your issue?

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact descriptions what happens, logs and the output of ' flutter doctor -v'  please.
All system setups can be slightly different so its always better to open new issues and reference related issues.


add haiku support

hello,
this adds haiku support per #119. if there is a more idiomatic way to handle this, would be open to suggestions.
the following shows a run of the unit tests  (after successful compilation) in which currently only one test doesn't pass.  my guess is that this test for haiku can probably be suppressed as it is unclear if datagram over unix sockets in haiku is currently available.
thanks!
> uname -a
Haiku shredder 1 hrev55602 Oct 29 2021 07:10:38 x86_64 x86_64 Haiku

> cargo test
  Downloaded proc-macro2 v1.0.33
  Downloaded 1 crate (41.0 KB) in 0.51s
   Compiling proc-macro2 v1.0.33
   Compiling syn v1.0.82
   Compiling smallvec v1.7.0
   Compiling instant v0.1.12
   Compiling parking_lot_core v0.8.5
   Compiling parking_lot v0.11.2
   Compiling quote v1.0.10
   Compiling serial_test_derive v0.5.1
   Compiling serial_test v0.5.1
   Compiling signal-hook v0.3.12 (/boot/home/src/git/rust-libs/signal-hook)
    Finished test [unoptimized + debuginfo] target(s) in 1m 09s
     Running unittests (target/debug/deps/signal_hook-dcf2f73007120844)

running 11 tests
test flag::tests::register_unregister ... ok
test low_level::channel::tests::multi_thread ... ok
test low_level::channel::tests::multiple ... ok
test low_level::channel::tests::new_empty ... ok
test low_level::channel::tests::overflow ... ok
test low_level::channel::tests::pass_value ... ok
test low_level::pipe::tests::register_dgram_socket ... FAILED
test low_level::pipe::tests::register_with_pipe ... ok
test low_level::pipe::tests::register_with_socket ... ok
test low_level::signal_details::test::existing ... ok
test low_level::signal_details::test::unknown ... ok

failures:

---- low_level::pipe::tests::register_dgram_socket stdout ----
Error: Os { code: -2147454955, kind: Uncategorized, message: "Address family not supported by protocol family" }
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`: the test returned a termination value with a non-zero status code (1) which indicates a failure', /mnt/d/Rust/rust-x86/library/test/src/lib.rs:194:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Hello
Have you tried the way with introducing an alias?
As for the pull request:

Can the omission be done on single import item/one macro invocation instead? Something like: pub use libc::{..., #[cfg(not(target_os = "haiku"))] SIGIO, ...}? A completely different list is for windows because it's very different, but here it is similar. Or maybe pull it out, eg: use libc::{most of the signals}; #[cfg(not(haiku))] use libc::SIGIO?
As for the failing test… I'm OK with skipping it, but it would be nice to verify that it's not really supported or check what's happening.

Codecov Report

Merging #127 (a403f90) into master (53a2334) will increase coverage by 0.52%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #127      +/-   ##
==========================================
+ Coverage   69.10%   69.63%   +0.52%
==========================================
  Files          16       16
  Lines         764      764
  Branches      122      122
==========================================
+ Hits          528      532       +4
+ Misses        141      136       -5
- Partials       95       96       +1

Impacted Files
Coverage Δ

src/lib.rs
88.23% <ø> (ø)

src/low_level/signal_details.rs
17.50% <ø> (ø)

signal-hook-registry/src/half_lock.rs
81.66% <0.00%> (+6.66%)
:arrow_up:

thanks for the comments. i am not sure how to approach the suggestion for alias without a more concrete example but can research it for the future.
i was not sure if the omission as you suggested would work but tried it out and looks like it works as hoped. thanks! i have pushed up a change that i hope looks a bit cleaner.
i did a check for datagram support for unix sockets and am rather sure that this is not a supported configuration in haiku so went ahead and disabled that test only for haiku.  see an excerpt below that i hope helps explain:
> cat main.c

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>

#define SOCK_PATH "socket_test_filename"

int main(void)
{
    int s, len;
    struct sockaddr_un local;
    char str[100];

    if ((s = socket(AF_UNIX, SOCK_DGRAM, 0)) == -1) {
        perror("socket");
        exit(1);
    }

    return 0;
}

> gcc -o sockettest main.c -lnetwork
> ./sockettest
socket: Address family not supported by protocol family

Thank you. I'm going to make a release soon.


Ss/native button

This adds a native button with event handler @button_click.
Currently only accepts a "label" String property and a "style" TextStyle property, to be extended in the future.

Thanks for the feedback! :)

LGTM! Good work


fix site documentation to add missing nav links - issue 640

Issue #640 :
Description of changes:
Added missing navigation links as mentioned in the issue description.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@ratnopamc Addons Overview table page  is missing following addons. Can you fix that too pls.

kasten-k10.md
keda.md
kube-state-metrics.md
kubeflow.md
prometheus-node-exporter.md
upbound-universal-crossplane.md
Once that is fixed. I can republish. With current version i can still see your changes - https://aws-quickstart.github.io/cdk-eks-blueprints/ Nice work.

@shapirov103 The changes look good to me and aligns to the issue #640 .
I also went ahead and published the web documentation and everything looks good to me. Also the Addons Overview table is also updated - https://aws-quickstart.github.io/cdk-eks-blueprints/addons/
Please merge this PR.


Compatibility needs to be verified on other platforms

I've only tested Maui on macOS (ARM64). Other computers exist; Maui should probably be able to run on them as well.

I can help with this.


dev version test bugs

Seems to be mostly working. Seems like
Hit some other small issues as well
initial frame seems to succeed but hits an error at the end(I was still able to execute followup cells fine)

Non-api failures

Default params cell

This doesn’t seem to cause issues but an error

1-4 not 1-5

got this error when I only had one scene prompt, fixed with multiple

thanks! i'll take a look

ok try it now


[BUG] Connection dialog v2: 'authentication' drop-down does not respect 'default-value' property.

Describe the bug
When defining the 'authentication' field as a drop-down with a default value, the field remains empty by default:
    <field name="authentication" label="Authentication mode" category="authentication" value-type="selection" default-value="auth-pass">
        <selection-group>
            <option label="Password" value="auth-pass"/>
            <option label="Username/Password" value="auth-user-pass" />
        </selection-group>
    </field>

When using any other field name it does work as expected:
    <field name="v-test-field" label="Authentication mode" category="authentication" value-type="selection" default-value="auth-pass">
        <selection-group>
            <option label="Password" value="auth-pass"/>
            <option label="Username/Password" value="auth-user-pass" />
        </selection-group>
    </field>

Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: MacOS
Tableau Version 2020.3

About you:
Name: Christian Stuart
Company: Databricks

Can no longer reproduce. I possibly had an invalid value cached.


Redirect HTTP to HTTPS

There is code in place for this, but it doesn't seem to function properly. Tested in both chrome and firefox.

Nothing to see here...


Remove IRC resource

Is anyone still using the IRC bots? If not, we should consider removing it to improve overall
server performance.

@EsDeKa @Bierbuikje Thoughts?

If it improves the server we should do it, it is rarely used since we have the discord bots.

If it "eats" a lot of performance then yeah it should be removed. Anyways no one using it I guess

Actually the discord resource is using the irc resource for its commands,
so it can't really be removed until the commands are moved to discord then
On 21 Dec 2017 11:31, "Jarno"<EMAIL_ADDRESS>wrote:

Closed #359
https://github.com/JarnoVgr/Mr.Green-MTA-Resources/issues/359 via
296b46c
https://github.com/JarnoVgr/Mr.Green-MTA-Resources/commit/296b46c93179f01bffefe00a782d6bfe6588d9cb
.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JarnoVgr/Mr.Green-MTA-Resources/issues/359#event-1397727599,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADbBOZtUMfcViG98siM52uC8qUbGvDm1ks5tCjN4gaJpZM4RIxd3
.

Oops

Wait what. That wasn't something I'd expect.
I've made #361


Does this support FeatureServer ?

Just hangs on trying this.. Is it beacuse this is a FeatureServer. Your examples all have MapServer in them.
Thanks
shapefile-ags https://services1.arcgis.com/XXXXX/arcgis/rest/services/Assessment/FeatureServer/0/query --file-name='LA.zip'

FeatureServers seem to be working for me. It looks like you've added /query to the end of the URL. It might work if you take that out.


Validation issue

Hi!
First a big thanks for your code, i got it work at the first try!
I have notice that the field validation does not work as expected on the email field.
I have set it up here:
http://www.prettynaive.com/form/index.php
Thanks for your help!
Cheers!

Hello, thanks for the comment. I actually put this up a long time ago and will not have time to look into the issue for a while. Newer options are likely available on Github that have a recent Bootstrap version. I probably should make this read only...

Ok, I will try to get it work. Thanks again for your time, and your work! Cheers!


Share feature broken in Android O beta

Share feature is broken in the Android O beta release. Needs to be fixed.

Fixed in beta stream. Needs a production release. Damn Android O really speeds up performance


Cedar/IPC: Fix MAC address for IPv4 multicast

Per RFC 1112, Ethernet multicast address should be in the form of 01-00-5E-00-00-00, where the lowest 23 bits are copied from the destination IP.
Since multicast is currently treated as broadcast, this commit does not actually fix anything but may help reducing broadcast traffic.

Changes proposed in this pull request:

Change destination MAC address for IPv4 multicast per RFC 1112

There are several approaches to multicast Mac.
To make things clear, can you also add inline comment with rfc?

Comments added.
Sorry I am not aware of other approaches. What I can see is this format is very widely used.

Thank you very much for your contribution!


[Feature] Support primary key replicated storage

What type of PR is this：

[ ] BugFix
[x] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

[FE PR Coverage Check]
:disappointed: fail : 2 / 3 (66.67%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/task/StreamLoadTask.java
2
3
66.67%
[262]

[FE PR Coverage Check]
:disappointed: fail : 2 / 3 (66.67%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/task/StreamLoadTask.java
2
3
66.67%
[262]

[FE PR Coverage Check]
:disappointed: fail : 2 / 3 (66.67%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/task/StreamLoadTask.java
2
3
66.67%
[262]

[FE PR Coverage Check]
:disappointed: fail : 2 / 3 (66.67%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/task/StreamLoadTask.java
2
3
66.67%
[262]

run starrocks_admit_test

if replicated storage is turn on for primary table by default, shuffle service for stream load and broker load should be disabled

run starrocks_admit_test

run starrocks_fe_unittest

[FE PR Coverage Check]
:disappointed: fail : 2 / 3 (66.67%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/task/StreamLoadTask.java
2
3
66.67%
[262]

run starrocks_admit_test

run starrocks_admit_test


adt(doc): specify code snippet language

The bug that caused code snippets in doc comments to not show up with code coloring for the type of language has been fixed.
This updates our doc comment code tags to specify the language as csharp.
All SDK Contribution checklist:
This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] Please open PR in Draft mode if it is:

Work in progress or not intended to be merged.
Encountering multiple pipeline failures and working on fixes.

[ ] If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
[x] I have read the contribution guidelines.
[x] The pull request does not introduce breaking changes.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

SDK Generation Guidelines

[ ] The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as the commitid of your swagger spec or link to the swagger spec, used to generate the code. (Track 2 only)
[ ] The *.csproj and AssemblyInfo.cs files have been updated with the new version of the SDK. Please double check nuget.org current release version.

Additional management plane SDK specific contribution checklist:
Note: Only applies to Microsoft.Azure.Management.[RP] or Azure.ResourceManager.[RP]

[ ] Include updated management metadata.
[ ] Update AzureRP.props to add/remove version info to maintain up to date API versions.

Management plane SDK Troubleshooting

If this is very first SDK for a services and you are adding new service folders directly under /SDK, please add new service label and/or contact assigned reviewer.

If the check fails at the Verify Code Generation step, please ensure:

Do not modify any code in generated folders.
Do not selectively include/remove generated files in the PR.
Do use generate.ps1/cmd to generate this PR instead of calling autorest directly.
Please pay attention to the @microsoft.csharp version output after running generate.ps1. If it is lower than current released version (2.3.82), please run it again as it should pull down the latest version.

Note: We have recently updated the PSH module called by generate.ps1 to emit additional data. This would help reduce/eliminate the Code Verification check error. Please run following command:
  `dotnet msbuild eng/mgmt.proj /t:Util /p:UtilityName=InstallPsModules`

Old outstanding PR cleanup
Please note:
If PRs (including draft) has been out for more than 60 days and there are no responses from our query or followups, they will be closed to maintain a concise list for our reviewers.

This should be fixed globally here:
https://github.com/Azure/azure-sdk-for-net/blob/e00810bd3db3062d13965e4f6806c812775aa246/eng/SnippetGenerator/CSharpProcessor.cs#L14

This should be fixed globally here:
https://github.com/Azure/azure-sdk-for-net/blob/e00810bd3db3062d13965e4f6806c812775aa246/eng/SnippetGenerator/CSharpProcessor.cs#L14

I don't know how that file is used. In our case, we had to manually add the <example> and <code> tags to these locations in our API surface.
@pakrym do you have advice here on how this could be fixed globally?

After talking with @pakrym, we'll merge this to confirm it fixes the web docs code sample style there. Then we'll address the snippet generator to not skip over example tags written this way, and even look at have it automatically add the language property when not present.


File is MISSING

fragments.APIService file is missing
and also activity_forget_password layout,
Please provide it

I'll try to update the code soon. Hope that helps.

Hello Gops0,
I have updated the code with the required files. Hope it helps.

Thanks bro.


Clear example with top-level Redux connect

I'm struggling to work out how to access redux state from a connected component's props, using the top level method connecting it to the Router.
I'd like to avoid using multiple connects, as the Redux docs state:

Try to only do this for a top-level component, or route handlers

I'm refactoring some code using NavigatorIOS and was previously passing the necessary props using passProps. I can't see an equivalent - I guess that happens behind the scenes with connect? Or do I need to connect each Route's component?

Think I found some good advice on #56
Still would be good to have clearer example I think.

Feel free to submit PR for improving documentation. Btw, there is quite large discussion at redux github about having only one connect for top-level component, and i don't agree with this sentence.


ViewModel and UIKit

Should viewModel import framework that exposes UIKit like RxCocoa? Maybe it's better to expose input/output as Observable's and convert them to Driver in viewController implementation where it's legit to import RxCocoa?

Hi, @IvanKalaica! Yeah, I've heard quite a lot people saying that ViewModel should be platform agnostic e.g in case you would want to make a MacOS app, but IMHO this is not possible ¯_(ツ)_/¯
And regarding Input/Output approach, at the moment I'm not sure if it's visible solution in more complex examples. We recently started to use RxFeedback in our app and we are very happy =)

Yeah, I also use RxFeedback also in my projects inside ViewModel with input/output as Observables. Currently this doesn't make sense since RxFeedback imports RxCocoa. It would be good if I can import just a Observable RxFeedback. Then it's possible to have platform agnostic ViewModel.

How do you work with UIImage for example?

I would expose var imageData: Observable<Data?>in ViewModel and convert it on async scheduler to format I need (UIImage) where I need it (cell or viewController) usually.

IMHO it violates original design idea ¯_(ツ)_/¯

The view model then provides data from the model in a form that the view can easily use.

from here

Yeah, I know and I agree. :)
I think UIImage is only data type for which I had to make such transformation outside ViewModel.
IMHO it's small price to pay considering the benefits.

and UIFont, UIColor... I think the price raises as time passes. :)


Properly handle POST binding for SAML logout response

I have a SAML SP (pac4j app) integrated via the SAML protocol with a CAS server.
I define the POST binding for the SAML logout responses:
cas.authn.saml-idp.logout.logout-response-binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

For the redirect binding, it is considered front channel and at the end of the logout process, the user is redirected to the SP with the SAML logout response.
For the post binding, it is considered back channel and the CAS server directly calls the SP with the SAML logout response and display its logout page at the end of the logout process.
This PR changes this behavior to consider the POST binding as a front channel communication. Thus, no direct call is made by the CAS server to the SP. At the end of the logout process, an HTTP POST is made to the SP with the RelayState and SAMLResponse parameters.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I don't think this is correct.

Thus, no direct call is made by the CAS server to the SP.

This cannot happen. If you have established SSO sessions with 11 SPs, this PR breaks logout for all of them, except the last one. We also cannot change the behavior, as it would break many many many SPs.
A POST logout is always a back-channel logout. If you need to, you can either use redirect, or redirect to something at the end of the logout process, or do custom work. The changes here cannot be accepted as they are.

We have two things here:

the SAML logout requests sent to the SPs for logout
the final SAML logout response returned to the original SP SAML logout request.

The SAML logout requests are always sent (CAS logout) but the SAML logout response is only sent when there was an original SAML logout request.
The SAML logout requests are sent back channel (whether it is a redirect or a POST). It happens in the SamlIdPSingleLogoutServiceMessageHandler. There is more to discuss here but leave that aside for now.
The SAML logout response is sent front channel for the redirect binding and back channel for the POST binding. It happens in the SamlIdPSingleLogoutRedirectionStrategy.
This PR does not change the behavior related to the SAML logout requests, this will work as before. It only changes the behavior for the SAML logout response in POST binding which happens after the SAML logout requests have been sent.
Does that make sense?

Ah, thank you. That makes sense. So you're still doing the POST for the logout response; you're just doing it in the end as a POST from the browser. Sure, I am perfectly good with that.
Two things:

I think we need to make sure this PR has excellent test coverage, given it's a critical areas. Right now, it has no tests.
We also need at least one integration/puppeteer test to make sure the HTML pages you have added work correctly as much as possible

I was waiting for your feedback before working on tests ;-) I will do that now.

Thank you, sir. Let me know if I can help with anything.

I have added unit tests for the changes as well as 4 new puppeteer tests (covering old and new use cases).
We should be good for the merge.

I forgot to mention that I haven't found the old cas-build.yml file where all scenarios were defined. I guess there are automatically picked up now: am I right?

Thanks Jérôme. I'll take a look later in the week, but I am sure the changeset is fine.
And yes, the scenarios are picked up automatically. It was too much work to manually list and maintain them :)
https://apereo.github.io/cas/development/developer/Test-Process.html#browser--functional-testing (towards the end)

This was most excellent. Thanks much for working out the tests!

Thanks for the merge


populate-jbrowse2: add refNameAliases when available

Could the populate-jbrowse2 subcommand support  per-assembly refNameAliases file (like the jbrowse add-assembly --refNameAliases option: https://jbrowse.org/jb2/docs/cli/#jbrowse-add-assembly-sequence)?
I'm not entirely sure what the CLI would look like. One suggestion is perhaps populate-jbrowse2 --refNameAliases_dir=<path>, where <path> is a path to a directory of refNameAliases TSV files named, e.g., <name>.txt; for each reference assembly name that is encountered in the yml config files, if <path>/<name>.txt exists, then a refNameAliases property is added to the output config.json. Could be other ways to implement this too.

Thanks @nathanweeks and sorry for the delayed response. It's a good idea, my initial reaction is that we ought to have a standardized (but optional) file resident in the datastore that iff present autocontent would just pass along as a URL for the --refNameAliases option value. I think that's pretty similar to what you suggested, except that there would be no option on the populate-jbrowse2 subcommand, it would just make it happen depending on the state of the datastore content. Would that work for your intended uses?

PS. IIRC, you can have a single tab-delimited file with multiple aliases per record, but if that isn't the case having a directory for these files as you suggested might be needed


Add SVD file for the RP2040, from Raspberry Pi

This is a new chip from the Raspberry Pi Foundation, used in many boards from various vendors. For more information, see: https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-now-on-sale/
SVD file source: https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2040/hardware_regs
The license of the file is a typical BSD 2-clause license, so this SVD file is easy to use and distribute.

Thanks, was just reading up on the chip and was planning on adding this if it was not already present in a PR, thanks!

Thanks, was just reading up on the chip and was planning on adding this if it was not already present in a PR, thanks!


Team Communicator Author keeps failing to send to recipeients

Also when i try preview the message i keeping getting the following message
Ooops! An unexpected error seems to have occured. Why not try refreshing your page? Or you can contact your administrator if the problem persists.

@angelovithoulkas  If possible, could you share the failures logs/ stack trace from the Application Insights?


[vm] triggers assert !function.is_abstract() in precompiler

When using extension methods I hit an assert in the precompiler.
/=====================================================================\
| ffi/extension_methods_test is new and failed (Crash, expected Pass) |
\=====================================================================/

--- Command "vm_compile_to_kernel []" (took 01.000817s):
DART_CONFIGURATION=DebugX64 /b/s/w/ir/pkg/vm/tool/gen_kernel --aot --platform=out/DebugX64/vm_platform_strong.dill -o /b/s/w/ir/out/DebugX64/generated_compilations/dartkp/tests_ffi_extension_methods_test/out.dill /b/s/w/ir/tests/ffi/extension_methods_test.dart --packages=/b/s/w/ir/.packages -Ddart.developer.causal_async_stacks=true

exit code:
0

--- Command "precompiler" (took 05.000972s):
DART_CONFIGURATION=DebugX64 out/DebugX64/gen_snapshot --snapshot-kind=app-aot-assembly --assembly=/b/s/w/ir/out/DebugX64/generated_compilations/dartkp/tests_ffi_extension_methods_test/out.S --no-enable-malloc-hooks --ignore-unrecognized-flags --packages=/b/s/w/ir/.packages /b/s/w/ir/out/DebugX64/generated_compilations/dartkp/tests_ffi_extension_methods_test/out.dill

exit code:
-6

stderr:
../../runtime/vm/compiler/aot/precompiler.cc: 584: error: expected: !function.is_abstract()
version=2.6.0-edge.3637e780148fd88486747d9b95a377d7287e3b46 (Fri Sep 27 06:21:43 2019 +0000) on "linux_x64"
thread=13987, isolate=isolate(0x55b0e4828c00)
  pc 0x000055b0e29df30c fp 0x00007ffced898b50 dart::Profiler::DumpStackTrace(void*)
  pc 0x000055b0e2715ed2 fp 0x00007ffced898c30 dart::Assert::Fail(char const*, ...)
  pc 0x000055b0e2ac08ef fp 0x00007ffced898ca0 dart::Precompiler::ProcessFunction(dart::Function const&)
  pc 0x000055b0e2abc0a3 fp 0x00007ffced898cc0 dart::Precompiler::Iterate()
  pc 0x000055b0e2ab93d7 fp 0x00007ffced898e80 dart::Precompiler::DoCompileAll()
  pc 0x000055b0e2ab8e55 fp 0x00007ffced899260 dart::Precompiler::CompileAll()
  pc 0x000055b0e2f4605b fp 0x00007ffced899320 Dart_Precompile
  pc 0x000055b0e26eb252 fp 0x00007ffced8994b0 dart::bin::main(int, char**)
-- End of DumpStackTrace

--- Re-run this test:
python tools/test.py -n dartkp-linux-debug-x64 ffi/extension_methods_test

log, CL
@liamappelbe, you are working on supporting extension methods in the VM right? Though, I can also take a look if you'd like.
/cc @johnniwinther

@a-siva took over the extension methods stuff so I could focus on WASM

@dcharkes I don't see a test tests/ffi/extension_methods_test.dart  in the tree, should I looking elsewhere for the test.

It was a try job in https://dart-review.googlesource.com/c/sdk/+/118993/2.
However, many CFE changes have landed since, and the last try job is green: https://dart-review.googlesource.com/c/sdk/+/118993/5.
I'll close this issue. I'll reopen if I encounter it again.
@johnniwinther: You have not seen this assert pop up anymore as well?

I had seen the issue on a debug bot. When I looked recently the errors had gone, so it seems to have been fixed.


Since v0.11.0, Happy-DOM window/self/globalThis functions crash when not invoked with explicit 'this'

Describe the bug
Vitest v0.10.5 worked fine. This commit / PR introduced a bug:
https://github.com/vitest-dev/vitest/pull/1256/files
I am able to reproduce with Preact / Hooks, due to usage of requestAnimationFrame, cancelAnimationFrame etc. without explicit this binding (e.g. requestAnimationFrame() instead of self.requestAnimationFrame() or window.requestAnimationFrame()).
Specifically, the crash occurs here (this is undefined):
https://github.com/capricorn86/happy-dom/blob/ae900ea746126d04103f9fbaef044bc1a2a15bf5/packages/happy-dom/src/window/Window.ts#L489
My current workaround is to ensure the this binding in Vitest's beforeEach:
window.requestAnimationFrame = window.requestAnimationFrame.bind(window);
window.cancelAnimationFrame = window.cancelAnimationFrame.bind(window);

Reproduction
Simply invoke requestAnimationFrame() without explicit this binding in a Vitest test => crash.
System Info
System:
    OS: macOS 12.3.1
    CPU: (8) x64 Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
    Memory: 3.43 GB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.15.0 - /usr/local/bin/node
    Yarn: 1.22.5 - ~/.yarn/bin/yarn
    npm: 8.8.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 101.0.4951.54
    Firefox: 100.0
    Safari: 15.4
  npmPackages:
    vitest: ^0.11.0 => 0.11.0

### Used Package Manager

pnpm

### Validations

- [X] Follow our [Code of Conduct](https://github.com/vitest-dev/vitest/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [Contributing Guidelines](https://github.com/vitest-dev/vitest/blob/main/CONTRIBUTING.md).
- [X] Read the [docs](https://vitest.dev/guide/).
- [X] Check that there isn't [already an issue](https://github.com/vitest-dev/vitest/issues) that reports the same bug to avoid creating a duplicate.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/vitest-dev/vitest/discussions) or join our [Discord Chat Server](https://chat.vitest.dev).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

I think this PR introduced a bug: https://github.com/vitest-dev/vitest/pull/1258/files

Vitest v0.10.5 worked fine

Previous version also doesn't work for me. I think we always had this issue with happy-dom. Can you confirm?
See: https://stackblitz.com/edit/vitest-dev-vitest-9sqxn4?file=test/suite.test.ts

Thank you for the quick turnaround, @sheremet-va and @antfu :)
I look forward to trying out the next point release.

Vitest v0.10.5 worked fine

Previous version also doesn't work for me. I think we always had this issue with happy-dom. Can you confirm?
See: https://stackblitz.com/edit/vitest-dev-vitest-9sqxn4?file=test/suite.test.ts

The bug occurred at my end only when I switched from Vitest v0.10.5 to v0.11.0 (I use PNPM, so I was able to quickly run a regression test by re-installing all the dependencies from a fresh lockfile, using the two different versions of Vitest).
Note that unlike your StackBlitz repro, I do not have @vitest/ui and vite dependencies (just happy-dom 3.1.1). I use Preact with @testing-library/dom + @testing-library/preact (all on latest versions).


changes to optional use flite for image encoding

This adds the option to use the flitetranscoder support added to generator core. By default generate-assets does not use it. This can get override at a global level using a configuration json file with use-flite: trueand at the individual component level by plugins rendering components.

@chrisbank Looks good. Just 1 question about renderOnWorkerThread change.

LGTM.


Added extra exclamatory !

please review

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement
Learn more about why HashiCorp requires a CLA and what the CLA includes
Have you signed the CLA already but the status is still pending? Recheck it.

Looks good to me


Auto Connection With BLE

Is There any option to auto connect with specific Device when it disconnect..?

After disconnect RxBleDevice.establishConnection(true)?

Closing since there is no response for over a week. Best Regards.


Update spec to make range handling a viable solo option

Currently, the semantic tokens range protocol (3.17) is described as the following:

When a user opens a file it can be beneficial to only compute the semantic tokens for the visible range (faster rendering of the tokens in the user interface). If a server can compute these tokens faster than for the whole file it can provide a handler for the textDocument/semanticTokens/range request to handle this special case. Please note that if a client also announces that it will send the textDocument/semanticTokens/range server should implement this request as well to allow for flicker free scrolling and semantic coloring of a minimap.

The above makes it sound like range handling can only be used on file open. However, in Roslyn, we're planning on using range handling by itself instead of using all three of full/delta/range. This was found to be much more optimal perf-wise for us and is similar how local non-LSP Roslyn computes semantic tokens today. It would be nice if the spec could be updated to make range handling a viable option for editing.

Actually this shouldn't be a problem since we already have this in the spec: https://github.com/microsoft/language-server-protocol/blob/dc493ca1873940130e16b14687edd0da53b9b150/_specifications/specification-3-16.md#L7628


Back Rune / Divine Light

My Back Rune Divine Light can not be stored in a set.
It can also not be "Quick-applied" via right click.
It is also not warning me if this rune is missing (for other slots a warning is popping up, when no rune is applied).
It seems the addon does not recognize this rune as a back rune, as it was changed from Seal of Martyrdom rune.
Greets Antasilea

/dump C_Engraving.IsEquipmentSlotEngravable(INVSLOT_BACK)
returned: [1]=true
/dump #C_Engraving.GetRunesForCategory(INVSLOT_BACK, true)
returned: [1]=0
/dump C_Engraving.GetRuneForEquipmentSlot(INVSLOT_BACK)
returned:
[1]={
  equipmentSlot=16,
  learnedAbilitySpellIDs={
  [1]=458856
  },
  name="Divine Light",
  level=1,
  skillLineAbilityID=48633,
  iconTexture=135981,
  itemEnchantmentID=7562
}

when no Rune is engraved it returns: empty result
however it does not give the message that no rune is engraved when I equip a new cloak (but it does for other rune slots)

v1.3.0 might have fixed this mess.
I'll wait for some confirmation before I close the ticket.

No activity for a while, I'm going to assume it was fixed.


Charts: Reports via Jenkins plugin are brocken due to lack of security

To comply the security requirements no inline java-script  should be used  on the gatling report pages.
The solution mentioned in Jenkins-Wiki (to disable security policy - ' unsafe-inline') is not acceptable in most cases.
Suggested solution:

the dynamically generated javascripts  should be saved and included as an external script.
Although it does not provide full security (via hash or nonce) it allows to exclude most unsafe "inline script" case.

Related Links:

https://wiki.jenkins-ci.org/display/JENKINS/Gatling+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy#ConfiguringContentSecurityPolicy-DisableCSPforallPlugins
https://www.w3.org/TR/CSP2/#script-src-hash-usage
Document needed Content-Security-Policy Settings for Gatling Reports

AFAIK, the Jenkins team introduced this breaking change, without providing a proper workaround, just in case your Jenkins servers are not properly secured and someone might be injecting malicious code in those static files. If that's the case, I sincerely disagree with this decision, and properly securing servers would have been the right thing to do.
Also, this "security" configuration can only be disabled globally. Why not per plugin???
IMHO, this is a Jenkins issue, and it's up to the Jenkins project to provide a proper solution.
Those scripts are generated as external files because they are shared with all the reports pages. I don't think we'll ever go to the length of customizing the way the reports are generated just to cope with Jenkins.
FWIW, we don't have such limitation with the FrontLine Jenkins plugin as FrontLine has it's own server and APIs, so we can depend as less as possible on Jenkins features and architecture choices.

I'll close this as "Won't fix" for now. We'll reconsider if some solution shows up that don't require us a huge effort to adapt.