Hi all,
I have an Acer Aspire A315-58 laptop[0], which, according to lspci has the following intel wireless chip:
Device: 00:14.3
Class: Network controller [0280]
Vendor: Intel Corporation [8086]
Device: Wi-Fi 6 AX201 [a0f0]
SVendor: Intel Corporation [8086]
SDevice: Wi-Fi 6 AX201 [0244]
Rev: 20
ProgIf: 00
Driver: iwlwifi
Module: iwlwifi
However, in the kernel message buffer, the following message is written:
[ 3.633490] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX101, REV=0x351
Also, this chip did not work with the 6.3.3 Arch Linux kernel, the driver loaded the
`QuZ-a0-hr-b0-74.ucode` firmware:
[ 6.516505] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 13 fired (delay=0ms).
[ 6.517615] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[ 6.517616] iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
[ 6.517617] iwlwifi 0000:00:14.3: Loaded firmware version: 74.a5e9588b.0 QuZ-a0-hr-b0-74.ucode
[ 6.517619] iwlwifi 0000:00:14.3: 0x00000084 | NMI_INTERRUPT_UNKNOWN
...
[ 6.861510] iwlwifi 0000:00:14.3: Failed to run INIT ucode: -110
I then noticed that firmwares 75-77 are available and that there were recent changes
to the iwlwifi module that increased IWL_22000_UCODE_API_MAX, so I gave it a go,
and built the kernel at ae8373a5add4ea39f032563cf12a02946d1e3546 and now firmware 77
is loaded, and that seems to work, at least I did not notice any issues so far.
The full logs and other information about the laptop can be found here[0].
Regards,
Barnabás Pőcze
[0]: https://linux-hardware.org/?probe=43069955ee
On Fri, May 26, 2023 at 05:55:48PM +0000, Barnabás Pőcze wrote:
> Hi all,
>
> I have an Acer Aspire A315-58 laptop[0], which, according to lspci has the following intel wireless chip:
>
> Device: 00:14.3
> Class: Network controller [0280]
> Vendor: Intel Corporation [8086]
> Device: Wi-Fi 6 AX201 [a0f0]
> SVendor: Intel Corporation [8086]
> SDevice: Wi-Fi 6 AX201 [0244]
> Rev: 20
> ProgIf: 00
> Driver: iwlwifi
> Module: iwlwifi
>
> However, in the kernel message buffer, the following message is written:
>
> [ 3.633490] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX101, REV=0x351
>
> Also, this chip did not work with the 6.3.3 Arch Linux kernel, the driver loaded the
> `QuZ-a0-hr-b0-74.ucode` firmware:
>
> [ 6.516505] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 13 fired (delay=0ms).
> [ 6.517615] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
> [ 6.517616] iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
> [ 6.517617] iwlwifi 0000:00:14.3: Loaded firmware version: 74.a5e9588b.0 QuZ-a0-hr-b0-74.ucode
> [ 6.517619] iwlwifi 0000:00:14.3: 0x00000084 | NMI_INTERRUPT_UNKNOWN
> ...
> [ 6.861510] iwlwifi 0000:00:14.3: Failed to run INIT ucode: -110
>
>
> I then noticed that firmwares 75-77 are available and that there were recent changes
> to the iwlwifi module that increased IWL_22000_UCODE_API_MAX, so I gave it a go,
> and built the kernel at ae8373a5add4ea39f032563cf12a02946d1e3546 and now firmware 77
> is loaded, and that seems to work, at least I did not notice any issues so far.
Does 6.3.x work with your v77 firmware? 6.4-rc4 with previous v74 firmware?
Seems like moving all parts at once here, hence I asked above to
isolate possible reason why your above case works.
--
An old man doll... just what I always wanted! - Clara
Hi
2023. május 31., szerda 15:59 keltezéssel, Bagas Sanjaya <[email protected]> írta:
> On Fri, May 26, 2023 at 05:55:48PM +0000, Barnabás Pőcze wrote:
> > Hi all,
> >
> > I have an Acer Aspire A315-58 laptop[0], which, according to lspci has the following intel wireless chip:
> >
> > Device: 00:14.3
> > Class: Network controller [0280]
> > Vendor: Intel Corporation [8086]
> > Device: Wi-Fi 6 AX201 [a0f0]
> > SVendor: Intel Corporation [8086]
> > SDevice: Wi-Fi 6 AX201 [0244]
> > Rev: 20
> > ProgIf: 00
> > Driver: iwlwifi
> > Module: iwlwifi
> >
> > However, in the kernel message buffer, the following message is written:
> >
> > [ 3.633490] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX101, REV=0x351
> >
> > Also, this chip did not work with the 6.3.3 Arch Linux kernel, the driver loaded the
> > `QuZ-a0-hr-b0-74.ucode` firmware:
> >
> > [ 6.516505] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 13 fired (delay=0ms).
> > [ 6.517615] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
> > [ 6.517616] iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
> > [ 6.517617] iwlwifi 0000:00:14.3: Loaded firmware version: 74.a5e9588b.0 QuZ-a0-hr-b0-74.ucode
> > [ 6.517619] iwlwifi 0000:00:14.3: 0x00000084 | NMI_INTERRUPT_UNKNOWN
> > ...
> > [ 6.861510] iwlwifi 0000:00:14.3: Failed to run INIT ucode: -110
> >
> >
> > I then noticed that firmwares 75-77 are available and that there were recent changes
> > to the iwlwifi module that increased IWL_22000_UCODE_API_MAX, so I gave it a go,
> > and built the kernel at ae8373a5add4ea39f032563cf12a02946d1e3546 and now firmware 77
> > is loaded, and that seems to work, at least I did not notice any issues so far.
>
> Does 6.3.x work with your v77 firmware? 6.4-rc4 with previous v74 firmware?
>
> Seems like moving all parts at once here, hence I asked above to
> isolate possible reason why your above case works.
| v74 v77
------+----------------
6.3.3 | crash n/a
6.3.5 | crash n/a
git | ok ok
(git ~ commit ae8373a5add4ea39f032563cf12a02946d1e3546)
(n/a ~ the driver does not support the firmware, i.e. IWL_22000_UCODE_API_MAX is too low)
So it appears that some commits might need to be backported for it work.
But every time it is detected as an AX101. I am more concerned about the misdetection.
Who is mistaken? lspci or iwlwifi? What are the potential consequences?
> [...]
Regards,
Barnabás Pőcze
Hi again,
2023. május 26., péntek 19:55 keltezéssel, Barnabás Pőcze <[email protected]> írta:
> Hi all,
>
> I have an Acer Aspire A315-58 laptop[0], which, according to lspci has the following intel wireless chip:
>
> Device: 00:14.3
> Class: Network controller [0280]
> Vendor: Intel Corporation [8086]
> Device: Wi-Fi 6 AX201 [a0f0]
> SVendor: Intel Corporation [8086]
> SDevice: Wi-Fi 6 AX201 [0244]
> Rev: 20
> ProgIf: 00
> Driver: iwlwifi
> Module: iwlwifi
>
> However, in the kernel message buffer, the following message is written:
>
> [ 3.633490] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX101, REV=0x351
>
> Also, this chip did not work with the 6.3.3 Arch Linux kernel, the driver loaded the
> `QuZ-a0-hr-b0-74.ucode` firmware:
>
> [ 6.516505] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 13 fired (delay=0ms).
> [ 6.517615] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
> [ 6.517616] iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
> [ 6.517617] iwlwifi 0000:00:14.3: Loaded firmware version: 74.a5e9588b.0 QuZ-a0-hr-b0-74.ucode
> [ 6.517619] iwlwifi 0000:00:14.3: 0x00000084 | NMI_INTERRUPT_UNKNOWN
> ...
> [ 6.861510] iwlwifi 0000:00:14.3: Failed to run INIT ucode: -110
>
For the record, I have done a git-bisect[1], and that turned up
d2ccc5c1526396aef5196e4dd2ec8538994e5072
wifi: iwlwifi: Update init sequence if tx diversity supported
as the first good commit[0].
Sadly, that patch (or even the series) does not appear to be easily backportable,
so it seems likely that current stable kernels won't be able to support this device.
Regards,
Barnabás Pőcze
[0]: https://lore.kernel.org/all/20230413102635.c2121c8694a7.Ibee3dd8765ef4b7504660fa228a7c7eff78920af@changeid/
[1]:
git bisect start
# status: waiting for both good and bad commits
# new: [b6dad5178ceaf23f369c3711062ce1f2afc33644] Merge tag 'nios2_fix_v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux
git bisect new b6dad5178ceaf23f369c3711062ce1f2afc33644
# status: waiting for good commit(s), bad commit known
# old: [457391b0380335d5e9a5babdec90ac53928b23b4] Linux 6.3
git bisect old 457391b0380335d5e9a5babdec90ac53928b23b4
# new: [6e98b09da931a00bf4e0477d0fa52748bf28fcce] Merge tag 'net-next-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
git bisect new 6e98b09da931a00bf4e0477d0fa52748bf28fcce
# old: [088e0c188513b58a0056a488cf5b7df094a8a48a] Merge tag 'platform-drivers-x86-v6.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
git bisect old 088e0c188513b58a0056a488cf5b7df094a8a48a
# new: [ca288965801572fe41386560d4e6c5cc0e5cc56d] Merge tag 'wireless-next-2023-04-21' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
git bisect new ca288965801572fe41386560d4e6c5cc0e5cc56d
# old: [d56417ad1133fc41752bb9fe37da7ae3187395a4] net: phy: smsc: clear edpd_enable if interrupt mode is used
git bisect old d56417ad1133fc41752bb9fe37da7ae3187395a4
# old: [c54876cd5961ce0f8e74807f79a6739cd6b35ddf] net/sched: pass netlink extack to mqprio and taprio offload
git bisect old c54876cd5961ce0f8e74807f79a6739cd6b35ddf
# new: [3288ee5844b74cebb94ed15bc9b5b9d3223ae038] Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
git bisect new 3288ee5844b74cebb94ed15bc9b5b9d3223ae038
# new: [d0b6f86fdbefa62fd4ad2acd1aea6c45f9b518ba] wifi: mt76: mt7996: let non-bufferable MMPDUs use correct hw queue
git bisect new d0b6f86fdbefa62fd4ad2acd1aea6c45f9b518ba
# new: [a0e97ae3f3320a246a79db7372fc23a38556014e] wifi: rtw89: add ieee80211::remain_on_channel ops
git bisect new a0e97ae3f3320a246a79db7372fc23a38556014e
# new: [d00800a289c9349bb659a698cbd7bc04521dc927] wifi: mac80211: add flush_sta method
git bisect new d00800a289c9349bb659a698cbd7bc04521dc927
# old: [413be839bfca9a4f6b32b92807ecdc2c2c182d94] wifi: iwlwifi: add a validity check of queue_id in iwl_txq_reclaim
git bisect old 413be839bfca9a4f6b32b92807ecdc2c2c182d94
# old: [e305a408c5f9c8df06a58e09a23375fd257f081c] wifi: iwlwifi: mvm: move function sequence
git bisect old e305a408c5f9c8df06a58e09a23375fd257f081c
# new: [217f3c52f00d3419ecdd38a99a7eceecb11679b2] wifi: iwlwifi: mvm: don't set CHECKSUM_COMPLETE for unsupported protocols
git bisect new 217f3c52f00d3419ecdd38a99a7eceecb11679b2
# new: [5caa82529eabff044c5f3eb254f3a7ff00e9170d] wifi: iwlwifi: Update configurations for Bnj-a0 and specific rf devices
git bisect new 5caa82529eabff044c5f3eb254f3a7ff00e9170d
# new: [d2ccc5c1526396aef5196e4dd2ec8538994e5072] wifi: iwlwifi: Update init sequence if tx diversity supported
git bisect new d2ccc5c1526396aef5196e4dd2ec8538994e5072
# first new commit: [d2ccc5c1526396aef5196e4dd2ec8538994e5072] wifi: iwlwifi: Update init sequence if tx diversity supported
>
> I then noticed that firmwares 75-77 are available and that there were recent changes
> to the iwlwifi module that increased IWL_22000_UCODE_API_MAX, so I gave it a go,
> and built the kernel at ae8373a5add4ea39f032563cf12a02946d1e3546 and now firmware 77
> is loaded, and that seems to work, at least I did not notice any issues so far.
>
> The full logs and other information about the laptop can be found here[0].
>
>
> Regards,
> Barnabás Pőcze
>
>
> [0]: https://linux-hardware.org/?probe=43069955ee
[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]
On 27.06.23 23:55, Barnabás Pőcze wrote:
>
> 2023. május 26., péntek 19:55 keltezéssel, Barnabás Pőcze <[email protected]> írta:
>>
>> I have an Acer Aspire A315-58 laptop[0], which, according to lspci has the following intel wireless chip:
>>
>> Device: 00:14.3
>> Class: Network controller [0280]
>> Vendor: Intel Corporation [8086]
>> Device: Wi-Fi 6 AX201 [a0f0]
>> SVendor: Intel Corporation [8086]
>> SDevice: Wi-Fi 6 AX201 [0244]
>> Rev: 20
>> ProgIf: 00
>> Driver: iwlwifi
>> Module: iwlwifi
>>
>> However, in the kernel message buffer, the following message is written:
>>
>> [ 3.633490] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX101, REV=0x351
> [...]
>
> For the record, I have done a git-bisect[1], and that turned up
>
> d2ccc5c1526396aef5196e4dd2ec8538994e5072
> wifi: iwlwifi: Update init sequence if tx diversity supported
>
> as the first good commit[0].
>
> Sadly, that patch (or even the series) does not appear to be easily backportable,
> so it seems likely that current stable kernels won't be able to support this device.
Thx for bisecting.
Thing is: 6.3 will be EOL in about two or three weeks anyway. And Arch
will likely switch to 6.4 (which works -- or did I get this wrong?)
within a week or two. Makes be wonder if it's the best solution for
everyone involved to not resolve this and move on.
Ciao, Thorsten
> [0]: https://lore.kernel.org/all/20230413102635.c2121c8694a7.Ibee3dd8765ef4b7504660fa228a7c7eff78920af@changeid/
> [1]:
> git bisect start
> # status: waiting for both good and bad commits
> # new: [b6dad5178ceaf23f369c3711062ce1f2afc33644] Merge tag 'nios2_fix_v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux
> git bisect new b6dad5178ceaf23f369c3711062ce1f2afc33644
> # status: waiting for good commit(s), bad commit known
> # old: [457391b0380335d5e9a5babdec90ac53928b23b4] Linux 6.3
> git bisect old 457391b0380335d5e9a5babdec90ac53928b23b4
> # new: [6e98b09da931a00bf4e0477d0fa52748bf28fcce] Merge tag 'net-next-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> git bisect new 6e98b09da931a00bf4e0477d0fa52748bf28fcce
> # old: [088e0c188513b58a0056a488cf5b7df094a8a48a] Merge tag 'platform-drivers-x86-v6.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
> git bisect old 088e0c188513b58a0056a488cf5b7df094a8a48a
> # new: [ca288965801572fe41386560d4e6c5cc0e5cc56d] Merge tag 'wireless-next-2023-04-21' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
> git bisect new ca288965801572fe41386560d4e6c5cc0e5cc56d
> # old: [d56417ad1133fc41752bb9fe37da7ae3187395a4] net: phy: smsc: clear edpd_enable if interrupt mode is used
> git bisect old d56417ad1133fc41752bb9fe37da7ae3187395a4
> # old: [c54876cd5961ce0f8e74807f79a6739cd6b35ddf] net/sched: pass netlink extack to mqprio and taprio offload
> git bisect old c54876cd5961ce0f8e74807f79a6739cd6b35ddf
> # new: [3288ee5844b74cebb94ed15bc9b5b9d3223ae038] Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
> git bisect new 3288ee5844b74cebb94ed15bc9b5b9d3223ae038
> # new: [d0b6f86fdbefa62fd4ad2acd1aea6c45f9b518ba] wifi: mt76: mt7996: let non-bufferable MMPDUs use correct hw queue
> git bisect new d0b6f86fdbefa62fd4ad2acd1aea6c45f9b518ba
> # new: [a0e97ae3f3320a246a79db7372fc23a38556014e] wifi: rtw89: add ieee80211::remain_on_channel ops
> git bisect new a0e97ae3f3320a246a79db7372fc23a38556014e
> # new: [d00800a289c9349bb659a698cbd7bc04521dc927] wifi: mac80211: add flush_sta method
> git bisect new d00800a289c9349bb659a698cbd7bc04521dc927
> # old: [413be839bfca9a4f6b32b92807ecdc2c2c182d94] wifi: iwlwifi: add a validity check of queue_id in iwl_txq_reclaim
> git bisect old 413be839bfca9a4f6b32b92807ecdc2c2c182d94
> # old: [e305a408c5f9c8df06a58e09a23375fd257f081c] wifi: iwlwifi: mvm: move function sequence
> git bisect old e305a408c5f9c8df06a58e09a23375fd257f081c
> # new: [217f3c52f00d3419ecdd38a99a7eceecb11679b2] wifi: iwlwifi: mvm: don't set CHECKSUM_COMPLETE for unsupported protocols
> git bisect new 217f3c52f00d3419ecdd38a99a7eceecb11679b2
> # new: [5caa82529eabff044c5f3eb254f3a7ff00e9170d] wifi: iwlwifi: Update configurations for Bnj-a0 and specific rf devices
> git bisect new 5caa82529eabff044c5f3eb254f3a7ff00e9170d
> # new: [d2ccc5c1526396aef5196e4dd2ec8538994e5072] wifi: iwlwifi: Update init sequence if tx diversity supported
> git bisect new d2ccc5c1526396aef5196e4dd2ec8538994e5072
> # first new commit: [d2ccc5c1526396aef5196e4dd2ec8538994e5072] wifi: iwlwifi: Update init sequence if tx diversity supported
>
>
>>
>> I then noticed that firmwares 75-77 are available and that there were recent changes
>> to the iwlwifi module that increased IWL_22000_UCODE_API_MAX, so I gave it a go,
>> and built the kernel at ae8373a5add4ea39f032563cf12a02946d1e3546 and now firmware 77
>> is loaded, and that seems to work, at least I did not notice any issues so far.
>>
>> The full logs and other information about the laptop can be found here[0].
>>
>>
>> Regards,
>> Barnabás Pőcze
>>
>>
>> [0]: https://linux-hardware.org/?probe=43069955ee
Hi
2023. június 29., csütörtök 13:31 keltezéssel, Thorsten Leemhuis <[email protected]> írta:
> [CCing the regression list, as it should be in the loop for regressions:
> https://docs.kernel.org/admin-guide/reporting-regressions.html]
>
> On 27.06.23 23:55, Barnabás Pőcze wrote:
> >
> > 2023. május 26., péntek 19:55 keltezéssel, Barnabás Pőcze <[email protected]> írta:
> >>
> >> I have an Acer Aspire A315-58 laptop[0], which, according to lspci has the following intel wireless chip:
> >>
> >> Device: 00:14.3
> >> Class: Network controller [0280]
> >> Vendor: Intel Corporation [8086]
> >> Device: Wi-Fi 6 AX201 [a0f0]
> >> SVendor: Intel Corporation [8086]
> >> SDevice: Wi-Fi 6 AX201 [0244]
> >> Rev: 20
> >> ProgIf: 00
> >> Driver: iwlwifi
> >> Module: iwlwifi
> >>
> >> However, in the kernel message buffer, the following message is written:
> >>
> >> [ 3.633490] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX101, REV=0x351
> > [...]
> >
> > For the record, I have done a git-bisect[1], and that turned up
> >
> > d2ccc5c1526396aef5196e4dd2ec8538994e5072
> > wifi: iwlwifi: Update init sequence if tx diversity supported
> >
> > as the first good commit[0].
> >
> > Sadly, that patch (or even the series) does not appear to be easily backportable,
> > so it seems likely that current stable kernels won't be able to support this device.
>
> Thx for bisecting.
>
> Thing is: 6.3 will be EOL in about two or three weeks anyway. And Arch
> will likely switch to 6.4 (which works -- or did I get this wrong?)
> within a week or two. Makes be wonder if it's the best solution for
> everyone involved to not resolve this and move on.
>
> Ciao, Thorsten
Yes, 6.4 seems to work. I mainly meant LTS releases. Nonetheless, lspci
and iwlwifi still disagree on what device it actually is.
Regards,
Barnabás Pőcze
>
> > [0]: https://lore.kernel.org/all/20230413102635.c2121c8694a7.Ibee3dd8765ef4b7504660fa228a7c7eff78920af@changeid/
> > [1]:
> > git bisect start
> > # status: waiting for both good and bad commits
> > # new: [b6dad5178ceaf23f369c3711062ce1f2afc33644] Merge tag 'nios2_fix_v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux
> > git bisect new b6dad5178ceaf23f369c3711062ce1f2afc33644
> > # status: waiting for good commit(s), bad commit known
> > # old: [457391b0380335d5e9a5babdec90ac53928b23b4] Linux 6.3
> > git bisect old 457391b0380335d5e9a5babdec90ac53928b23b4
> > # new: [6e98b09da931a00bf4e0477d0fa52748bf28fcce] Merge tag 'net-next-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> > git bisect new 6e98b09da931a00bf4e0477d0fa52748bf28fcce
> > # old: [088e0c188513b58a0056a488cf5b7df094a8a48a] Merge tag 'platform-drivers-x86-v6.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
> > git bisect old 088e0c188513b58a0056a488cf5b7df094a8a48a
> > # new: [ca288965801572fe41386560d4e6c5cc0e5cc56d] Merge tag 'wireless-next-2023-04-21' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
> > git bisect new ca288965801572fe41386560d4e6c5cc0e5cc56d
> > # old: [d56417ad1133fc41752bb9fe37da7ae3187395a4] net: phy: smsc: clear edpd_enable if interrupt mode is used
> > git bisect old d56417ad1133fc41752bb9fe37da7ae3187395a4
> > # old: [c54876cd5961ce0f8e74807f79a6739cd6b35ddf] net/sched: pass netlink extack to mqprio and taprio offload
> > git bisect old c54876cd5961ce0f8e74807f79a6739cd6b35ddf
> > # new: [3288ee5844b74cebb94ed15bc9b5b9d3223ae038] Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
> > git bisect new 3288ee5844b74cebb94ed15bc9b5b9d3223ae038
> > # new: [d0b6f86fdbefa62fd4ad2acd1aea6c45f9b518ba] wifi: mt76: mt7996: let non-bufferable MMPDUs use correct hw queue
> > git bisect new d0b6f86fdbefa62fd4ad2acd1aea6c45f9b518ba
> > # new: [a0e97ae3f3320a246a79db7372fc23a38556014e] wifi: rtw89: add ieee80211::remain_on_channel ops
> > git bisect new a0e97ae3f3320a246a79db7372fc23a38556014e
> > # new: [d00800a289c9349bb659a698cbd7bc04521dc927] wifi: mac80211: add flush_sta method
> > git bisect new d00800a289c9349bb659a698cbd7bc04521dc927
> > # old: [413be839bfca9a4f6b32b92807ecdc2c2c182d94] wifi: iwlwifi: add a validity check of queue_id in iwl_txq_reclaim
> > git bisect old 413be839bfca9a4f6b32b92807ecdc2c2c182d94
> > # old: [e305a408c5f9c8df06a58e09a23375fd257f081c] wifi: iwlwifi: mvm: move function sequence
> > git bisect old e305a408c5f9c8df06a58e09a23375fd257f081c
> > # new: [217f3c52f00d3419ecdd38a99a7eceecb11679b2] wifi: iwlwifi: mvm: don't set CHECKSUM_COMPLETE for unsupported protocols
> > git bisect new 217f3c52f00d3419ecdd38a99a7eceecb11679b2
> > # new: [5caa82529eabff044c5f3eb254f3a7ff00e9170d] wifi: iwlwifi: Update configurations for Bnj-a0 and specific rf devices
> > git bisect new 5caa82529eabff044c5f3eb254f3a7ff00e9170d
> > # new: [d2ccc5c1526396aef5196e4dd2ec8538994e5072] wifi: iwlwifi: Update init sequence if tx diversity supported
> > git bisect new d2ccc5c1526396aef5196e4dd2ec8538994e5072
> > # first new commit: [d2ccc5c1526396aef5196e4dd2ec8538994e5072] wifi: iwlwifi: Update init sequence if tx diversity supported
> >
> >
> >>
> >> I then noticed that firmwares 75-77 are available and that there were recent changes
> >> to the iwlwifi module that increased IWL_22000_UCODE_API_MAX, so I gave it a go,
> >> and built the kernel at ae8373a5add4ea39f032563cf12a02946d1e3546 and now firmware 77
> >> is loaded, and that seems to work, at least I did not notice any issues so far.
> >>
> >> The full logs and other information about the laptop can be found here[0].
> >>
> >>
> >> Regards,
> >> Barnabás Pőcze
> >>
> >>
> >> [0]: https://linux-hardware.org/?probe=43069955ee
On 29.06.23 17:28, Barnabás Pőcze wrote:
> 2023. június 29., csütörtök 13:31 keltezéssel, Thorsten Leemhuis <[email protected]> írta:
>> On 27.06.23 23:55, Barnabás Pőcze wrote:
>>> 2023. május 26., péntek 19:55 keltezéssel, Barnabás Pőcze <[email protected]> írta:
>>>> I have an Acer Aspire A315-58 laptop[0], which, according to lspci has the following intel wireless chip:
>>>>
>>>> Device: 00:14.3
>>>> Class: Network controller [0280]
>>>> Vendor: Intel Corporation [8086]
>>>> Device: Wi-Fi 6 AX201 [a0f0]
>>>> SVendor: Intel Corporation [8086]
>>>> SDevice: Wi-Fi 6 AX201 [0244]
>>>> Rev: 20
>>>> ProgIf: 00
>>>> Driver: iwlwifi
>>>> Module: iwlwifi
>>>>
>>>> However, in the kernel message buffer, the following message is written:
>>>>
>>>> [ 3.633490] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX101, REV=0x351
Gregory who is CCed since the start of the thread might care to look
into this. According to a quick search lspci is right, but this needs
expects. Maybe it's just a cosmetic problem.
>>> [...]
>>> For the record, I have done a git-bisect[1], and that turned up
>>> d2ccc5c1526396aef5196e4dd2ec8538994e5072
>>>
>>> as the first good commit[0].
>>>
>>> Sadly, that patch (or even the series) does not appear to be easily backportable,
>>> so it seems likely that current stable kernels won't be able to support this device.
>>
>> Thx for bisecting.
>>
>> Thing is: 6.3 will be EOL in about two or three weeks anyway. And Arch
>> will likely switch to 6.4 (which works -- or did I get this wrong?)
>> within a week or two. Makes be wonder if it's the best solution for
>> everyone involved to not resolve this and move on.
>
> Yes, 6.4 seems to work.
#regzbot inconclusive: unlikely to be fixed in 6.3 before EOL, but 6.4 works
> I mainly meant LTS releases. Nonetheless, lspci
> and iwlwifi still disagree on what device it actually is.
Not sure if I properly understand this.
Is this broken in 6.1.y as well, but working in earlier kernels? Then it
needs a separate report.
Or do you mean the disagreement? Maybe mentioning Gregory's name above
will do the trick to make the Intel folks look into this.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
Hi
2023. június 29., csütörtök 18:50 keltezéssel, Linux regression tracking (Thorsten Leemhuis) <[email protected]> írta:
> On 29.06.23 17:28, Barnabás Pőcze wrote:
> > 2023. június 29., csütörtök 13:31 keltezéssel, Thorsten Leemhuis <[email protected]> írta:
> >> On 27.06.23 23:55, Barnabás Pőcze wrote:
> >>> 2023. május 26., péntek 19:55 keltezéssel, Barnabás Pőcze <[email protected]> írta:
> >>>> I have an Acer Aspire A315-58 laptop[0], which, according to lspci has the following intel wireless chip:
> >>>>
> >>>> Device: 00:14.3
> >>>> Class: Network controller [0280]
> >>>> Vendor: Intel Corporation [8086]
> >>>> Device: Wi-Fi 6 AX201 [a0f0]
> >>>> SVendor: Intel Corporation [8086]
> >>>> SDevice: Wi-Fi 6 AX201 [0244]
> >>>> Rev: 20
> >>>> ProgIf: 00
> >>>> Driver: iwlwifi
> >>>> Module: iwlwifi
> >>>>
> >>>> However, in the kernel message buffer, the following message is written:
> >>>>
> >>>> [ 3.633490] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX101, REV=0x351
>
> Gregory who is CCed since the start of the thread might care to look
> into this. According to a quick search lspci is right, but this needs
> expects. Maybe it's just a cosmetic problem.
>
> >>> [...]
> >>> For the record, I have done a git-bisect[1], and that turned up
> >>> d2ccc5c1526396aef5196e4dd2ec8538994e5072
> >>>
> >>> as the first good commit[0].
> >>>
> >>> Sadly, that patch (or even the series) does not appear to be easily backportable,
> >>> so it seems likely that current stable kernels won't be able to support this device.
> >>
> >> Thx for bisecting.
> >>
> >> Thing is: 6.3 will be EOL in about two or three weeks anyway. And Arch
> >> will likely switch to 6.4 (which works -- or did I get this wrong?)
> >> within a week or two. Makes be wonder if it's the best solution for
> >> everyone involved to not resolve this and move on.
> >
> > Yes, 6.4 seems to work.
>
> #regzbot inconclusive: unlikely to be fixed in 6.3 before EOL, but 6.4 works
>
> > I mainly meant LTS releases. Nonetheless, lspci
> > and iwlwifi still disagree on what device it actually is.
>
> Not sure if I properly understand this.
>
> Is this broken in 6.1.y as well, but working in earlier kernels? Then it
> needs a separate report.
There are two issues:
* lspci and iwlwifi disagreeing about the device (AX201 vs AX101), and
* the device not working until the aforementioned commit.
This email was originally intended to be about the first one since the device
does work with 6.4.
But out of curiosity I wanted to find the commit that made the device work to
see if maybe it could be easily backported to 6.3, 6.1, etc.
In conclusion:
device does not work device is misdetected
6.1 present present
6.3 present present
6.4 fixed present
Since the commits that fixed it don't appear to be easily backportable,
the only thing remains to be seen is why lspci and iwlwifi disagree about the
name of the device. That issue is still present in 6.4.
Regards,
Barnabás Pőcze
>
> Or do you mean the disagreement? Maybe mentioning Gregory's name above
> will do the trick to make the Intel folks look into this.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
On Thu, Jun 29, 2023 at 05:30:34PM +0000, Barnabás Pőcze wrote:
> Hi
>
>
> 2023. június 29., csütörtök 18:50 keltezéssel, Linux regression tracking (Thorsten Leemhuis) <[email protected]> írta:
>
> > On 29.06.23 17:28, Barnabás Pőcze wrote:
> > > 2023. június 29., csütörtök 13:31 keltezéssel, Thorsten Leemhuis <[email protected]> írta:
> > >> On 27.06.23 23:55, Barnabás Pőcze wrote:
> > >>> 2023. május 26., péntek 19:55 keltezéssel, Barnabás Pőcze <[email protected]> írta:
> > >>>> I have an Acer Aspire A315-58 laptop[0], which, according to lspci has the following intel wireless chip:
> > >>>>
> > >>>> Device: 00:14.3
> > >>>> Class: Network controller [0280]
> > >>>> Vendor: Intel Corporation [8086]
> > >>>> Device: Wi-Fi 6 AX201 [a0f0]
> > >>>> SVendor: Intel Corporation [8086]
> > >>>> SDevice: Wi-Fi 6 AX201 [0244]
> > >>>> Rev: 20
> > >>>> ProgIf: 00
> > >>>> Driver: iwlwifi
> > >>>> Module: iwlwifi
> > >>>>
> > >>>> However, in the kernel message buffer, the following message is written:
> > >>>>
> > >>>> [ 3.633490] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX101, REV=0x351
> >
> > Gregory who is CCed since the start of the thread might care to look
> > into this. According to a quick search lspci is right, but this needs
> > expects. Maybe it's just a cosmetic problem.
> >
> > >>> [...]
> > >>> For the record, I have done a git-bisect[1], and that turned up
> > >>> d2ccc5c1526396aef5196e4dd2ec8538994e5072
> > >>>
> > >>> as the first good commit[0].
> > >>>
> > >>> Sadly, that patch (or even the series) does not appear to be easily backportable,
> > >>> so it seems likely that current stable kernels won't be able to support this device.
> > >>
> > >> Thx for bisecting.
> > >>
> > >> Thing is: 6.3 will be EOL in about two or three weeks anyway. And Arch
> > >> will likely switch to 6.4 (which works -- or did I get this wrong?)
> > >> within a week or two. Makes be wonder if it's the best solution for
> > >> everyone involved to not resolve this and move on.
> > >
> > > Yes, 6.4 seems to work.
> >
> > #regzbot inconclusive: unlikely to be fixed in 6.3 before EOL, but 6.4 works
> >
> > > I mainly meant LTS releases. Nonetheless, lspci
> > > and iwlwifi still disagree on what device it actually is.
> >
> > Not sure if I properly understand this.
> >
> > Is this broken in 6.1.y as well, but working in earlier kernels? Then it
> > needs a separate report.
>
> There are two issues:
>
> * lspci and iwlwifi disagreeing about the device (AX201 vs AX101), and
> * the device not working until the aforementioned commit.
>
> This email was originally intended to be about the first one since the device
> does work with 6.4.
>
> But out of curiosity I wanted to find the commit that made the device work to
> see if maybe it could be easily backported to 6.3, 6.1, etc.
>
> In conclusion:
>
> device does not work device is misdetected
> 6.1 present present
> 6.3 present present
> 6.4 fixed present
>
> Since the commits that fixed it don't appear to be easily backportable,
> the only thing remains to be seen is why lspci and iwlwifi disagree about the
> name of the device. That issue is still present in 6.4.
This isn't a regression then, it's never worked, but now it works in
6.4, so yeah! And we don't generally backport new hardware enablement
to stable kernels unless it's a simple device id table update.
As for naming, realize that iwlwifi and lspci get the names of the
device from different places, so perhaps those userspace databases just
are not in sync yet?
thanks,
greg k-h
Hi
2023. június 29., csütörtök 20:46 keltezéssel, Greg KH <[email protected]> írta:
> On Thu, Jun 29, 2023 at 05:30:34PM +0000, Barnabás Pőcze wrote:
> > Hi
> >
> >
> > 2023. június 29., csütörtök 18:50 keltezéssel, Linux regression tracking (Thorsten Leemhuis) <[email protected]> írta:
> >
> > > On 29.06.23 17:28, Barnabás Pőcze wrote:
> > > > 2023. június 29., csütörtök 13:31 keltezéssel, Thorsten Leemhuis <[email protected]> írta:
> > > >> On 27.06.23 23:55, Barnabás Pőcze wrote:
> > > >>> 2023. május 26., péntek 19:55 keltezéssel, Barnabás Pőcze <[email protected]> írta:
> > > >>>> I have an Acer Aspire A315-58 laptop[0], which, according to lspci has the following intel wireless chip:
> > > >>>>
> > > >>>> Device: 00:14.3
> > > >>>> Class: Network controller [0280]
> > > >>>> Vendor: Intel Corporation [8086]
> > > >>>> Device: Wi-Fi 6 AX201 [a0f0]
> > > >>>> SVendor: Intel Corporation [8086]
> > > >>>> SDevice: Wi-Fi 6 AX201 [0244]
> > > >>>> Rev: 20
> > > >>>> ProgIf: 00
> > > >>>> Driver: iwlwifi
> > > >>>> Module: iwlwifi
> > > >>>>
> > > >>>> However, in the kernel message buffer, the following message is written:
> > > >>>>
> > > >>>> [ 3.633490] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX101, REV=0x351
> > >
> > > Gregory who is CCed since the start of the thread might care to look
> > > into this. According to a quick search lspci is right, but this needs
> > > expects. Maybe it's just a cosmetic problem.
> > >
> > > >>> [...]
> > > >>> For the record, I have done a git-bisect[1], and that turned up
> > > >>> d2ccc5c1526396aef5196e4dd2ec8538994e5072
> > > >>>
> > > >>> as the first good commit[0].
> > > >>>
> > > >>> Sadly, that patch (or even the series) does not appear to be easily backportable,
> > > >>> so it seems likely that current stable kernels won't be able to support this device.
> > > >>
> > > >> Thx for bisecting.
> > > >>
> > > >> Thing is: 6.3 will be EOL in about two or three weeks anyway. And Arch
> > > >> will likely switch to 6.4 (which works -- or did I get this wrong?)
> > > >> within a week or two. Makes be wonder if it's the best solution for
> > > >> everyone involved to not resolve this and move on.
> > > >
> > > > Yes, 6.4 seems to work.
> > >
> > > #regzbot inconclusive: unlikely to be fixed in 6.3 before EOL, but 6.4 works
> > >
> > > > I mainly meant LTS releases. Nonetheless, lspci
> > > > and iwlwifi still disagree on what device it actually is.
> > >
> > > Not sure if I properly understand this.
> > >
> > > Is this broken in 6.1.y as well, but working in earlier kernels? Then it
> > > needs a separate report.
> >
> > There are two issues:
> >
> > * lspci and iwlwifi disagreeing about the device (AX201 vs AX101), and
> > * the device not working until the aforementioned commit.
> >
> > This email was originally intended to be about the first one since the device
> > does work with 6.4.
> >
> > But out of curiosity I wanted to find the commit that made the device work to
> > see if maybe it could be easily backported to 6.3, 6.1, etc.
> >
> > In conclusion:
> >
> > device does not work device is misdetected
> > 6.1 present present
> > 6.3 present present
> > 6.4 fixed present
> >
> > Since the commits that fixed it don't appear to be easily backportable,
> > the only thing remains to be seen is why lspci and iwlwifi disagree about the
> > name of the device. That issue is still present in 6.4.
>
> This isn't a regression then, it's never worked, but now it works in
> 6.4, so yeah! And we don't generally backport new hardware enablement
> to stable kernels unless it's a simple device id table update.
I was hoping the change is just a couple lines of bug fixing, which I imagine,
would've been a good candidate for backporting. To be fair, the commit that made
it work is in fact a couple lines, but it has many dependencies...
>
> As for naming, realize that iwlwifi and lspci get the names of the
> device from different places, so perhaps those userspace databases just
> are not in sync yet?
> [...]
Yes, I am aware of that. Another thing I have realized is that I could just open
the laptop to see what's written on the chip to determine who is right. As it turns
out, I did not even have to do that because it says right on the back that
The Device Contains WLAN + Bluetooth Module
AX101NGW
I really should've thought of this before. So if this label is to be believed,
then iwlwifi is right, and lspci is incorrect. So sorry everyone for this waste
of time. For some reasons I really thought that iwlwifi was in the wrong.
I submitted the info to the pci-ids project: https://pci-ids.ucw.cz/read/PC/8086/a0f0
Regards,
Barnabás Pőcze