From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Bitsch To: development@lists.ipfire.org Subject: Re: Errors for WLAN card since CU189 Date: Thu, 17 Oct 2024 11:43:12 +0200 Message-ID: <3f59786e-8f72-4fdd-85a4-45a560c3c4c8@ipfire.org> In-Reply-To: <4087B2D9-0540-4FDE-A5E7-9FA8A38A28F1@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1615646519265376495==" List-Id: --===============1615646519265376495== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'll try as good as my influenca allows;) I think, the problems came up with the change from 'select interface' in=20 hostapd WUI to 'hostapd is on blue'. BR, Bernhard Am 17.10.2024 um 11:33 schrieb Michael Tremer: > Could you elaborate a little bit more on this? >=20 > We might want to fix this in c189 before other people walk into the same pr= oblem=E2=80=A6 >=20 > -Michael >=20 >> On 16 Oct 2024, at 20:04, Bernhard Bitsch wrote: >> >> Some light at the end of the tunnel. ;) >> >> wlanap.cgi tries to set $INTF from $cgiparams{'INTERFACE'} in line 64. >> But $cgiparams{'INTERFACE'} is not defined or empty. >> Setting $INTF to "blue0" brings the channels and the status. >> I think there went something wrong with the modification to new look. >> >> The problem with the kernel errors is solved by the interrupt setting. >> >> Regards, >> Bernhard >> >> Am 16.10.2024 um 18:20 schrieb Bernhard Bitsch: >>> I also cannot set the channel. Only automatic channel select available. >>> /etc/init.d/hostapd restart functions at the second restart only. >>> Messages: >>> /etc/init.d/hostapd restart >>> Stopping hostapd... [ >>> Starting hostapd... >>> blue0: interface state UNINITIALIZED->COUNTRY_UPDATE >>> ACS: Automatic channel selection started, this may take a bit >>> blue0: interface state COUNTRY_UPDATE->ACS >>> blue0: ACS-STARTED >>> Am 16.10.2024 um 17:05 schrieb Michael Tremer: >>>> I believe this is a known bug in the driver. You can fix this by turning= the IRQ mode to legacy. It is a setting of the module: >>>> >>>> [root(a)fw01 ~]# modinfo ath10k_pci >>>> filename: /lib/modules/6.6.47-ipfire/kernel/drivers/net/ wireless/= ath/ath10k/ath10k_pci.ko.xz >>>> firmware: ath10k/QCA9377/hw1.0/board.bin >>>> firmware: ath10k/QCA9377/hw1.0/firmware-5.bin >>>> firmware: ath10k/QCA9377/hw1.0/firmware-6.bin >>>> firmware: ath10k/QCA6174/hw3.0/board-2.bin >>>> firmware: ath10k/QCA6174/hw3.0/board.bin >>>> =E2=80=A6 >>>> parm: irq_mode:0: auto, 1: legacy, 2: msi (default: 0) (uint) >>>> =E2=80=A6 >>>> >>>> This is most likely because of updating the firmware for your card. >>>> >>>> -Michael >>>> >>>>> On 16 Oct 2024, at 16:02, Bernhard Bitsch wrote: >>>>> >>>>> Hi, >>>>> >>>>> since some time I noticed strange messages according to my WLAN card. >>>>> With CU189 these are very frequently. >>>>> >>>>> An extract from now: >>>>> >>>>> ... >>>>> Oct 16 16:09:17 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to in= crease tx pending count: -16, dropping >>>>> Oct 16 16:10:39 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to in= crease tx pending count: -16, dropping >>>>> Oct 16 16:11:20 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:13:45 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to in= crease tx pending count: -16, dropping >>>>> Oct 16 16:18:47 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:18:52 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:19:13 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:19:28 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:19:33 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:19:38 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:19:43 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:19:48 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:19:54 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:19:59 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:20:04 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:20:09 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:20:24 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:20:40 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:21:10 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:21:16 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:21:41 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:21:46 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> Oct 16 16:21:51 BitschCop kernel: ath10k_pci 0000:01:00.0: failed to fl= ush transmit queue (skip 0 ar-state 1): 0 >>>>> ............ >>>>> >>>>> Regards, >>>>> Bernhard >>>>> >>>>> BTW: I'm missing the status part of the hostapd WUI page. >>>> >> >=20 --===============1615646519265376495==--