Bug#1081114: linux: Please enable CONFIG_MT7925E=m, CONFIG_MT7925U=m

[Vincent Blut]

Hi Robert,

Le 2024-09-08 03:32, Robert Edmonds a écrit :
> Package: linux
> Severity: wishlist
> 
> Dear maintainers,
> 
> Please enable support for MediaTek Wi-Fi 7 adapters based on the
> mt7925 driver. These adapters can be purchased now (e.g. the AzureWave
> AW-EB600NF M.2 module) but the driver for these adapters is not enabled
> in the Debian kernel:
> 
> $ grep -i mt7925 /boot/config-6.10.7-amd64
> # CONFIG_MT7925E is not set
> # CONFIG_MT7925U is not set
> 
> The Bluetooth functionality on the module that I have is provided by
> a USB device with ID 13d3:3604, which needs a patch to add the device
> ID [0]. It looks like this is in bluetooth-next and will probably be
> in 6.12.
> 
> The firmware-mediatek package already ships firmware for the mt7925
> driver:
> 
> $ dpkg -L firmware-mediatek | grep mt7925
> /usr/lib/firmware/mediatek/mt7925
> /usr/lib/firmware/mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin
> /usr/lib/firmware/mediatek/mt7925/WIFI_MT7925_PATCH_MCU_1_1_hdr.bin
> /usr/lib/firmware/mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin
> 
> Ubuntu enabled the mt7925 driver some time ago [1].

I'm working on adding support for a bunch of Wi-Fi 7 devices. I hope to
be able to send a merge request later today. Note that this will target
Linux 6.11 though.

> 
> Thanks!
> 
> [0] 
> https://patchwork.kernel.org/project/linux-mediatek/patch/20240715061508.14077-1-jiande...@mediatek.com/
> 
> [1] https://bugs.launchpad.net/ubuntu/+source/linux-oem-6.5/+bug/2043542
> 
> -- 
> Robert Edmonds
> edmo...@debian.org
> 


signature.asc
Description: PGP signature

Bug#1063161:

[Vincent Blut]

Hi Nathan,

Le 2024-05-23 17:12, Nathan MALO a écrit :
> Hello !
> 
> Thank you very much for enabling those two features in the kernel.
> Your work is much appreciated !
> 
> Maybe I am missing something but I've download the 6.8.9-1 package from
> here
> http://ftp.us.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.8.9-amd64_6.8.9-1_amd64.deb
> and while fiddling with it, I was not able to find the keys CONFIG_AMDTEE
> and CONFIG_AMD_PMF in the /boot/config file.
> 
> I was able to see those two keys activated in salsa :
> https://salsa.debian.org/kernel-team/linux/-/blob/sid/debian/config/amd64/config?ref_type=heads
> 
> Am I missing something ?
> Maybe the package was not rebuilt with this new configuration ?

We are just lacking a configuration symbol. Diederik, starting with
linux 6.8 AMD PMF requires TEE. Do you want me to send a MR?

> Thanks for your help !

Thanks for the report,
Vincent


signature.asc
Description: PGP signature

Re: Requesting CONFIG_PINCTRL_METEORLAKE

[Vincent Blut]

Hi,

Le 2024-04-30 17:14, Szabolcs Gyurko a écrit :
> Hi team,
> 
> 
> Can I please request that you compile kernels with CONFIG_PINCTRL_METEORLAKE 
> enabled as module like all the other PINCTRL ones?
> This is needed on new generation Intel Ultra CPUs to enable i2c devices 
> properly.
> 
> Currently I need to recompile the kernel just because of this (I’m running 
> sid 6.7.9 kernel at the time of writing). I’d rather have the stock kernel 
> have this.

I opened a merge request a few days ago.
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1062
 
> Thanks,
> --
> Szabolcs Gyurko
> szabo...@gyurko.org 
> PGP-ID: 0x50F289EE @ keys.gnupg.net

Cheers,
Vincent


signature.asc
Description: PGP signature

Re: linux-image-6.5.0-5-amd64: 474 MB; linux-image-6.6.13-amd64: 99.4 MB. Why? And should I care?

[Vincent Blut]

Hi Ludovic,

Le 2024-02-05 17:13, Ludovic Brenta a écrit :
> Hello, kernel maintainers.
> 
> I see in aptitude that the size of the linux-image package is being
> reduced by almost 80%.  I have searched kernel logs (both upstream and
> Debian packaging) but could not find an explanation.  Does this imply
> that many kernel modules have disappeared?  I don't see ant new packages
> to contain these modules, though.  So: what happened, and should I care?

Nothing to worry about, modules are now compressed with XZ.
 
> Thanks a lot for your time
> 
> -- 
> Ludovic Brenta.
 
Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1057272: Enable SENSORS_IIO_HWMON support

[Vincent Blut]

Control: tags -1 moreinfo

Hi Andrey,

Le 2023-12-02 16:40, Andrey Melnikov a écrit :
> Package: src:linux
> Version: 6.5.13-1
> Severity: wishlist
> 
> Please, enable SENSORS_IIO_HWMON support. Without it I'm unable to
> fetch the AXP209 internal temperature sensor.
 
The definition of the AXP209 PMU seems to confirm that the internal temperature
sensor is hooked to the iio-hwmon driver:

pmic-temp {
compatible = "iio-hwmon";
io-channels = <&axp_adc 4>; /* Internal temperature */
};

One thing, though. Does it make sense to enable SENSORS_IIO_HWMON outside of
armhf?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1055244: linux-image-amd64: Please enable CONFIG_MTK_T7XX for the Intel/Mediatek FM350-GL 5G modem

[Vincent Blut]

Hi Martin,

Le 2023-11-02 20:10, Martin Sofaru a écrit :
> Source: linux
> Version: linux/6.5.0-3
> Severity: wishlist
> X-Debbugs-Cc: debian-b...@fhloston.org
> 
> Dear Maintainer,
> 
> please set CONFIG_MTK_T7XX=m to build the mtk_t7xx kernel module.
> 
> This module is necessary to use some 5G modems built into newer Lenovo 
> Laptops like X1 Yoga Gen7/Gen8 and X1 Carbon Gen10/Gen11.
> 
> As long as this [1] patch is not merged upstream, it might be sensible to 
> also include this. 
> 
> The modem itself also needs some kind of FCC unlock which can be found here 
> [2].

I'll send a merge request soon. The patch to have the modem part work has been
merged in Linux 6.6-rc1.
 
> Thank you
> 
> Martin

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1055069: please enable SC8280XP sound modules

[Vincent Blut]

Hi,

Le 2023-10-30 20:30, Dmitry Baryshkov a écrit :
> Package: src:linux
> Version: 6.5.8-1
> Severity: normal
> 
> Please enable the following options as modules to enable audio support
> on Lenovo X13s platform:
> 
> CONFIG_SND_SOC_SC8280XP
> CONFIG_SC_LPASSCC_8280XP

Emanuele, as you’re working on support for the Lenovo X13s platform, could you
please comment on that?

Cheers,
Vincent


signature.asc
Description: PGP signature

Re: CONFIG_PREEMPT_DYNAMIC=y?

[Vincent Blut]

Hi,

Le 2023-10-10 13:54, Diederik de Haas a écrit :
> On Tuesday, 10 October 2023 12:10:07 CEST Emanuele Rocca wrote:
> > CONFIG_PREEMPT_DYNAMIC is set to 'y' by default on amd64 due to
> > HAVE_PREEMPT_DYNAMIC_CALL being 'y', see:
> > https://sources.debian.org/src/linux/6.5.6-1/kernel/Kconfig.preempt/?hl=101#
> > L101
> > 
> > arm64 does not have PREEMPT_DYNAMIC_CALL, this is why PREEMPT_DYNAMIC is
> > not set by default there.
> 
> Neither does amd64. So it appears something else is causing 
> CONFIG_PREEMPT_DYNAMIC to be enabled on amd64.

From the commit message introducing PREEMPT_DYNAMIC:¹

CONFIG_PREEMPT_DYNAMIC is automatically selected by CONFIG_PREEMPT if
the architecture provides the necessary support (CONFIG_STATIC_CALL_INLINE,
CONFIG_GENERIC_ENTRY, and provide with __preempt_schedule_function() /
__preempt_schedule_notrace_function()).

Cheers,
Vincent

¹ https://lore.kernel.org/all/20210118141223.123667-5-frede...@kernel.org/T/#u


signature.asc
Description: PGP signature

Bug#1041007: linux-image-6.1.0-0.deb11.7-amd64: Please enable TPM hardware RNG support (CONFIG_HW_RANDOM_TPM)

[Vincent Blut]

Hi Björn,

Le 2023-08-15 07:49, Björn Persson a écrit :
> Hello, has there been any progress with this?

I started working on this a few days ago. I’ll try to send a merge request
over the weekend.

> […]
>
> Björn Persson

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1041007: linux-image-6.1.0-0.deb11.7-amd64: Please enable TPM hardware RNG support (CONFIG_HW_RANDOM_TPM)

[Vincent Blut]

Hello,

Le 2023-07-13 23:10, jflf_ker...@gmx.com a écrit :
> Package: src:linux
> Version: 6.1.20-2~bpo11+1
> Severity: normal
> X-Debbugs-Cc: jflf_ker...@gmx.com
> 
> Dear Maintainer,
> 
> Currently no Debian kernel enables support for TPM hardware RNG. On one of my
> systems:
> 
> $ uname -a
> Linux XXX 6.1.0-0.deb11.7-amd64 #1 SMP PREEMPT_DYNAMIC Debian
> 6.1.20-2~bpo11+1 (2023-04-23) x86_64 GNU/Linux
> 
> $ cat /sys/class/tpm/tpm0/device/description
> TPM 2.0 Device
> 
> $ ls /dev/tpm*
> /dev/tpm0  /dev/tpmrm0
> 
> $ sudo tpm2_getrandom 16 | xxd -p
> 7ba65632453b191385a3989485ac80a3
> 
> $ grep HW_RANDOM_TPM /boot/config-$(uname -r)
> 
> 
> $ find /lib/modules/$(uname -r) -iname \*tpm\*rng\*
> 
> 
> $ ls /dev/hwrng
> ls: cannot access '/dev/hwrng': No such file or directory
> 
> 
> I have checked the current bookworm and trixie kernel debs, and they don't
> include it either. It should be enabled there too.
> 
> I manage multiple older amd64 machines that have discrete TPM chips, but no
> RDRAND instruction or any other hardware RNG. Enabling support for the TPM RNG
> would provide the kernel with additional entropy earlier in the boot process.

Indeed, this regression compared to the kernel provided in bullseye is due to
a configuration issue.
For HW_RANDOM_TPM to be enabled, the TCG_TPM and HW_RANDOM config symbols are
required but there is a subtlety in the way they have to be built. If TCG_TPM
is built-in then HW_RANDOM must not be loadable (built as a module).

If we take a look at the kernel configuration files prior being constructed, we
can see that both TCG_TPM and HW_RANDOM config symbols should be built as
modules:

$ grep -Er "TCG_TPM|HW_RANDOM="
arm64/config:CONFIG_TCG_TPM=m
kernelarch-x86/config:CONFIG_TCG_TPM=m
config:CONFIG_HW_RANDOM=m
config.cloud:CONFIG_TCG_TPM=m
 
However after these files have been constructed, the TCG_TPM config symbol is
no longer provided as module but built-in:

$ grep TCG_TPM /boot/config-6.3.0-1-amd64
CONFIG_TCG_TPM=y

This change is what causes HW_RANDOM_TPM to be disabled and is probably due to
[1].

Ben, Salvatore, to fix this regression we should either force TCG_TPM to be
built as a module or make HW_RANDOM built-in. The second solution have my
preference, WDYT?

Cheers,
Vincent

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=644f17412f5acf01a19af9d04a921937a2bc86c6


signature.asc
Description: PGP signature

Bug#1038385: linux-image-amd64: Please enable CONFIG_INTEL_SKL_INT3472 for the Intel Skylake power controller

[Vincent Blut]

Le 2023-07-26 14:57, Martin Sofaru a écrit :
> Hi Vincent,
> 
> On Tue, 25 Jul 2023 22:50:35 +0200 Vincent Blut 
> wrote:
> > Hi Martin,
> > 
> > Le 2023-07-25 16:15, Martin Sofaru a écrit :
> > > Dear maintainer,
> > > > since kernel 6.4.
> > > > CONFIG_VIDEO_V4L2_SUBDEV_API=y needs to be set aswell.
> > > > It was previously enabled until kernel 6.3.
> > > > > CONFIG_INTEL_SKL_INT3472=m and
> > 
> > […]
> > 
> > > CONFIG_VIDEO_V4L2_SUBDEV_API=y
> > > > are needed to compile ipu6-drivers-dkms for the new Intel
> > Computervision
> > > webcams present in major manufacturer's new designs, for example Lenovo's 
> > > X1
> > > Carbon gen10+ or X1 Yoga Gen7+.
> > 
> > This driver should select VIDEO_V4L2_SUBDEV_API, right?
> 
> currently the dkms from ipu6-drivers just fails to compile when
> CONFIG_VIDEO_V4L2_SUBDEV_API is not set. So if I enable some other not
> related media driver that selects CONFIG_VIDEO_V4L2_SUBDEV_API=y I can build
> ipu6-drivers.
 
If this driver requires this API then it should select VIDEO_V4L2_SUBDEV_API.
Could you eventually send a bug report upstream?

> I simply noticed that
> config-6.3.0-1-amd64 and
> config-6.3.0-2-amd64
> have CONFIG_VIDEO_V4L2_SUBDEV_API=y while config-6.4.0-1-amd64 has not.
> 
> I do not know the reasoning for the removal of that config.
 
CONFIG_VIDEO_V4L2_SUBDEV_API was available in Linux 6.3 thanks to the 
CONFIG_VIDEO_NOON010PC30 option. However that camera sensor driver has been
dropped in Linux 6.4 and none of the camera sensor drivers enabled in Debian
select CONFIG_VIDEO_V4L2_SUBDEV_API.

> At this point I am just grateful I can use the camera in my device at all :)

Understandable ;)


signature.asc
Description: PGP signature

Bug#1038385: linux-image-amd64: Please enable CONFIG_INTEL_SKL_INT3472 for the Intel Skylake power controller

[Vincent Blut]

Hi Martin,

Le 2023-07-25 16:15, Martin Sofaru a écrit :
> Dear maintainer,
> 
> since kernel 6.4.
> 
> CONFIG_VIDEO_V4L2_SUBDEV_API=y needs to be set aswell.
> 
> It was previously enabled until kernel 6.3.
> 
> 
> CONFIG_INTEL_SKL_INT3472=m and

[…]

> CONFIG_VIDEO_V4L2_SUBDEV_API=y
> 
> are needed to compile ipu6-drivers-dkms for the new Intel Computervision
> webcams present in major manufacturer's new designs, for example Lenovo's X1
> Carbon gen10+ or X1 Yoga Gen7+.

This driver should select VIDEO_V4L2_SUBDEV_API, right?

> Thank you
> 
> Martin
 
 Cheers,
 Vincent


signature.asc
Description: PGP signature

Bug#1012222: linux: please enable the CONFIG_X86_KERNEL_IBT configuration option

[Vincent Blut]

Version: 6.3.1-1~exp1

Hi Laurent,

Le 2022-06-01 18:53, Laurent Bonnaud a écrit :
> Package: src:linux
> Version: 5.18.0-trunk
> Severity: wishlist
> 
> 
> Dear kernel Maintainers,
> 
> the CONFIG_X86_KERNEL_IBT configuration option is currently not enabled in 
> Debian kernels:
> 
> $ grep CONFIG_X86_KERNEL_IBT /boot/config*
> /boot/config-5.18.0-trunk-amd64:# CONFIG_X86_KERNEL_IBT is not set
> /boot/config-5.18.0-trunk-rt-amd64:# CONFIG_X86_KERNEL_IBT is not set
> 
> It is an important protection against ROP/JOP attacks.  Could you please 
> enable it in Debian kernels?

Let's close this report since kernel IBT is enabled by default starting with
Linux 6.2+ [1].
 
> Thanks,
> 
> -- 
> Laurent.
 
Cheers,
Vincent

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4fd5f70ce14da230c6a29648c3d51a48ee0b4bfd


signature.asc
Description: PGP signature

Bug#1035569: installation-reports: failed to detect Realtek RTL8852BE WiFi 6 802.11ax PCIe adapter

[Vincent Blut]

Le 2023-05-09 19:05, Diederik de Haas a écrit :
> On Tuesday, 9 May 2023 18:49:35 CEST Vincent Blut wrote:
> > > today I tried again with a TP-Link TL-WN725N Nano USB dongle which
> > > contains the Realtek RTL8188EU chip set. Same result, the adapter is not
> > > recognized and I am presented with a list of kernel modules of which none
> > > works. But in this case, I am pretty sure that the RTL8188EU chip *should*
> > > be supported by a recent kernel.
> > > 
> > > Any hints, or should I file a separate installation report?
> > 
> > RTL8188EU support requires Linux 6.3+:
> > https://lore.kernel.org/all/3aad60f6-23f9-81e8-c741-4bd51e99f...@gmail.com/
> 
> While that appears to be a 'proper' driver for RTL8188EU, it looks like there
> was a previous driver for it in staging:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-6.1.y&qt=grep&q=RTL8188EU
> 
> The new installation report (https://bugs.debian.org/1035824) has this line:
> [42871.936975] r8188eu: module is from the staging directory, the quality is 
> unknown, you have been warned.
> 
> Am I missing something (still)?

Color me stupid. I was working from upstream's master branch which have the
staging driver removed. Sorry for the confusion!


signature.asc
Description: PGP signature

Bug#1035569: installation-reports: failed to detect Realtek RTL8852BE WiFi 6 802.11ax PCIe adapter

[Vincent Blut]

Hi Fabian,

Le 2023-05-09 18:04, fab...@greffrath.com a écrit :
> Hi guys,
> 
> Am 05.05.2023 18:09, schrieb Diederik de Haas:
> > Too recent for Bookworm as it appears that it was added in 6.2,
> > while Bookworm has 6.1.
> 
> today I tried again with a TP-Link TL-WN725N Nano USB dongle which contains
> the Realtek RTL8188EU chip set. Same result, the adapter is not recognized
> and I am presented with a list of kernel modules of which none works. But in
> this case, I am pretty sure that the RTL8188EU chip *should* be supported by
> a recent kernel.
> 
> Any hints, or should I file a separate installation report?

RTL8188EU support requires Linux 6.3+:
https://lore.kernel.org/all/3aad60f6-23f9-81e8-c741-4bd51e99f...@gmail.com/
 
> Cheers,
> 
>  - Fabian
 
Cheers,
Vincent


signature.asc
Description: PGP signature

Re: Request for Realtek rtw89_8852be driver

[Vincent Blut]

Le 2023-03-26 18:24, Diederik de Haas a écrit :
> On Sunday, 26 March 2023 17:55:17 CEST Vincent Blut wrote:
> > Le 2023-03-26 15:12, Andy Smith a écrit :
> > > I've got a laptop running testing with a Realtek 8852be card in it.
> > > 
> > > This driver seems to be present in upstream kernel from 6.1:
> > > https://elixir.bootlin.com/linux/v6.1/source/drivers/net/wireless/real
> > > tek/rtw89/rtw8852be.c> 
> > > but doesn't seem to be in any Debian kernel package at present.
> 
> While a skeleton version of that file is present, it does not seem to be a 
> complete driver (in 6.2 it's already 'fuller'), but more importantly, in the 
> Kconfig file there is no RTW89_8852BE, so it can't be enabled in Debian's 6.1 
> kernel.

Indeed, that's what I observed after having a closer look.
 
> > > I have got it working using a DKMS built from these instructions:
> > > https://github.com/lwfinger/rtw89
> > > 
> > > (and packaged firmware-realtek)
> > > 
> > > Will this driver make its way into a bookworm kernel at some point,
> 
> No, but the DKMS built saw a recent improvement :-)
> 
> > > or do I need to submit a wishlist bug for this, or is there some
> > > other procedure?
> 
> To get it enabled for *Trixie*, filing a wishlist bug seems appropriate.

Yeah, I’ll send a MR when Linux 6.2+ hits master.
 
> > Surely it would be wise to enable RTW89_8852BE and RTW89_8852CE for
> > bookworm. Salvatore, what's your take on this? I can commit some time to
> > work on this.
> 
> The RTW89_8852CE module is available in the 6.1 Kconfig file, so it _could_ 
> be 
> enabled, but whether that's useful without an explicit request is another Q.

I think it would be nice to have it enabled since it is available on quite a
few Lenovo Legion T series towers.

Cheers,
Vincent


signature.asc
Description: PGP signature

Re: Request for Realtek rtw89_8852be driver

[Vincent Blut]

Hi Andy,

Le 2023-03-26 15:12, Andy Smith a écrit :
> Hi,
> 
> I've got a laptop running testing with a Realtek 8852be card in it.
> This driver seems to be present in upstream kernel from 6.1:
> 
> 
> https://elixir.bootlin.com/linux/v6.1/source/drivers/net/wireless/realtek/rtw89/rtw8852be.c
> 
> but doesn't seem to be in any Debian kernel package at present.
> 
> I have got it working using a DKMS built from these instructions:
> 
> https://github.com/lwfinger/rtw89
> 
> (and packaged firmware-realtek)
> 
> Will this driver make its way into a bookworm kernel at some point,
> or do I need to submit a wishlist bug for this, or is there some
> other procedure?

Surely it would be wise to enable RTW89_8852BE and RTW89_8852CE for bookworm.
Salvatore, what's your take on this? I can commit some time to work on this.
 
> Thanks!
> Andy
 
Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1021337: linux-image-5.19.0-2-amd64: Please enable building of the idxd module for the IntelData Accelerator support

[Vincent Blut]

Le 2022-10-06 12:34, Diederik de Haas a écrit :
> Control: severity -1 wishlist
> 
> On donderdag 6 oktober 2022 07:58:35 CEST Gunnar Wolf wrote:
> > Package: linux-image-5.19.0-2-amd64
> > 
> > Specifically, the required configuration options to enable all of its
> > features are:
> >CONFIG_INTEL_IDXD=m
> >CONFIG_INTEL_IDXD_SVM=y
> 
> Is this only applicable for the amd64 architecture or is it useful for others 
> as well?

Since these depend on X86_64, only amd64 is concerned.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1013895: RTL8188EUS 802.11n Wireless Network Adapter not working on 5.18

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2022-06-26 23:53, Santiago Ruano Rincón a écrit :
> Package: src:linux
> Version: 5.18.5-1
> Severity: important
> 
> Dear linux maintainers,
> 
> Not sure if this should be filed against firmware-realtek, and sorry if
> that is the case. I have a WiFi USB dongle that doesn't work on linux
> 5.18, but it does work on 5.15.
> 
> You can see this error in the logs below during boot, or when I replug
> the dongle:
> 
>  r8188eu 1-1.2:1.0: _rtw_init_xmit_priv failed
> 
> Maybe this is relevant:
> https://lkml.org/lkml/2022/5/21/527

This patch has been applied upstream to Linux 5.19-rc3 and backported to Linux
5.18.6. While the latter is not yet available in Debian, we have Linux 5.19-rc4
in experimental. Could you please check if it fixes this issue?
 
> Thanks for your work,
> 
>  -- Santiago

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1012880: linux: ti omap hw crypto drivers not enabled

[Vincent Blut]

Control: reassign -1 src:linux

Hi,

Le 2022-06-16 17:49, Yu-Tung Chang a écrit :
> Package: linux-image-armmp
> Version: 5.18.0-1
> 
> lookup in debian\config\armhf\config:
> CONFIG_CRYPTO_DEV_OMAP_SHAM=m
> CONFIG_CRYPTO_DEV_OMAP_AES=m
> 
> lookup in /boot/config-5.18.0-1-armmp:
> # CONFIG_CRYPTO_DEV_OMAP is not set
> 
> Drivers not enabled as expected!
 
We are missing CRYPTO_DEV_OMAP, indeed. I'll fix that!

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1010580: acp drivers

[Vincent Blut]

Hi Mario,

Le 2022-05-04 16:04, Limonciello, Mario a écrit :
> Package: linux
> Version: 5.17.3
> 
> Currently the kernel config by default does not configure these two options:
> # CONFIG_SND_SOC_AMD_ACP5x is not set
> # CONFIG_SND_SOC_AMD_ACP6x is not set
> 
> Ideally these should both be set to "m".
> 
> ACP5x is for supporting the ACP in the Steam Deck.
> ACP6x is for supporting the DMIC in notebooks with Ryzen 6000.

This is on my TODO list.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1010146: modprobe: ERROR: could not insert 'amd_pstate': No such device

[Vincent Blut]

Package: src:linux
Followup-For: Bug #1010146

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Tobias,

The AMD P-State driver has been enabled in linux 5.17.3-1 available in
testing/unstable. The kernel you are using does not include it.

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYmf4nQAKCRAQn1qAt/bg
AatkAP46KeDriC3sYK2cnwBEHUmYdD1CWNhAMYF9Tu4YrMJJTAD+J5NBDxUSddqR
EP80CuI/o9PhPDmNCNZLwYunHwzEPAw=
=Mv1P
-END PGP SIGNATURE-

Bug#1009018: linux-image-5.16.0-5-amd64: Shutdown, reboot, and suspend broken on chromebook when module cros_ec_typec is loaded.

[Vincent Blut]

Version: 5.17.3-1

Hi,

Le 2022-04-05 18:23, Dan Bassett a écrit :
> Package: src:linux
> Version: 5.16.14-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: b...@fizix.org
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>I upgraded my system from Stable (5.10 kernel) to Testing in order
>to get sound working, however, upon upgrade, my system was no longer
>able to shutdown, reboot, or suspend properly.  All of these actions
>would result in the system hanging, requiring a hard reset.
> 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>I manually built a series of kernels to try to narrow down where
>the issue was occuring and found that when I disabled the building of
>chromebook related platform drivers, my system would happily reboot
>and suspend.  I also noticed that the kernel was throwing an error 
>at boot when attempting to load the cros_ec_typec module.  Given this
>information, I attempted to boot the stock debian kernel
>(5.16.0-5-amd64) with the option module_blacklist=cros_ec_typec,
>which resulted in a system that rebooted and suspended as expected.
>I am unaware of any functionality that I may be losing by not loading
>the cros_ec_typec module.
> 
> 
>* What was the outcome of this action?
> 
>I have a working system, though ideally this module would properly
>load on boot (as my hardware configuration seems to want it), and not
>break shutdown/reboot/suspend.
> 
> 
>* What outcome did you expect instead?
> 
>The system should work without disabling relevant kernel modules.

Dan confirmed to me privately that this issue has been fixed in Linux 5.17.3.
Closing!

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1008973: linux-image-amd64: Very slow wireless with MEDIATEK 7961

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2022-04-05 14:39, Xavier Chantry a écrit :
> Package: linux-image-amd64
> Version: 5.10.84-1
> Severity: important
> X-Debbugs-Cc: chantry.xav...@gmail.com
> 
> Dear Maintainer,
> 
> We have a problem with MEDIATEK 7961 wireless on Levono P14s with AMD
> Ryzen.
> 
> With 5.10 kernel on debian stable the wireless just does not work, so we
> installed kernel 5.16 from testing.
> 
> With kernel 5.16 the wireless is so slow that it's unusable, each
> internet query takes several seconds. A simple ping to google.com varies
> from 100ms to 3000ms.
> 
> With kernel 5.17 it's slighly better but the ping still goes up to
> 600ms.
> 
> With kernel 5.15 however, it works quite good, Internet is very usable,
> ping varies from 3ms to 30ms.
> (on the same network, the P14s with Intel wireless does better and is
> always under 10ms).
> 
> It looks like big changes were made to the mt7921e driver in 5.16
> according to Phoronix :
> The Mediatek MT7921 WiFi driver has added support for 6GHz WiFi, active
> state power management (ASPM), and other improvements.
> 
> And it looks like this caused a big regression with MEDIATEK 7961.
> 
> Besides the network performance problem on 5.16, suspend/resume is also
> broken, while it works perfectly on 5.15.

Le 2022-04-06 10:19, Christoph Martin a écrit :
> I have the same Problem with an P14s and Mediathek 7921e.
> There is even about 30% package loss.
> 
> Christoph
> 
> Am 05.04.22 um 14:39 schrieb Xavier Chantry:
> > 
> > With kernel 5.16 the wireless is so slow that it's unusable, each
> > internet query takes several seconds. A simple ping to google.com varies
> > from 100ms to 3000ms.
> > 
> > With kernel 5.17 it's slighly better but the ping still goes up to
> > 600ms.

Le 2022-04-15 14:19, Julien Negros a écrit :
> Hi,
> 
> Same issue here, switching to linux-image-5.15.0-0.bpo.3-amd64 did the
> trick. Hope the next kernel version fixes this problem !
> 
> Cheers
> -- 
> Julien Négros
 
Linux 5.17.3 (uploaded to unstable earlier today) includes a lot of fixes for
Mediatek WLAN devices. Could you please check if that kernel fixes the slowness
you are seeing?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1009299: linux-image-5.16.0-6-amd64: 5.16 breaks buttons below touchpad on Dell Precision 7550

[Vincent Blut]

Hi Marc,

Le 2022-04-11 09:59, Marc Glisse a écrit :
> Package: src:linux
> Version: 5.16.18-1
> Severity: normal
> 
> Dear Maintainer,
> 
> the Dell Precision 7550 is a laptop which has a touchpad, and below it 3
> physical buttons. If I boot with linux-image-5.15.0-3-amd64, these
> buttons work perfectly well. However, with linux-image-5.16.0-6-amd64,
> the right button does not work. Running xev, it prints nothing when I
> click that button. evemu-record does see something when I click on the
> right button, here are some random parts of its log
> 
> # DMI: 
> dmi:bvnDellInc.:bvr1.12.0:bd12/12/2021:br1.12:svnDellInc.:pnPrecision7550:pvr:rvnDellInc.:rn01PXFR:rvrA00:cvnDellInc.:ct10:cvr:sku09C3:
> # Input device name: "DELL09C3:00 0488:120A Touchpad"
> # Input device ID: bus 0x18 vendor 0x488 product 0x120a version 0x100
> 
> #   Event type 1 (EV_KEY)
> # Event code 272 (BTN_LEFT)
> # Event code 325 (BTN_TOOL_FINGER)
> # Event code 328 (BTN_TOOL_QUINTTAP)
> # Event code 330 (BTN_TOUCH)
> # Event code 333 (BTN_TOOL_DOUBLETAP)
> # Event code 334 (BTN_TOOL_TRIPLETAP)
> # Event code 335 (BTN_TOOL_QUADTAP)
> 
> # Properties:
> #   Property  type 0 (INPUT_PROP_POINTER)
> #   Property  type 2 (INPUT_PROP_BUTTONPAD)
> 
> E: 0.01 0004 0005   # EV_MSC / MSC_TIMESTAMP0
> E: 0.01     #  SYN_REPORT (0) -- +0ms
> E: 0.001257 0004 0005 4400  # EV_MSC / MSC_TIMESTAMP4400
> E: 0.001257     #  SYN_REPORT (0) -- +1ms
> E: 0.002600 0004 0005 8900  # EV_MSC / MSC_TIMESTAMP8900
> E: 0.002600     #  SYN_REPORT (0) -- +1ms
> E: 0.004029 0004 0005 13300 # EV_MSC / MSC_TIMESTAMP13300
> [...]
> 
> The buttons were always a bit strange (see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980376).
> 
> syslog (or Xorg.0.log) has, among other things
> 
> Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (II) event23 - 
> DELL09C3:00 0488:120A Touchpad: is tagged by udev as: Touchpad
> Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (EE) event23 - 
> DELL09C3:00 0488:120A Touchpad: kernel bug: missing right button, assuming it 
> is a clickpad.
> Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (II) event23 - 
> DELL09C3:00 0488:120A Touchpad: device is a touchpad
> 
> Please let me know any logs I should attach to help.

The fix [1] for this issue has been applied to the last upstream stable
kernels so it should find its way in Debian relatively soon.

Cheers,
Vincent

[1] 
https://lore.kernel.org/all/20220321184404.20025-1-jose.exposit...@gmail.com/


signature.asc
Description: PGP signature

Bug#1009302: linux-image-5.17.0-trunk-amd64: Missing CONFIG_X86_AMD_PSTATE=m module

[Vincent Blut]

Control: tags -1 pending

Hi,

Le 2022-04-11 10:52, Tobias Koeck a écrit :
> Package: src:linux
> Version: 5.17.1-1~exp1
> Severity: important
> 
> Dear Maintainer,
> 
> the
> 
> CONFIG_X86_AMD_PSTATE
> 
> module is not set.
> 
> https://www.phoronix.com/scan.php?page=news_item&px=AMD-P-State-How-To
> 
> Can you add it to the kernel so that it is possible to use AMD's power
> management?

This is pending.

https://salsa.debian.org/kernel-team/linux/-/commit/2ee8b17f8d9cf15a02bf373b7eca5bade354abaf

> Greetings and thanks,
> Tobias

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1009018: linux-image-5.16.0-5-amd64: Shutdown, reboot, and suspend broken on chromebook when module cros_ec_typec is loaded.

[Vincent Blut]

Le 2022-04-06 14:02, Vincent Blut a écrit :
> Hi Dan,
> 
> Le 2022-04-05 18:23, Dan Bassett a écrit :
> > Package: src:linux
> > Version: 5.16.14-1
> > Severity: normal
> > Tags: upstream
> > X-Debbugs-Cc: b...@fizix.org
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> > 
> >I upgraded my system from Stable (5.10 kernel) to Testing in order
> >to get sound working, however, upon upgrade, my system was no longer
> >able to shutdown, reboot, or suspend properly.  All of these actions
> >would result in the system hanging, requiring a hard reset.
> > 
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> >I manually built a series of kernels to try to narrow down where
> >the issue was occuring and found that when I disabled the building of
> >chromebook related platform drivers, my system would happily reboot
> >and suspend.  I also noticed that the kernel was throwing an error 
> >at boot when attempting to load the cros_ec_typec module.  Given this
> >information, I attempted to boot the stock debian kernel
> >(5.16.0-5-amd64) with the option module_blacklist=cros_ec_typec,
> >which resulted in a system that rebooted and suspended as expected.
> >I am unaware of any functionality that I may be losing by not loading
> >the cros_ec_typec module.
> > 
> > 
> >* What was the outcome of this action?
> > 
> >I have a working system, though ideally this module would properly
> >load on boot (as my hardware configuration seems to want it), and not
> >break shutdown/reboot/suspend.
> > 
> > 
> >* What outcome did you expect instead?
> > 
> >The system should work without disabling relevant kernel modules.
> 
> I think [1], currently applied to Linux 5.18-rc1, will fix this issue.
> 
> Prashant, Benson, should this patch be applied to Linux 5.7+?

I just noticed that it has been commited to the relevant stable trees. Sorry
for the noise!


signature.asc
Description: PGP signature

Bug#1009018: linux-image-5.16.0-5-amd64: Shutdown, reboot, and suspend broken on chromebook when module cros_ec_typec is loaded.

[Vincent Blut]

Hi Dan,

Le 2022-04-05 18:23, Dan Bassett a écrit :
> Package: src:linux
> Version: 5.16.14-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: b...@fizix.org
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>I upgraded my system from Stable (5.10 kernel) to Testing in order
>to get sound working, however, upon upgrade, my system was no longer
>able to shutdown, reboot, or suspend properly.  All of these actions
>would result in the system hanging, requiring a hard reset.
> 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>I manually built a series of kernels to try to narrow down where
>the issue was occuring and found that when I disabled the building of
>chromebook related platform drivers, my system would happily reboot
>and suspend.  I also noticed that the kernel was throwing an error 
>at boot when attempting to load the cros_ec_typec module.  Given this
>information, I attempted to boot the stock debian kernel
>(5.16.0-5-amd64) with the option module_blacklist=cros_ec_typec,
>which resulted in a system that rebooted and suspended as expected.
>I am unaware of any functionality that I may be losing by not loading
>the cros_ec_typec module.
> 
> 
>* What was the outcome of this action?
> 
>I have a working system, though ideally this module would properly
>load on boot (as my hardware configuration seems to want it), and not
>break shutdown/reboot/suspend.
> 
> 
>* What outcome did you expect instead?
> 
>The system should work without disabling relevant kernel modules.

I think [1], currently applied to Linux 5.18-rc1, will fix this issue.

Prashant, Benson, should this patch be applied to Linux 5.7+?

Cheers,
Vincent

[1] https://lore.kernel.org/all/20220126190219.3095419-1-pmal...@chromium.org/


signature.asc
Description: PGP signature

Bug#1007725: linux-image-5.16.0-4-amd64: Intel Alder Lake-P audio device not detected correctly

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2022-03-15 17:55, Sean Clarke a écrit :
> Package: src:linux
> Version: 5.16.12-1
> Severity: important
> X-Debbugs-Cc: sean.cla...@sec-consulting.co.uk
> 
> Dear Maintainer,
> 
> New Alienware X15 R2 with Alder Lake-P sound. Sound not detceted, no options 
> or
> device shown in alsa.

It seems the firmware-sof-signed package is missing. Please install it and
report back!

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1007722: linux-image-5.16.0-4-amd64: Intel Killer WIFI AX1675 not working (not detected / identified / firmware doesn't load)

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2022-03-15 17:40, Sean Clarke a écrit :
> Package: src:linux
> Version: 5.16.12-1
> Severity: important
> X-Debbugs-Cc: sean.cla...@sec-consulting.co.uk
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
> New Alienware installed with Debian Bookworm/Testing. WiFi not detected
> correctly and not showing as available

Looking at the device ID (8086:51f0), it should be supported starting with
Linux 5.17 [1]. Could you please install linux-image-5.17.0-rc8 from
experimental and report back?

Cheers,
Vincent


[1] 
https://lore.kernel.org/all/iwlwifi.20211219132536.2d5bec2d7b68.Icffb4e27390e6a5c76a0cbe7abf7472558f323d6@changeid/


signature.asc
Description: PGP signature

Bug#1006490: linux-image-5.16.0-1-amd64: hid-playstation.ko is missing

[Vincent Blut]

Hi Anton,

Le 2022-02-26 13:21, Anton Shestakov a écrit :
> Package: src:linux
> Version: 5.16.7-2
> Severity: normal
> X-Debbugs-Cc: a...@dwimlabs.net
> 
> Dear Maintainer,
> 
> On linux-image-5.15.0-3-amd64 there's a hid-playstation.ko module that 
> supports
> DualSense (PS5) controller, but it's missing from linux-image-5.16.0-1-amd64:
> 
> # dpkg -L linux-image-5.15.0-3-amd64 | fgrep hid-playstation
> /lib/modules/5.15.0-3-amd64/kernel/drivers/hid/hid-playstation.ko
> # dpkg -L linux-image-5.16.0-1-amd64 | fgrep hid-playstation
> 
> (Also missing from linux-image-5.16.0-2-amd64.)
> 
> Because of this, a different driver is used for the controller (I assume it's
> hid-generic), and so accelerometer/gyro and touchpad are not supported, and 
> the
> buttons/axes are in a strange order.
> 
> After looking at #1006275 and the patch that fixed it, I found that the older
> kernel config file also used to contain CONFIG_HID_PLAYSTATION=m and
> CONFIG_PLAYSTATION_FF=y. Please consider re-enabling these options too.

Indeed, this driver now depends on LEDS_CLASS_MULTICOLOR which is disabled in
our kernel config. I'll fix this!

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1002460: linux-image-amd64: Missing kernel configuration for Microsoft Laptops and Surface devices

[Vincent Blut]

Le 2021-12-22 14:07, Matthias Brennwald a écrit :
> Full details (including a suggested fix) are available here:
> https://github.com/linux-surface/linux-surface/issues/683

I need a clarification about CONFIG_SURFACE_AGGREGATOR_CDEV. This options' 
help text mentions that it is intended for debugging and development only, 
and should not be used otherwise. Is it really needed?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1002460: linux-image-amd64: Missing kernel configuration for Microsoft Laptops and Surface devices

[Vincent Blut]

Control: reassign -1 src:linux

Hi Matthias,

Le 2021-12-22 14:07, Matthias Brennwald a écrit :
> Package: linux-image-amd64
> Version: 5.15.5-1
> Severity: normal
> X-Debbugs-Cc: mbren...@gmail.com
> 
> Dear Maintainer,
> 
> Some features for Linux on Microsoft Laptops and Surface devices that were
> implemented in the 5.13+ Linux kernel are not configured with the kernels
> provided by Debian.
> 
> Full details (including a suggested fix) are available here:
> https://github.com/linux-surface/linux-surface/issues/683

I'll work on this later today.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Vincent Blut]

Le 2021-11-23 22:34, Salvatore Bonaccorso a écrit :
> Hi,
> 
> On Tue, Nov 23, 2021 at 12:37:02PM +0100, Vincent Blut wrote:
> > Hi,
> > 
> > Le 2021-11-22 18:54, Boyuan Yang a écrit :
> > > Hi,
> > > 
> > > On Fri, 5 Nov 2021 16:55:33 +0800 Wenbin Lv  wrote:
> > > > Package: src:linux
> > > > Version: 5.15-1~exp1
> > > > Severity: wishlist
> > > > 
> > > > Hi,
> > > > Paragon's NTFS3 driver has been merged to 5.15, and it offers much
> > > > better performance compared to ntfs-3g. Currently it is not enabled in
> > > > Debian's kernel config, nor can I mount NTFS partitions using '-t
> > > > ntfs3'.
> > > > Please enable it if you consider it stable enough. Thank you!
> > > 
> > > Now that 5.15 has been uploaded to Unstable, this issue will attract wider
> > > attention. Please consider enabling it in future uploads.
> > 
> > I'll send a merge request to the kernel team later today.
> 
> Are tools available to handle creation and checking of such NTFS3
> filesystems?

Not yet AFAIK.

> The last time I went to the paragon software site it mentioned it was
> planning. This is not a must, but kept me for slightly on the on hold
> position for enabling it.

Understandable! Let's hold off for the moment then.
 
> Regards,
> Salvatore

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Vincent Blut]

Hi,

Le 2021-11-22 18:54, Boyuan Yang a écrit :
> Hi,
> 
> On Fri, 5 Nov 2021 16:55:33 +0800 Wenbin Lv  wrote:
> > Package: src:linux
> > Version: 5.15-1~exp1
> > Severity: wishlist
> > 
> > Hi,
> > Paragon's NTFS3 driver has been merged to 5.15, and it offers much
> > better performance compared to ntfs-3g. Currently it is not enabled in
> > Debian's kernel config, nor can I mount NTFS partitions using '-t
> > ntfs3'.
> > Please enable it if you consider it stable enough. Thank you!
> 
> Now that 5.15 has been uploaded to Unstable, this issue will attract wider
> attention. Please consider enabling it in future uploads.

I'll send a merge request to the kernel team later today.

> Thanks!
> Boyuan Yang

Have a good day,
Vincent


signature.asc
Description: PGP signature

Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

[Vincent Blut]

Hi,

Le 2021-10-26 17:33, Zameer Manji a écrit :
> On Tue, Oct 26, 2021 at 5:05 PM Vincent Blut  wrote:
> 
> > Control: reassign -1 src:linux
> >
> > Hi,
> >
> > Le 2021-10-26 20:44, Zameer Manji a écrit :
> > > Package: linux-image-arm64
> > > Version: 5.14.9-2
> > > Severity: important
> > >
> > > Dear Maintainer,
> > >
> > > In bullseye, version 5.10.70-1 has the
> > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
> > > kernel configuration set to 'y'. In bookworm it is unset which disable
> > this feature.
> > >
> > > This kernel configuration parameter allows for the EFI stub of the
> > kernel to
> > > parse and use a 'initrd=' parameter to set up an initrd when booting
> > from EFI.
> > > Boot loaders like 'systemd-boot' or 'refind' set this parameter if
> > configured
> > > to pass an initrd. If the kernel configuration parameter is unset, the
> > > `initrd=` paramater is ignored, and can result in an unbootable system
> > because
> > > the initrd has not setup the root filesystem.
> > >
> > > Without the kernel configuaration set, it is not possible to use
> > 'systemd-boot'
> > > or 'refind' on arm64 as both of these bootloaders assume the kernel will
> > > handle the 'initrd=' flag and setup the initrd.
> > >
> > > Please consider enabling CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on
> > > arm64 so using 'systemd-boot' or 'refind' can continue to work. Until
> > these
> > > bootloaders have been updated to use an alternative method of passing the
> > > initrd to the EFI stub, it is not possible to have a booting system.
> >
> > Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer enabled
> > by
> > default. Please see [1] for some details.
> >
> > Cheers,
> > Vincent
> >
> > [1]
> > https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a
> >
>
> Hello Vincent,
> 
> I see and understand the rationale of upstream to deprecate this
> functionality.
> >From the commit you linked I see another commit [0] which says:
> 
> > Loading an initrd passed via the kernel command line is deprecated: it
> > is limited to files that reside in the same volume as the one the kernel
> > itself was loaded from, and we have more flexible ways to achieve the
> > same. So make it configurable so new architectures can decide not to
> > enable it.
> 
> I assume the 'more flexible ways' to do the same is referencing this
> feature [1]
> which is indeed more flexible. The problem is that the firmware/bootloader
> must
> support this new functionality, by populating the right EFI file with the
> right GUID.
> 
> As far as I can see on arm64 there are three EFI bootloaders:
> * GRUB2
> * systemd-boot
> * refind
> 
> Both systemd-boot and refind do not yet support this new mechanism,
> although I see
> that systemd has some unreleased code [2] to support the new way. I have
> not been
> able to test GRUB2 but my understanding is that this new method is still
> under active
> development [3].
> 
> The problem is that upstream has deprecated this functionality by assuming
> the only
> active use was x86, but was completely possible to use it on arm64 (it
> works fine for me
> on bullseye). Since EFI bootloaders have not yet implemented the new way,
> and still
> rely on this deprecated method on all architectures, it results in
> unbootable systems
> on arm64.
> 
> I would 100% think this should remain disabled on arm64 if most EFI
> bootloaders
> supported the new way, but unfortunately they do not.
> 
> I hope you would consider enabling this kernel configuration for arm64
> until EFI
> bootloaders catch up to the recommended way.
> 
> 
> [0]
> https://gitlab.com/linux-kernel/stable/-/commit/cf6b83664895a5c7e97710df282e220bd047f0f5
> [1]
> https://gitlab.com/linux-kernel/stable/-/commit/ec93fc371f014a6fb483e3556061ecad4b40735c
> [2]
> https://github.com/systemd/systemd/commit/a6089431d52adda93eec251a3df0dffa1fe0661a#diff-76eb4030e88f340c9133388f17c65774b0f17a0a8105500978f6ce18ca1deb5a
> [3] https://www.mail-archive.com/grub-devel@gnu.org/msg32272.html
 
Salvatore, I tend to agree with Zameer. I think we should explicitly enable 
EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER until the support for loading initrd
from a device path is widespread among bootloaders.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

[Vincent Blut]

Control: reassign -1 src:linux

Hi,

Le 2021-10-26 20:44, Zameer Manji a écrit :
> Package: linux-image-arm64
> Version: 5.14.9-2
> Severity: important
> 
> Dear Maintainer,
> 
> In bullseye, version 5.10.70-1 has the 
> CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
> kernel configuration set to 'y'. In bookworm it is unset which disable this 
> feature.
> 
> This kernel configuration parameter allows for the EFI stub of the kernel to
> parse and use a 'initrd=' parameter to set up an initrd when booting from EFI.
> Boot loaders like 'systemd-boot' or 'refind' set this parameter if configured
> to pass an initrd. If the kernel configuration parameter is unset, the
> `initrd=` paramater is ignored, and can result in an unbootable system because
> the initrd has not setup the root filesystem.
> 
> Without the kernel configuaration set, it is not possible to use 
> 'systemd-boot'
> or 'refind' on arm64 as both of these bootloaders assume the kernel will
> handle the 'initrd=' flag and setup the initrd.
> 
> Please consider enabling CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on
> arm64 so using 'systemd-boot' or 'refind' can continue to work. Until these
> bootloaders have been updated to use an alternative method of passing the
> initrd to the EFI stub, it is not possible to have a booting system.
 
Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer enabled by
default. Please see [1] for some details. 

Cheers,
Vincent

[1] 
https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a
 


signature.asc
Description: PGP signature

Bug#989777: Re: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Vincent Blut]

Hi Philippe,

Le 2021-10-14 14:11, pham...@bluewin.ch a écrit :
> Hello Vincent,
> 
> 
> Finally I had to force the installation of the firmware-iwlwifi 20210818-1 
> for it to work.
> 
> Configuring preferences.d (with files => stable-prioritaire + 
> testing-on-bullseye) and sources.list  (see attached files) was not enough. 
> By the way in Debian 12.1 sources.list is unusually short, it does not 
> contain the "Bullseye base repository" or other directory, which can be very 
> annoying for a beginner user...
> 
> After this manipulation the Bluetooth works +/-. When starting the OS for the 
> first time, Bluetooth is present and working, I can connect my Logitech MX 
> Anywhere 2S mouse but it is impossible to connect a Logitech CRAFT keyboard. 
> Indeed, the Logitech CRAFT keyboard requires the entry of a series of numeric 
> digits to confirm its connection with the OS, but no series of digits is 
> provided by the OS to make this connection, so it fails...

Installing the 'solaar' package should help you pair the keyboard with the
receiver.
 
> After a simple start, the Bluetooth connection no longer works. If I try to 
> start blueman-manager manually I get the following error message :
> 
> 
> philippe@laptop:~$ blueman-manager
> blueman-manager version 2.1.4 starting
> blueman-manager 13.43.01 ERRORManager:118 on_dbus_name_appeared: Default 
> adapter not found, trying first available.
> blueman-manager 13.43.01 ERRORManager:122 on_dbus_name_appeared: No 
> adapter(s) found, exiting
> 
> 
> root@laptop:~# blueman-manager
> Unable to init server: Could not connect: Connection refused
> Unable to init server: Impossible de se connecter : Connection refused
> Traceback (most recent call last):
>   File "/usr/bin/blueman-manager", line 44, in 
> manager = Blueman()
>   File "/usr/lib/python3/dist-packages/blueman/main/Manager.py", line 29, in 
> __init__
> super().__init__(title=_("Bluetooth Devices"))
>   File "/usr/lib/python3/dist-packages/gi/overrides/Gtk.py", line 515, in 
> __init__
> raise RuntimeError(
> RuntimeError: Gtk couldn't be initialized. Use Gtk.init_check() if you want 
> to handle this case.
> 
> 
> In this case if I run the command journalctl -k | grep -Ei 
> 'bluetooth|iwlwifi' I get :
> 
> 
> root@laptop:~# journalctl -k | grep -Ei 'bluetooth|iwlwifi' 
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: enabling device ( -> 
> 0002)
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: firmware: failed to load 
> iwlwifi-ty-a0-gf-a0-64.ucode (-2)
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: Direct firmware load for 
> iwlwifi-ty-a0-gf-a0-64.ucode failed with error -2
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: firmware: direct-loading 
> firmware iwlwifi-ty-a0-gf-a0-63.ucode
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: api flags index 2 larger 
> than supported by driver
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: TLV_FW_FSEQ_VERSION: 
> FSEQ Version: 0.0.2.25
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: loaded firmware version 
> 63.c04f3485.0 ty-a0-gf-a0-63.ucode op_mode iwlmvm
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: firmware: failed to load 
> iwl-debug-yoyo.bin (-2)
> oct 14 13:34:21 laptop kernel: Bluetooth: Core ver 2.22
> oct 14 13:34:21 laptop kernel: NET: Registered PF_BLUETOOTH protocol family
> oct 14 13:34:21 laptop kernel: Bluetooth: HCI device and connection manager 
> initialized
> oct 14 13:34:21 laptop kernel: Bluetooth: HCI socket layer initialized
> oct 14 13:34:21 laptop kernel: Bluetooth: L2CAP socket layer initialized
> oct 14 13:34:21 laptop kernel: Bluetooth: SCO socket layer initialized
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: Firmware timestamp 2021.28 
> buildtype 1 build 28502
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: No device address configured
> oct 14 13:34:21 laptop kernel: bluetooth hci0: firmware: direct-loading 
> firmware intel/ibt-0041-0041.sfi
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: Found device firmware: 
> intel/ibt-0041-0041.sfi
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: Boot Address: 0x100800
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: Firmware Version: 86-28.21
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: Firmware already loaded
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: Detected Intel(R) Wi-Fi 
> 6 AX210 160MHz, REV=0x420
> oct 14 13:34:22 laptop kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> oct 14 13:34:22 laptop kernel: Bluetooth: BNEP filters: protocol multicast
> oct 14 13:34:22 laptop kernel: Bluetooth: BNEP socket layer initialized
> oct 14 13:34:22 laptop kernel: iwlwifi :3b:00.0: firmware: direct-loading 
> firmware iwlwifi-ty-a0-gf-a0.pnvm
> oct 14 13:34:22 laptop kernel: iwlwifi :3b:00.0: loaded PNVM version 
> 0xd35929d8
> oct 14 13:34:22 laptop kernel: iwlwifi :3b:00.0: Detected RF GF, 
> rfid=0x10d000
> oct 14 13:34:22 laptop kernel: iwlwifi :3b:00

Bug#989777: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Vincent Blut]

Salut Philippe,

Le 2021-10-11 23:10, pham...@bluewin.ch a écrit :
> Hello Vincent,
> I installed the 5.14.9-2 kernel: amd64 from testing.
> After reboot I still have to install your old package for my wifi card to be 
> detected :
> https://snapshot.debian.org/archive/debian/20210313T203823Z/pool/non-free/f/firmware-nonfree/firmware-iwlwifi_20210208-4_all.deb

Curious, what does journalctl -k | grep -Ei 'bluetooth|iwlwifi' report when
booting on Linux 5.14.9-2 paired with firmware-iwlwifi 20210818-1?

> As with the 5.10 kernel there is only the Wifi which does not work and the 
> Bluetooth ?!
> I understood that Wifi worked from kernel 5.10 and Bluetooth worked from 
> kernel 5.10 ?!

AFAIR, Wi-Fi should work on Linux 5.10 but bluetooth requires Linux >= 5.11.

> Can you give me some good advice on how to get this damn Intel AX210 card 
> working under Debian 11 Bullseye ??
> Thanks in advance.
> Meilleures salutations.
> Philippe

Bonne journée,
Vincent


signature.asc
Description: PGP signature

Bug#995608: linux-image-5.14.0-1-amd64: Boot immediately hangs.

[Vincent Blut]

Le 2021-10-03 20:58, Salvatore Bonaccorso a écrit :
> Hi Vincent,
> 
> On Sun, Oct 03, 2021 at 03:55:21PM +0200, Vincent Blut wrote:
> > Hi,
> > 
> > Le 2021-10-03 11:40, Nathanael Schweers a écrit :
> > > 
> > > Salvatore Bonaccorso  writes:
> > > 
> > > > Control: tags -1 + moreinfo
> > > >
> > > > Hi Nathanael,
> > > >
> > > > On Sun, Oct 03, 2021 at 10:02:35AM +0200, Nathanael Schweers wrote:
> > > >> Package: src:linux
> > > >> Version: 5.14.6-3
> > > >> Severity: grave
> > > >> Justification: renders package unusable
> > > >>
> > > >> Dear Maintainer,
> > > >>
> > > >> using this kernel, my machine no longer boots.  Instead of showing a 
> > > >> prompt to
> > > >> enter the LUKS passphrase (as is done in version 
> > > >> linux-image-5.10.0-7-amd64) a
> > > >> non-blinking cursor is shown.  Nothing happens afterwards.
> > > >>
> > > >> Version linux-image-5.10.0-7-amd64 still works, but newer versions
> > > >> (linux-image-5.10.0-8-amd64 and the version this report is for) 
> > > >> produce the
> > > >> behaviour mentioned above.
> > > >>
> > > >> I’m afraid that I don’t have a decent idea on what extra information 
> > > >> to provide.
> > > >
> > > > Could you please confirm that booting with the 'mem_encrypt=off'
> > > > kernel command line heps?
> > > 
> > > With this option the kernel does indeed boot.  Thanks for the tip!
> > 
> > Salvatore, given the increase in bug reports that this feature generates,
> > I think it would be sensible to unset AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT 
> > until
> > those incompatibilities are fixed, like I proposed in [1]. One would have to
> > use the "mem_encrypt=on" command line option to enable the AMD Secure Memory
> > Encryption. If it sounds reasonable to you and the rest of the kernel team,
> > I can send a merge request.
> 
> Yes I think at this point is reasonable, as people wanting the feature
> still can enable it, but we do not break usual setups as it has hit
> severral people arleady. Can you post the reference [1], it was not
> included.  No need for a merge request, as I have the change already
> in debian/config/kernelarch-x86/config .

Oops, sorry about that. [1] was supposed to point to 
https://salsa.debian.org/kernel-team/linux/-/merge_requests/322/diffs

> Vincent, thanks for your huge amount of contributions, that is awesome
> :)

You're welcome!

> Regards,
> Salvatore

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#995608: linux-image-5.14.0-1-amd64: Boot immediately hangs.

[Vincent Blut]

Hi,

Le 2021-10-03 11:40, Nathanael Schweers a écrit :
> 
> Salvatore Bonaccorso  writes:
> 
> > Control: tags -1 + moreinfo
> >
> > Hi Nathanael,
> >
> > On Sun, Oct 03, 2021 at 10:02:35AM +0200, Nathanael Schweers wrote:
> >> Package: src:linux
> >> Version: 5.14.6-3
> >> Severity: grave
> >> Justification: renders package unusable
> >>
> >> Dear Maintainer,
> >>
> >> using this kernel, my machine no longer boots.  Instead of showing a 
> >> prompt to
> >> enter the LUKS passphrase (as is done in version 
> >> linux-image-5.10.0-7-amd64) a
> >> non-blinking cursor is shown.  Nothing happens afterwards.
> >>
> >> Version linux-image-5.10.0-7-amd64 still works, but newer versions
> >> (linux-image-5.10.0-8-amd64 and the version this report is for) produce the
> >> behaviour mentioned above.
> >>
> >> I’m afraid that I don’t have a decent idea on what extra information to 
> >> provide.
> >
> > Could you please confirm that booting with the 'mem_encrypt=off'
> > kernel command line heps?
> 
> With this option the kernel does indeed boot.  Thanks for the tip!

Salvatore, given the increase in bug reports that this feature generates,
I think it would be sensible to unset AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT until
those incompatibilities are fixed, like I proposed in [1]. One would have to
use the "mem_encrypt=on" command line option to enable the AMD Secure Memory
Encryption. If it sounds reasonable to you and the rest of the kernel team,
I can send a merge request.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#995234: linux-image-amd64: can't start X anymore with linux-image-5.14.0-1

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2021-09-28 12:06, Klaumi Klingsporn a écrit :
> Package: linux-image-amd64
> Version: 5.14.6-2
> Severity: important
> 
> Dear Maintainer,
> 
> after today's kernel-upgrade in testing to linux-image-5.14.0-1-amd64 
> (version 5.14.6-2)
> X cannot be started on my machine neither by lightdm nor by hand with startx.
> Booting with linux-image-5.10.0-8-amd64 (version 5.10.46-5) all works fine.
> 
> Hardware: AMD Ryzen3 3200G with Radeon Vega Graphics managed by amdgpu
> 
> I'll attach the relevant log-files for both kernels. But looking at 
> Xorg.0.log it seems
> as if the amdgpu-driver doesn't recognize the GPU any more and lists all 
> supported
> chipsets instead.

Does adding 'mem_encrypt=off' to the kernel command line helps?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#994453: Bug confirmation

[Vincent Blut]

Le 2021-09-24 16:44, Alexander Kernozhitsky a écrit :
> Hello,
> 
> > Is it still reproducible when adding 'mem_encrypt=off' to the kernel command
> > line?
> 
> with `mem_encrypt=off` parameter, the kernel boots fine.

Thanks for testing, Alexander!

Jens-Michael, Gert, how does your system behave when
disabling AMD Secure Memory Encryption?
 
> -- 
> Alexander Kernozhitsky
 
Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#994949: linux-image-5.14.0-1-amd64: amdgpu and other problems during boot resulting in unusable machine

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2021-09-23 19:46, Jan Christoph Uhde a écrit :
> Package: src:linux
> Version: 5.14.6-2
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> after installing the latest kernel my system does no longer
> boot into a usable state. The display freezes and the machine
> can only be accessed via ssh. Booting a 5.10 kernel mitigates
> the problem.
> 
> please note that I tried to use the navi-driver from linux-firmware
> (0268c1b8a06798f5167cbef8fb16241298b3eba9) which does not resolve the
> issue.
> 
> the dirvers have been installed with the following command:
> 
> --- linux-firmware-update-navi - start ---
> #!/bin/bash
> 
> ferr(){
> echo "$*"
> exit 1
> }
> 
> lib="/usr/lib/firmware"
> logfile=linux-firmware-amdgpu-update.log
> 
> cd linux-firmware || ferr "can not change into git reop"
> git fetch origin
> git reset --hard origin/HEAD || ferr "can not update"
> 
> changes="$(git diff HEAD@{1} HEAD -- amdgpu 2>&1)"
> 
> if [[ -z $changes ]]; then
> exit 1
> fi
> 
> cp amdgpu/nav* "$lib/amdgpu" || ferr "can not copy navi files"
> 
> date +%F | tee -a ../$logfile
> git log -n1 | tee -a ../$logfile
> echo "$changes" | tee -a ../$logfile
> echo "---" | tee -a ../$logfile
> echo "" | tee -a ../$logfile
> update-initramfs -u
> #yes this sucks I should use $HOME instead of `..`
> --- linux-firmware-update-navi - end ---
> 
> I am really willing to help to resolve this issue, but I would need
> some guidance as I have no system/kernel programming experience.
> 
> I feel comfortable with git / gdb / c++ and understand basic C.
> But I have no clue about gnu-extensions or the standard libraries
> other than the stuff in `string.h`.
> 
> If you can not deal with the problem yourself it would be really
> helpful if you could bring me into contact with people, who can
> solve this issue or are at least interested. I can not identify
> the problem enough to find the correct mailing list. This why I
> file the bug here in the debian bug tracker. 

Could you please try if booting with the 'mem_encrypt=off' kernel command line
helps?

Thanks,
Vincent


signature.asc
Description: PGP signature

Bug#994453: Bug confirmation

[Vincent Blut]

Hi,

Le 2021-09-24 03:02, Alexander Kernozhitsky a écrit :
> Control: found -1 5.14.6-2
> 
> I have just tried installing the kernel from unstable. After reboot, the 
> booting process just hung at the very early stage. Nothing was printed onto 
> the screen, and I cannot find the logs, as it happened during booting from 
> initramfs.
> 
> The problem may be specific to Debian, as I tried booting openSUSE Tumbleweed 
> from LiveUSB with kernel 5.14.5, and it worked fine.
> 
> I am using Lenovo Thinkpad E495 with AMD Ryzen 5 3500U CPU.

Is it still reproducible when adding 'mem_encrypt=off' to the kernel command
line?
 
> -- 
> Alexander Kernozhitsky
 
Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#977320: linux-image-4.19.0-9-amd64: Enable CONFIG_BACKLIGHT_PWM

[Vincent Blut]

Package: src:linux
Followup-For: Bug #977320

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Pablo,

Were you able to diagnosed this issue?

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYUT7HgAKCRAQn1qAt/bg
AdpBAQDGv+E83P4C0+T9+G8jlohi3RhhiGjWfPnB5PAtV+hGaQD+NtuUuqXx/Iip
H8FXkRu4VlZ82BLw5H9WhpfSlGFpDQ4=
=5Vml
-END PGP SIGNATURE-

Bug#944886: Please enable CONFIG_SND_SOC_SOF_NOCODEC_SUPPORT

[Vincent Blut]

Package: src:linux
Followup-For: Bug #944886

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 moreinfo

Hi,

Debian Bullseye should provide a much better experience on machines equipped
with this kind of audio controllers without having to enable
CONFIG_SND_SOC_SOF_NOCODEC_SUPPORT, which is not recommended.

If you still have this laptop, it would be nice to hear how it behaves on a
"modern" kernel.

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYUSweAAKCRAQn1qAt/bg
AZEkAPsE1p7I0KEmLEnxHZ1yh5hWeKDPKmrkd0o2e9h0FIBG4AD/c3d/2+bgXKrN
Me740IT+3NBm002WTYrsQn+BWs+I2g8=
=4ypf
-END PGP SIGNATURE-


signature.asc
Description: PGP signature

Bug#994215: Enable CONFIG_FSL_MC_UAPI_SUPPORT

[Vincent Blut]

Control: forcemerge -1 992988

Hi Christian,

Le 2021-09-13 21:28, Christian Svensson a écrit :
> Package: src:linux
> Version: linux/5.14.2-1~exp1
> 
> Please enable CONFIG_FSL_MC_UAPI_SUPPORT ("Management Complex (MC)
> userspace support") for arm64.
> This is needed to manage the onboard network interfaces on LX2160A-based
> boards such as the SolidRun HoneyComb LX2. Without this configuration
> option the onboard network interfaces can only be used in the state it is
> handed over to Linux by the bootloader. In practice this means that while
> e.g. lower speed interfaces may be set up, the faster SFP+ or QSFP28 ports
> could be left deactivated and thus not usable.
> 
> If you have any questions I am happy to try to answer them.

I'll work on this. Hopefully it'll be enabled in the next kernel upload.

> Regards,
> Chris

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#993865: please enable CONFIG_MT7915E

[Vincent Blut]

Hi Piotr,

Le 2021-09-07 15:08, Piotr Ożarowski a écrit :
> Package: src:linux
> Version: 5.10.28-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Please enable CONFIG_MT7915E (MediaTek MT7915E (PCIe) support) - looks
> like my new mini PCIe card needs this one.
> 5.14-1~exp2 from experimental doesn't have this one enabled as well
> 
> CONFIG_MT7915E was added in Linux 5.8

I sent a merge request¹ to fulfil your request. It also enables support for
other wireless MediaTek chips, notably the MT7921E which seems quite popular on
some laptops (e.g. ASUS G15, Acer Nitro 5).

> TIA

Cheers,
Vincent

¹ https://salsa.debian.org/kernel-team/linux/-/merge_requests/391


signature.asc
Description: PGP signature

Bug#908196: linux-image-4.9.0-8-armmp: Please set CONFIG_LEDS_PCA963X=m

[Vincent Blut]

Hi Reco,

Le 2021-08-20 11:16, Reco a écrit :
>   Hi, Vincent.
> 
> On Tue, Aug 17, 2021 at 04:41:20PM +0200, Vincent Blut wrote:
> > Package: src:linux
> > Followup-For: Bug #908196
> 
> > Is it still worthwhile to enable this option?
> 
> IMO yes. I have the thing sitting on my desk now, it runs Debian, and it
> serves its function.

Good to know.

> > So if this router does not run on Linux 5.13+, it's probably not worth
> > to enable this option.
> 
> I've just upgraded the device to bullseye, and installed
> linux-image-5.13.0-trunk from the experimental on it.
> I confirm that:
> 
> - the device boots successfully with that kernel.
> - both LAN and WAN ports work.
> - USB ports work too.
> 
> The kernel from the experimental just misses the usual:
> 
> - pca963x for WAN/WIFI leds
> - wifi.
> 
> Wifi requires out of tree module anyway, and its outside of the scope of
> this bug report.

OK! I'll send a merge request to the kernel team later today then.
> 
> Sincerely yours, Reco

Have a good day,
Vincent


signature.asc
Description: PGP signature

Bug#908196: linux-image-4.9.0-8-armmp: Please set CONFIG_LEDS_PCA963X=m

[Vincent Blut]

Package: src:linux
Followup-For: Bug #908196

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 moreinfo

Hi Reco,

Sorry it took so long to get back to you.

Is it still worthwhile to enable this option? Looking at device tree
information, the pca963x LED drivers seem to be used only by the
Linksys WRT1200AC (pca9635), other devices generally prefer to use GPIO
connected LEDs or a different expander (PCA9555, etc.)

So if this router does not run on Linux 5.13+, it's probably not worth to enable
this option.

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYRvKjwAKCRAQn1qAt/bg
AdBHAP9fDZdx3++JQg02zknaSgh+Wa/s5q8Ko5NRMKXlZtCgyQD+LZzzeUOTownu
JQFLgTD3dG/gPvf0oJE0WLcxhahSOQ0=
=X1j+
-END PGP SIGNATURE-

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Vincent Blut]

Version: 5.10.38-1

Hi,

One week has passed, as per your request I'm closing this bug report. Feel free
to reopen it if the issue recurs.

Cheers,
Vincent

Le 2021-06-21 09:34, Dekks Herton a écrit :
> problem resolved, i think.
> 
> new sof firmware update came out, not sure its arrival was more than a
> coincidence
> 
> 1 - disabling all intel vitrualisation options in the helix bios was enough
> to allow the fw to load thus  pavucontrol was now seeing input bars moving
> but no sound output.
> 
> 2 - ran alsactl -U init after i noticed ucm errors when running alsactl
> init.
> 
> 3 - aplay -l now sees all 3 cards when docked and 2 when tablet only.
> 
> 4 - alsamixer still showed the correct hw but a lot of outputs were muted,
> by enabling and disabling them all in sequence enabling the front dac
> enabled sount from the rt256 card and headphone socket.
> 
> I'm doing basic checks like detaching and reattaching to see if that
> affects the sound, so far ok Only noticeable thing is the fw gets reloaded
> 3 or 4 times a session, but doesn't seem to affect anything . If i have not
> commented more  in a week feel free to close the bug.
> 
> On Tue, 15 Jun 2021 at 11:43, Dekks Herton  wrote:
> 
> > Hi Vincent
> >
> > I'll kill the pipewire server, i would uninstall the packages but they are
> > hard deps for gnome now.
> >
> > Is the fw file catpt is trying to load the correct one? Is there new fw
> > files that come with catpt that have been forgotten?
> > Is there a listiing for the error codes -110 and -2, are they missing
> > files or read permission issues?
> >
> > Regards.
> >
> >
> >
> >
> > On Sun, 13 Jun 2021 at 18:08, Vincent Blut  wrote:
> >
> >> Hi,
> >>
> >> Le 2021-06-05 08:31, Dekks Herton a écrit :
> >> > Hi
> >> >
> >> > Additional alsa-info script output
> >>
> >> From a quick look, alsa-info reports that you're running both PipeWire and
> >> PulseAudio sound servers. While it may not be the root cause of your
> >> issue,
> >> if you want to stick with the former, please disable the latter:
> >> $ sudo systemctl --user disable --now pulseaudio.service pulseaudio.socket
> >>
> >> Note though that using PipeWire as a substitute to PulseAudio/JACK/ALSA in
> >> Debian 11 is considered experimental.
> >>
> >> Cheers,
> >> Vincent
> >>
> >


signature.asc
Description: PGP signature

Re: Re: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Vincent Blut]

Salut Philippe,

Le 2021-06-14 23:09, pham...@bluewin.ch a écrit :
> The boot is difficult, I have a recurring error message that turns in a loop.
> 
> journalctl -k | grep -Ei "iwl|bluetooth :
> 
> 
> root@portable-1:~# journalctl -k | grep -Ei "iwl|bluetooth"
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: enabling device 
> ( -> 0002)
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: firmware: 
> direct-loading firmware iwlwifi-ty-a0-gf-a0-59.ucode
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: api flags index 2 
> larger than supported by driver
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: TLV_FW_FSEQ_VERSION: 
> FSEQ Version: 93.8.63.28
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: loaded firmware 
> version 59.601f3a66.0 ty-a0-gf-a0-59.ucode op_mode iwlmvm
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: firmware: failed to 
> load iwl-debug-yoyo.bin (-2)
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: Detected Intel(R) 
> Wi-Fi 6 AX210 160MHz, REV=0x420
> jun 14 22:48:12 portable-1 kernel: Bluetooth: Core ver 2.22
> jun 14 22:48:12 portable-1 kernel: Bluetooth: HCI device and connection 
> manager initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: HCI socket layer initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: L2CAP socket layer initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: SCO socket layer initialized
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: firmware: failed to 
> load iwlwifi-ty-a0-gf-a0.pnvm (-2)
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: base HW address: 
> 54:14:f3:52:7b:e1
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
> information failed (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
> (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
> FW download
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0 wlp59s0: renamed from 
> wlan0
> jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP (Ethernet Emulation) ver 
> 1.3
> jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP filters: protocol multicast
> jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP socket layer initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
> information failed (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
> (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
> FW download
> jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
> information failed (-22)
> jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
> (-22)
> jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
> FW download
> 
> 
> systemctl status bluetooth.service :
> 
> 
> root@portable-1:~# systemctl status bluetooth.service
> ● bluetooth.service - Bluetooth service
>  Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor 
> preset: enabled)
>  Active: active (running) since Mon 2021-06-14 22:48:12 CEST; 10min ago
>Docs: man:bluetoothd(8)
>Main PID: 649 (bluetoothd)
>  Status: "Running"
>   Tasks: 1 (limit: 38030)
>  Memory: 2.6M
> CPU: 266ms
>  CGroup: /system.slice/bluetooth.service
>  └─649 /usr/libexec/bluetooth/bluetoothd
> 
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEScanIntervalConnect” in >
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEScanWindowConnect” in gr>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEMinConnectionInterval” i>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEMaxConnectionInterval” i>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEConnectionLatency” in gr>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEConnectionSupervisionTim>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEAutoconnecttimeout” in g>
> jun 14 22:48:12 portable-1 systemd[1]: Started Bluetooth service.
> jun 14 22:48:12 portable-1 bluetoothd[649]: Starting SDP server
> jun 14 22:48:12 portable-1 bluetoothd[649]: Bluetooth management interface 
> 1.18 initialized
> lines 1-22/22 (END)
> 
> 
> If I can be useful for make a test on my system, do not hesitate to ask me it.

Thanks for the logs, Phillipe. From the information I gathered, it seems
Linux 5.11 is required to get bluetooth work on this adapter.

Before rebasing on Linux 5.11 for the 21.04 release,

Re: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Vincent Blut]

Le 2021-06-14 22:19, pham...@bluewin.ch a écrit :
> Salut Vincent,
> 
> I have rebooted my Laptop after downgrading the firmware, this must have 
> restarted the iwlmvm and iwlwifi services, which allowed me to launch an 
> internet connection by Wifi.

OK, that's good to hear.

> But nothing to do for Bluetooth, it refuses to work.

Could you please attach the output of the following commands:
$ sudo journalctl -k | grep -Ei "iwl|bluetooth"
$ sudo systemctl status bluetooth.service


signature.asc
Description: PGP signature

Re: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Vincent Blut]

Salut Philippe,

Le 2021-06-14 21:48, pham...@bluewin.ch a écrit :
> Hello Andrei,
> I must have "my head in the moon" as we say in French :) I did not see the 
> download link...
> After uninstall of the new "firmware-iwlwifi_20210315-2_all.deb" and 
> installation of the old "firmware-iwlwifi_20210208-4_all.deb" the Wifi work 
> fine, but the Bluetooth not work, I dont have access to my Bluetooth devices 
> ;-(

Did you reload the iwlmvm and iwlwifi modules after downgrading the firmware?

> Best regards.
> Philippe

Cheers,
Vincent


signature.asc
Description: PGP signature

Re: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Vincent Blut]

Hi,

Le 2021-06-14 11:58, pham...@bluewin.ch a écrit :
> Hello and thank you for your message.
> I'm already using the "non-free" Debian images which contain firmware for 
> network cards etc.
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/amd64/iso-dvd/
> The package "firmware-iwlwifi_20210315-2_all.deb" is correctly installed, but 
> my Intel AX210 Wifi / Bluetooth card is not recognized and is not functional.
> This problem is extremely debilitating for me (severity: high). I bought this 
> hardware to run on Debian 10 with Backport and on Debian 11 but I cannot use 
> it.

There are reports in the wild stating that firmware version 22.40.0.2 (included
upstream in linux-firmware 20210315) for Intel AX210 caused some regressions.
Downgrading to firmware version 22.30.0.4 (included upstream in linux-firmware
20210208) seems to have fixed those regressions for the people affected by them.

Could you check if installing firmware_iwlwifi 20210208-4 [1] fixes your issue?

> Best regards.
> Philippe

Cheers,
Vincent

[1] 
https://snapshot.debian.org/archive/debian/20210313T203823Z/pool/non-free/f/firmware-nonfree/firmware-iwlwifi_20210208-4_all.deb


signature.asc
Description: PGP signature

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Vincent Blut]

Le 2021-06-13 20:08, Vincent Blut a écrit :
> Hi,
> 
> Le 2021-06-05 08:31, Dekks Herton a écrit :
> > Hi
> > 
> > Additional alsa-info script output
> 
> From a quick look, alsa-info reports that you're running both PipeWire and
> PulseAudio sound servers. While it may not be the root cause of your issue,
> if you want to stick with the former, please disable the latter:
> $ sudo systemctl --user disable --now pulseaudio.service pulseaudio.socket

Err: the above command should not be run with sudo.

> Note though that using PipeWire as a substitute to PulseAudio/JACK/ALSA in
> Debian 11 is considered experimental.
> 
> Cheers,
> Vincent


signature.asc
Description: PGP signature

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Vincent Blut]

Hi,

Le 2021-06-05 08:31, Dekks Herton a écrit :
> Hi
> 
> Additional alsa-info script output

From a quick look, alsa-info reports that you're running both PipeWire and
PulseAudio sound servers. While it may not be the root cause of your issue,
if you want to stick with the former, please disable the latter:
$ sudo systemctl --user disable --now pulseaudio.service pulseaudio.socket

Note though that using PipeWire as a substitute to PulseAudio/JACK/ALSA in
Debian 11 is considered experimental.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Vincent Blut]

Hi Salvatore,

Le 2021-06-04 21:39, Salvatore Bonaccorso a écrit :
> Hi,
> 
> On Fri, Jun 04, 2021 at 05:56:03PM +0200, Vincent Blut wrote:
> > Hi Dekks,
> > 
> > Le 2021-06-04 15:34, Dekks Herton a écrit :
> > > Hi Everyone,
> > > 
> > > As 5.10.7 was still in unstable 1 added it to my bullseye system via 
> > > adding
> > > SId to sources.list and pulling the image and relevant headers packages. 
> > > If
> > > there is a better or more correct way please advise.
> > > 
> > > Running 5.10.7 AFAIK installs the catpt modules correctly and all the hw
> > > associated correctly
> > > 
> > > 1) See aplayL txt file enc 2) GNOME shows a different slider layout
> > > 
> > > However there is still no sound on play back, parsing journalctl it seems
> > > the firmware IntcSST2.bin errors out and thus no firmware is loaded.
> > > 
> > > Jun 04 00:49:06 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware:
> > > direct-loading firmware intel/IntcSST2.bin
> > > Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware:
> > > direct-loading firmware intel/IntcSST2.bin
> > > Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware ready
> > > timeout
> > > Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: boot firmware
> > > failed: -110
> > > 
> > > I enclose a listing of the intel firmware folder showing IntcSST2.bin is
> > > there, Is it the correct firmware?
> > > 
> > > I've googled and cant find any info on this. Does intel have a github for
> > > this re-written driver?
> > > 
> > > Can the bug reopened or can you advise any possible solutions?
> > 
> > Do you have firmware-sof-signed installed? It may be needed on your system.
> 
> Reopened the bug for now (at least until the above question is
> clarified).

Dekks replied to me privately. Those SOF audio firmware aren't going to help in
this case since we don't provide support for SOF on Broadwell based platforms.
I already mentioned this in [1] but I had totally forgotten that.

Dekks, out of curiosity, could you please post the output of 'pacmd list-sinks'?

> Regards,
> Salvatore

Cheers,
Vincent

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986822#10


signature.asc
Description: PGP signature

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Vincent Blut]

Hi Dekks,

Le 2021-06-04 15:34, Dekks Herton a écrit :
> Hi Everyone,
> 
> As 5.10.7 was still in unstable 1 added it to my bullseye system via adding
> SId to sources.list and pulling the image and relevant headers packages. If
> there is a better or more correct way please advise.
> 
> Running 5.10.7 AFAIK installs the catpt modules correctly and all the hw
> associated correctly
> 
> 1) See aplayL txt file enc 2) GNOME shows a different slider layout
> 
> However there is still no sound on play back, parsing journalctl it seems
> the firmware IntcSST2.bin errors out and thus no firmware is loaded.
> 
> Jun 04 00:49:06 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware:
> direct-loading firmware intel/IntcSST2.bin
> Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware:
> direct-loading firmware intel/IntcSST2.bin
> Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware ready
> timeout
> Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: boot firmware
> failed: -110
> 
> I enclose a listing of the intel firmware folder showing IntcSST2.bin is
> there, Is it the correct firmware?
> 
> I've googled and cant find any info on this. Does intel have a github for
> this re-written driver?
> 
> Can the bug reopened or can you advise any possible solutions?

Do you have firmware-sof-signed installed? It may be needed on your system.

> Regards

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#977320: Updated information

[Vincent Blut]

Control: notfixed 977320 linux/5.10.9-1
Control: tags -1 moreinfo

Hi Pablo,

Le 2021-05-27 09:45, Pablo Bianucci a écrit :
> Hello,
> 
> I saw that the bug was fixed and tried the kernel, but it seems I did a bad
> diagnostic. As found in https://bugs.archlinux.org/task/55024, it seems that
> the required options for backlight control to work out-of-the-box in Cherry
> Trail tablets are:
> 
> CONFIG_PWM=y
> CONFIG_PWM_SYSFS=y
> CONFIG_PWM_CRC=y
> CONFIG_PWM_LPSS=m
> CONFIG_PWM_LPSS_PCI=m
> CONFIG_PWM_LPSS_PLATFORM=m

Among these options, only CONFIG_PWM_LPSS_PCI is missing in our kernel
configuration. That would be nice if you could build a kernel with this option
enabled to check that it allows you to correctly turn down the screen backlight
on the ASUS Transformer TA102.

> I apologize for the earlier misleading report...
> 
> Pablo B.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987281: linux-image-amd64: Enable i915 HDCP 2.2 support

[Vincent Blut]

Le 2021-04-30 13:41, Salvatore Bonaccorso a écrit :
> Hi Vincent,
> 
> On Fri, Apr 30, 2021 at 12:43:22PM +0200, Vincent Blut wrote:
> > Le 2021-04-30 09:12, Bastian Germann a écrit :
> > > Am 29.04.21 um 20:13 schrieb Vincent Blut:
> > > > Running 'xrandr --verbose' from Xorg should give you the supported
> > > > HDCP Content Type. If that reports "HDCP Type1" then support for HDCP 
> > > > 2.2 is
> > > > enabled.
> > > 
> > > Works as expected. Enabling the two configs is sufficient.
> > 
> > Thanks for confirming.
> > 
> > Salvatore, how do you feel about enabling those kernel options for Bullseye?
> > Should I open a MR?
> 
> As it was verified to work and it adds important additional hardware
> support, then yes please.

Done.
https://salsa.debian.org/kernel-team/linux/-/merge_requests/354

> I just find at this stage the part very important, we should try to
> enable additional HW support only if we have some verification that it
> adds value for the users, this is why I mentioned it last time.

Definitely agree!

> Regards,
> Salvatore

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987281: linux-image-amd64: Enable i915 HDCP 2.2 support

[Vincent Blut]

Le 2021-04-30 09:12, Bastian Germann a écrit :
> Am 29.04.21 um 20:13 schrieb Vincent Blut:
> > Running 'xrandr --verbose' from Xorg should give you the supported
> > HDCP Content Type. If that reports "HDCP Type1" then support for HDCP 2.2 is
> > enabled.
> 
> Works as expected. Enabling the two configs is sufficient.

Thanks for confirming.

Salvatore, how do you feel about enabling those kernel options for Bullseye?
Should I open a MR?


signature.asc
Description: PGP signature

Bug#987281: linux-image-amd64: Enable i915 HDCP 2.2 support

[Vincent Blut]

Hi,

Le 2021-04-29 19:01, Bastian Germann a écrit :
> Am 21.04.21 um 07:24 schrieb Salvatore Bonaccorso:
> > Were you able to verify that enabling those two as modules make it
> > work?
> 
> I honestly do not know how to check from userspace. xrandr has a Content
> Protection flag that is responsible for enabling/indicating HDCP usage. It
> works but I cannot verify it to be HDCP v2.2 (v1.4 works without those
> configs). libhdcpsdk has a HDCPSetProtectionLevel but I do not have the time
> right now to write a test program.

Running 'xrandr --verbose' from Xorg should give you the supported
HDCP Content Type. If that reports "HDCP Type1" then support for HDCP 2.2 is
enabled.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987773: enable netfilter modules

[Vincent Blut]

Control: reassign -1 src:linux
Control: tags -1 moreinfo

Hi Arturo,

Le 2021-04-29 12:09, Arturo Borrero Gonzalez a écrit :
> Source: linux
> Severity: normal
> 
> Dear maintainers,
> 
> thanks for your hard work with this package, it is really appreciated.
> 
> I noticed today the following missing netfilter modules in the kernel
> from testing/sid (by the time of this writing same version in both):
> 
> === 8< ===
> arturo@endurance:~ $ grep NETFILTER_EGRESS /boot/config-5.10.0-6-amd64 

That one is not available, see below.

> arturo@endurance:~ $ grep NETFILTER_XT_TARGET_NOTRACK 
> /boot/config-5.10.0-6-amd64 
> # CONFIG_NETFILTER_XT_TARGET_NOTRACK is not set

That one is deprecated upstream, do we really need it?

> I think CONFIG_NETFILTER_EGRESS is newer, but should be available since 5.7, 
> in
> upstream commit:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8537f78647c072bdb1a5dbe32e1c7e5b13ff1258

It has been reverted:
https://github.com/torvalds/linux/commit/357b6cc5834eabc1be7c28a9faae7da061df097d

 
> regards.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987638: linux-image-5.10.0-6-arm64: Missing kernel modules for Pine64's Pinebook Pro (usb-c, battery gauge, audio)

[Vincent Blut]

Salut Lionel,

Le 2021-04-27 11:27, Lionel Fourquaux a écrit :
> On Mon, Apr 26, 2021 at 11:19:29PM +0200, Vincent Blut wrote:
> > A merge request [1] has been proposed today to improve support for the 
> > Pinebook
> > Pro.
> 
> Thanks! (The merge request and this report are related.)
> 
> Some additional information: I (finally) managed to (cross-)build a Debian
> kernel package and test this:
>  * the battery gauge is working!

Great.

>  * the usb-c port gets its FUSB302 driver, but hits an error later:
> [8.656555] OF: graph: no port node found in /i2c@ff3d/fusb30x@22
>(This may be related to this patch to the DTD:
>   
> https://patchwork.kernel.org/project/linux-rockchip/patch/20200924063042.41545-1-...@endlessos.org/
>which made the monitor work, or possibly another missing driver.)

As it's not clear from your message, did you also enable CONFIG_TYPEC and
CONFIG_TYPEC_TCPM as modules?

>  * pulseaudio starts correctly (unlike before), but no sound (note: the
> internal switch controlling the audio jack is set in "serial port"mode;
> I'm not sure whether this affects the speakers, I will tryflipping the
> switch later).
> 
> So this is clearly an improvement (especially the battery gauge), but not a
> complete solution.
>
> Best regards,
> 
>   -- Lionel

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987638: linux-image-5.10.0-6-arm64: Missing kernel modules for Pine64's Pinebook Pro (usb-c, battery gauge, audio)

[Vincent Blut]

Hi,

Le 2021-04-26 22:46, Lionel Fourquaux a écrit :
> Package: src:linux
> Version: 5.10.28-1
> Severity: wishlist
> X-Debbugs-Cc: lionel.fourquaux+deb...@normalesup.org
> 
> Dear Maintainer,
> 
> I'm using Debian bullseye (currently unstable, soon to be stable) on 
> a Pine64 Pinebook Pro, installed using the official Debian installer.
> 
> Some devices are "not working" (meaning: nonfunctional, not detected by 
> the kernel):
>  * the usb-c port
>  * the battery gauge (cw2025) (note: dmesg shows error messages about a 
>missing power supply (the usb-c port?):
> [8.546079] power_supply cw2015-battery: Not all required supplies found, 
> defer probe
> [8.546089] cw2015 4-0062: Failed to register power supply
>)
>  * the audio output (built-in speakers).
> 
> After comparing the available kernel modules to the device tree, I believe 
> that this is caused by some missing modules in the kernel configuration. 
> I suggest enabling:
>   CONFIG_TYPEC_FUSB302
>   CONFIG_SND_SOC_ES8316

A merge request [1] has been proposed today to improve support for the Pinebook
Pro.

> Best regards,
> 
>   -- Lionel

Cheers,
Vincent

[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/352


signature.asc
Description: PGP signature

Bug#987019: (no subject)

[Vincent Blut]

Hey Josua,

Le 2021-04-26 17:32, Josua Mayer a écrit :
> Hi Vincent,
> 
> Thanks for your quick reply (which I failed to notice )
> So I did a test today with GPIO_MXC=m, and initramfs-tools in default
> configuration.
> 
> gpio_mxc module is included in initramfs automatically, and the system can
> boot from microSD just fine.
> Therefore, setting it as a module would do.

Awesome, thanks for testing. I'll update the merge request then.

> Yours sincerely
> Josua mayer

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987576: linux: Please enable CONFIG_SND_AUDIO_GRAPH_CARD

[Vincent Blut]

Le 2021-04-26 02:19, Diederik de Haas a écrit :
> Source: linux
> Version: 5.10.28-1
> Severity: wishlist
> 
> https://github.com/torvalds/linux/commit/ddf3fa8b8a16e076f247c115a73356b4b0d83a33
> is titled: "arm64: defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD"
> and the secondary commit msg is 
> "CONFIG_SND_AUDIO_GRAPH_CARD is needed to use HDMI sound with video"
> 
> According to the above mentioned URL, it's been part of arm64's
> defconfig since 2018-05-02 and included since kernel version 4.18-rc1.
> When researching how to get HDMI audio working on a Rock64, this was one
> of the settings they (on IRC freenode#linux-rockchip) said needed to be
> enabled for it to work.
> Checking on the config on this RPi3B+ indicated that it wasn't enabled
> on arm64, so hereby the request to enable it.

I sent a MR [1] to enable this option.

> I can imaging that it would also make sense to enable it on armhf, but I
> don't know if that's needed or maybe already enabled there, but I assume
> the Debian kernel maintainers can make an informed judgement on that.

It is already provided as a module on armhf.

> Cheers,
>   Diederik

Have a good day,
Vincent

[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/351


signature.asc
Description: PGP signature

Bug#987019: (no subject)

[Vincent Blut]

Hi Josua,

Le 2021-04-15 20:22, Josua Mayer a écrit :
> Dear Maintainers,
> 
> I have found a configuration change that makes the microSD port function
> again, verified by rebuilding 5.10.0-6:
> diff --git a/debian/config/armhf/config b/debian/config/armhf/config
> index bdf0fa118db1..7c39d00d7aae 100644
> --- a/debian/config/armhf/config
> +++ b/debian/config/armhf/config
> @@ -343,6 +343,7 @@ CONFIG_GPIO_DA9052=m
>  CONFIG_GPIO_PALMAS=y
>  CONFIG_GPIO_TWL4030=y
>  CONFIG_GPIO_TWL6040=y
> +CONFIG_GPIO_MXC=y
> 
>  ##
>  ## file: drivers/gpu/drm/Kconfig

Would compiling it as a module lead to the same result?

> Yours sincerely
> Josua Mayer

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#986848: linux: Please enable CONFIG_RMI4_F3A kernel config option

[Vincent Blut]

Hi Justin,

Le 2021-04-12 15:53, Justin King-Lacroix a écrit :
> Source: linux
> Severity: normal
> X-Debbugs-Cc: justi...@google.com
> 
> Kernel config option CONFIG_RMI4_F3A is not enabled by default on Debian 
> kernels.
> 
> It is required for touchpad "click" functionality to work on the Lenovo P1 
> Gen 2
> (among possibly other laptop models).

It is also required by the Lenovo Thinkpad X1 Extreme Gen 2.

> Can it please be enabled for future kernels?
> (Related: is there a reason why it isn't?)

I'll propose a merge request to the kernel team.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#986822: installation-reports: Debian 11 Breaks Analague sound on Thinkpad Helix 2nd Gen

[Vincent Blut]

Control: reassign -1 src:linux
Control: retitle -1 Missing support for Haswell/Broadwell platforms with I2S 
codec present

Hi,

Le 2021-04-12 13:40, dekks herton a écrit :
> Comments/Problems:
> 
> No analogue sound on Tablet from Broadwell-U from intel smart sound chipset -
> hw works on Buster but breaks on Bullseye
> Card0 on Buster no longer detected on Bullseye

Due to various bugs, Intel has rewritten the audio driver for Haswell/Broadwell
in Linux 5.10.
The bad news is that our kernel configuration does not seem to provide the
necessary bits to enable support for the Intel Audio DSP on Haswell U/Y and
Broadwell U.
I'm willing to provide a patch to fix this but the release of Bullseye is
approaching really fast so we might have to wait for the first point release.

> Tried installing Intel SOF drivers/firmware to no effect, forcing 
> snd_hda_intel
> via modprobe conf doesn't work either
> Broadwell-U works eith with HDA or SOF drivers theoretically.
> There is record of a kernel compilation flag to enable SOF functionality
> SND_SOC_SOF_BROADWELL_SUPPORT=Y breaking legacy and snd_hda_intel too.

We do not support SOF on Broadwell. This is even not recommended by upstream due
to some limitations related to DMA and suspend-resume so installing
firmware-sof-signed is of no use in your case.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#985687: linux-image-5.9.0-0.bpo.5-armmp: Set CONFIG_CAN_J1939=m

[Vincent Blut]

Hi Andrew,

Le 2021-03-22 04:26, Andrew Balmos a écrit :
> Package: src:linux
> Version: 5.9.15-1~bpo10+1
> Severity: normal
> 
> Dear Maintainer,
> 
> Please consider setting kernel option "CONFIG_CAN_J1939=m" for at least
> buster-backports armmp. Without this setting the CAN J1939 protocol can
> not be easily used.

buster-backports contains linux 5.10.19-1~bpo10+1 with CAN_J1939 enabled as a
module. Please upgrade!

> Regards
> Andrew

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#981186: linux: Enable CMN-600 interconnect on arm64

[Vincent Blut]

Le 2021-03-17 19:24, Wookey a écrit :
> On 2021-03-17 19:43 +0100, Vincent Blut wrote:
> > Le 2021-03-17 15:49, Wookey a écrit :
> > > On 2021-03-17 14:52 +0100, Vincent Blut wrote:
> > > > Le 2021-01-27 12:57, Wookey a écrit :
> > > > > Version: Please enable ARM CMN-600 power management on arm64
> > > > >
> > > > > This requires CONFIG_ARM_CMN=y
> > > >
> > > > Does it really have to be built-in instead of being provided as a 
> > > > module? Last I
> > > > checked, Fedora and Ubuntu provide it as a module.
> > > 
> > > No it should really be a module. Perf is driven from userspace so you
> > > never need to use it before modules can be loaded.
> > 
> > Agreed.
> 
> > > I see that
> > > CONFIG_THUNDERX2_PMU=y
> > > CONFIG_ARM_SMMU_V3_PMU=y
> > > are also set as builtins. That's probably wrong too.
> > 
> > It seems your arm64 kernel config deviates from the one we provide in 
> > Debian.
> > CONFIG_THUNDERX2_PMU is compiled as a module while CONFIG_ARM_SMMU_V3_PMU is
> > not set, at least in linux 5.10.19-1.
> 
> Hmm. I was looking at the (built, with CONFIG_ARM_CMN=y) sources for
> 5.10.9-1 and the (unbuilt) sources for 5.10.19-1. So yes, slightly
> different and the built version is not up to date any more.
> 
> If we already have CONFIG_THUNDERX2_PMU=m already then that's great
> (Ah yes - that's the upstream default).  Adding
> CONFIG_ARM_SMMU_V3_PMU=m would be good too. Adding it as a module
> should be pretty harmless then at least it's available? I'll set off a
> build now to check it works.

Enabling ARM_SMMU_V3_PMU as a module should be harmless, indeed.

> > > […]
> > 
> > > I also checked the state of the other perf configs with the arm kernel 
> > > team
> > > and got feedback that we have all the ones that should sensibly be set 
> > > set once
> > > CONFIG_ARM_CMN=m
> > > and
> > > CONFIG_THUNDERX2_PMU=m
> > > is added
> > 
> > This means updating the arm64 kernel config to only include ARM_CMN as a 
> > module.
> > To me it is acceptable for Bullseye as this seems uncontroversial, but note 
> > that
> > I can't speak for the kernel team.
> 
> Will you ask them, or should I?

I can send merge requests to enable ARM_CMN and ARM_SMMU_V3_PMU if you wish.

> It seems like prodding someone would be good as this was filed back on 27th
> jan and there have been uploads since, so I guess no-one has noticed till now.

I have been contributing for some time to help the kernel team, but I must admit
I didn't notice this one (and probably many others).

> > > Upstream enables
> > > CONFIG_FSL_IMX8_DDR_PMU=m
> > > by default too. IMX8 hardware is available so we should probably turn 
> > > this on too
>
> > Contrary to Ubuntu, we do not provide support for the i.MX8M SoC family,
> > so enabling this option in the arm64 kernel config is not an option, right?
> 
> Ah OK. I didn't realise IMX8 was not enabled in the debian kernel (A
> subject for a different bug). In that case, no this is not
> appropriate.

I wanted to work on this a few months ago, but sadly I was unable to obtain a
i.MX8 SBC.

> Wookey
> -- 
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#981186: linux: Enable CMN-600 interconnect on arm64

[Vincent Blut]

Le 2021-03-17 15:49, Wookey a écrit :
> On 2021-03-17 14:52 +0100, Vincent Blut wrote:
> > Control: tags -1 moreinfo
> >
> > Hi Wookey,
> >
> > Le 2021-01-27 12:57, Wookey a écrit :
> > > Source: linux
> > > Version: Please enable ARM CMN-600 power management on arm64
> > > Severity: normal
> > > Tags: patch
> > >
> > > Current arm hardware such as graviton2 (AWS arm64 hardware) has
> > > 'Coherent Mesh Network' interconnect (between components in a
> > > soc). It's important that support for this is built in the kernel so
> > > it can be used.
> > >
> > > This requires CONFIG_ARM_CMN=y
> >
> > Does it really have to be built-in instead of being provided as a module? 
> > Last I
> > checked, Fedora and Ubuntu provide it as a module.
> 
> No it should really be a module. Perf is driven from userspace so you
> never need to use it before modules can be loaded.

Agreed.

> I just did it like this because the other settings here are set as
> built-ins too and this seemed less disruptive. (If we make it a module
> we'll need to make sure it gets included in the right module package -
> I'm not sure if that need tweaking somewhere else in the build system)
> 
> I see that
> CONFIG_THUNDERX2_PMU=y
> CONFIG_ARM_SMMU_V3_PMU=y
> are also set as builtins. That's probably wrong too.

It seems your arm64 kernel config deviates from the one we provide in Debian.
CONFIG_THUNDERX2_PMU is compiled as a module while CONFIG_ARM_SMMU_V3_PMU is
not set, at least in linux 5.10.19-1.

> […]

> I also checked the state of the other perf configs with the arm kernel team
> and got feedback that we have all the ones that should sensibly be set set 
> once
> CONFIG_ARM_CMN=m
> and
> CONFIG_THUNDERX2_PMU=m
> is added

This means updating the arm64 kernel config to only include ARM_CMN as a module.
To me it is acceptable for Bullseye as this seems uncontroversial, but note that
I can't speak for the kernel team.

> Upstream enables
> CONFIG_FSL_IMX8_DDR_PMU=m
> by default too. IMX8 hardware is available so we should probably turn this on 
> too

Contrary to Ubuntu, we do not provide support for the i.MX8M SoC family,
so enabling this option in the arm64 kernel config is not an option, right?


signature.asc
Description: PGP signature

Bug#981186: linux: Enable CMN-600 interconnect on arm64

[Vincent Blut]

Control: tags -1 moreinfo

Hi Wookey,

Le 2021-01-27 12:57, Wookey a écrit :
> Source: linux
> Version: Please enable ARM CMN-600 power management on arm64
> Severity: normal
> Tags: patch
> 
> Current arm hardware such as graviton2 (AWS arm64 hardware) has
> 'Coherent Mesh Network' interconnect (between components in a
> soc). It's important that support for this is built in the kernel so
> it can be used.
> 
> This requires CONFIG_ARM_CMN=y

Does it really have to be built-in instead of being provided as a module? Last I
checked, Fedora and Ubuntu provide it as a module.

> This explains what the feature is:
> https://www.arm.com/products/silicon-ip-system/corelink-interconnect/cmn-600
> Graviton2:
> https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd
> 
> patch attached:
> --- debian/config/arm64/config~   2021-01-27 04:34:51.359552398 +
> +++ debian/config/arm64/config2021-01-27 04:53:11.922998842 +
> @@ -942,6 +942,7 @@
>  CONFIG_ARM_CCI400_PMU=y
>  CONFIG_ARM_CCI5xx_PMU=y
>  CONFIG_ARM_CCN=y
> +CONFIG_ARM_CMN=y
>  CONFIG_QCOM_L2_PMU=y
>  CONFIG_QCOM_L3_PMU=y
>  CONFIG_XGENE_PMU=y

> --- debian/config/arm64/config~   2021-01-27 04:34:51.359552398 +
> +++ debian/config/arm64/config2021-01-27 04:53:11.922998842 +
> @@ -942,6 +942,7 @@
>  CONFIG_ARM_CCI400_PMU=y
>  CONFIG_ARM_CCI5xx_PMU=y
>  CONFIG_ARM_CCN=y
> +CONFIG_ARM_CMN=y
>  CONFIG_QCOM_L2_PMU=y
>  CONFIG_QCOM_L3_PMU=y
>  CONFIG_XGENE_PMU=y

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#983586: linux-image-5.10.0-3-amd64: Please configure kernel with CONFIG_AMD_MEM_ENCRYPT=y

[Vincent Blut]

Hi,

Le 2021-02-26 20:26, bs.net a écrit :
> Package: src:linux
> Version: 5.10.13-1
> 
> Dear Maintainer,
> 
> please consider to set the Linux kernel option "CONFIG_AMD_MEM_ENCRYPT=y".
> 
> Without that option it is not possible to enable the memory encryption for AMD
> Secure Memory Encryption (SME).

I sent a merge request [1] to enable this feature, but it was deemed a bit late
for Bullseye.

> Thank you very much.
> 
> With kind regards

Cheers,
Vincent

[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/322


signature.asc
Description: PGP signature

Bug#890343: linux: make fq_codel default for default_qdisc

[Vincent Blut]

Hi,

Le 2021-01-21 00:43, Ben Hutchings a écrit :
> On Wed, 2021-01-20 at 14:46 -0800, Noah Meyerhans wrote:
> > On Wed, Jan 20, 2021 at 11:39:16PM +0100, Vincent Blut wrote:
> > > > We could do that.  However, in the past (earlier in this bug,
> > > > even) it's
> > > > been pointed out that other packages should not be responsible
> > > > for
> > > > setting kernel policies, so changes like this should be the
> > > > responsibility of the kernel packages.  That seems like a
> > > > sensible
> > > > position to take.
> > > 
> > > If this is the position of the kernel team, then fine. But some
> > > packages *do*
> > > tweak kernel parameters using the sysctl interface mechanism. So
> > > does the kernel
> > > team provides documention about what is acceptable?
> > 
> > I think the distinction is that the other packages that tweak sysctl
> > values don't claim to be doing so on behalf of the kernel team.  If
> > the
> > kernel team is responsible for the values being set, then the
> > settings
> > should come from a package that the kernel team owns, not some other
> > package.
> 
> Right, maybe in linux-base?  Although that might annoy derivatives that
> want different defaults.
> 
> procps is the wrong place, not just because it's out of our hands, but
> because systemd applies sysctl configuration now and procps is
> optional.

Is there a definitive answer from the kernel team about how this should be
implemented? In the meantime, Noah sent [1].

> Ben.

Cheers,
Vincent

[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/309/diffs


signature.asc
Description: PGP signature

Re: Include J1939 module in kernel build

[Vincent Blut]

Hi Rene,

Le 2021-02-14 22:15, reneherr...@gmail.com a écrit :
> Dear Maintainer,
> 
> I don't usually get to thank folks for everything that is made available to 
> the world, so a big and sincere thank you, despite not knowing who you are.
> 
> This is most definitely in the wishlist bucket as it is non-essential.  It is 
> however very low lying fruit.
> 
> J1939 and other derived protocols such as NMEA 2000 are widely used in the 
> automotive and marine industries to name a few.
> 
> I myself live on a sailboat and use various pieces of software that get 
> supercharged when they can collect data from other devices on the boat.
> 
> For example, I have an AIS and GPS devices on my NMEA 2000 bus that 
> broadcasts the boat's position and that of other vessels (avoiding large 
> metallic objects out at sea is a good thing).  The can-j1939 Linux Kernel 
> module does all the heavy lifting involved with the protocol which sits on 
> top of CAN and allows you to easily send and receive messages with hardware 
> devices already supported in Debian Linux (ex: CAN Bus Analyzer from 
> Microchip).  This module enables pulling that data and feeding it to a chart 
> plotter such as OpenCPN.  In simple terms, seeing a chart is nice, seing a 
> chart displaying your position and that of other boats is *very* nice, having 
> an alarm go off when a process detects a collision is eminant is *pure 
> awesomeness* as it can literally save your life.
> 
> The currect workaround is simply to pull the sources and recompiling the 
> kernel, which is not a huge deal, but it is a little anoying as this (idealy) 
> needs to be repeated every update.
> 
> Thanks for taking the time to read and consider this,
> 
> Rene

I sent a merge request for this:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/329


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#968181: 968181 and 968188 are fixed in 5.10.5-1

[Vincent Blut]

Hi Ryutaroh,

Le 2021-01-24 04:21, Ryutaroh Matsumoto a écrit :
> Control: reopen 968181
> Control: reopen 968188
> Control: found 968181 5.10.9-1
> Control: found 968188 5.10.9-1
> 
>  968181 missing DRI/DRM support on Raspberry Pi
>  968188 4K display resolution is not recognized with Raspberry Pi 4B
> 
> Since gpu/drm/vc4.ko is disabled in 5.10.9-1 while it was enabled in 5.10.5-1,
> the above two issues have come back (I unwelcome them...).

Indeed, CONFIG_DRM_VC4=m has been mistakenly removed from the arm64 kernel
configuration. I’ll propose a merge request to fix this.

> Best regards, Ryutaroh Matsumoto

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#980214: linux-image-5.10.0-1-arm64: please enable CONFIG_CRYPTO_NHPOLY1305_NEON

[Vincent Blut]

Le 2021-01-23 18:04, Diederik de Haas a écrit :
> On zaterdag 23 januari 2021 17:00:25 CET Vincent Blut wrote:
> > Hi,
> > 
> > Le 2021-01-23 15:00, Diederik de Haas a écrit :
> > > Control: reopen -1
> > > Control: found -1 5.10.9+1
> > > 
> > > On zaterdag 23 januari 2021 11:05:23 CET Ard Biesheuvel wrote:
> > > > On Sat, 16 Jan 2021 at 18:27, Ard Biesheuvel  wrote:
> > > > > On Sat, 16 Jan 2021 at 18:24, Diederik de Haas 
> > > 
> > > wrote:
> > > > > > On zaterdag 16 januari 2021 10:42:19 CET Ard Biesheuvel wrote:
> > > > > > > Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64
> > > > > > > builds
> > > > > > 
> > > > > > Is there a reason why it shouldn't be included in armhf builds? If
> > > > > > not,
> > > > > > then I'd like to see it enabled there too.
> > > > > > (And possibly in linux-image-rpi on armel as well?)
> > > > > 
> > > > > Agreed for armhf, assuming CONFIG_CRYPTO_ADIANTUM is already enabled
> > > > > on those platforms too. For armel, it depends on whether kernel mode
> > > > > NEON is already enabled in the first place.
> > > > 
> > > > This is enabled now for armhf but not for arm64:
> > > > 
> > > > linux-signed-arm64 (5.10.9+1) unstable; urgency=medium
> > > > ...
> > > > * [arm] Enable CRYPTO_NHPOLY1305_NEON. (closes: #980214)
> > > 
> > > I first thought that '[arm]' was a shorthand for various ARM
> > > architectures, but I just confirmed that it is indeed not fixed/enabled
> > > in arm64:
> > > # grep CRYPTO_NHPOLY1305_NEON /boot/config-5.10.0-2-arm64
> > > # CONFIG_CRYPTO_NHPOLY1305_NEON is not set
> > 
> > Indeed. I just sent a MR¹ to fix this.
> > 
> > Cheers,
> > Vincent
> > 
> > ¹ https://salsa.debian.org/kernel-team/linux/-/merge_requests/312
> 
> $ grep CRYPTO_NHPOLY1305_NEON /boot/config-5.10.0-2-armmp
> 
> didn't give a result, so it looks like it's also not enabled on armhf?

Oh I see, support for NEON in kernel mode is disabled.


signature.asc
Description: PGP signature

Bug#980214: linux-image-5.10.0-1-arm64: please enable CONFIG_CRYPTO_NHPOLY1305_NEON

[Vincent Blut]

Hi,

Le 2021-01-23 15:00, Diederik de Haas a écrit :
> Control: reopen -1
> Control: found -1 5.10.9+1
> 
> On zaterdag 23 januari 2021 11:05:23 CET Ard Biesheuvel wrote:
> > On Sat, 16 Jan 2021 at 18:27, Ard Biesheuvel  wrote:
> > > On Sat, 16 Jan 2021 at 18:24, Diederik de Haas  
> wrote:
> > > > On zaterdag 16 januari 2021 10:42:19 CET Ard Biesheuvel wrote:
> > > > > Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64
> > > > > builds
> > > > 
> > > > Is there a reason why it shouldn't be included in armhf builds? If not,
> > > > then I'd like to see it enabled there too.
> > > > (And possibly in linux-image-rpi on armel as well?)
> > > 
> > > Agreed for armhf, assuming CONFIG_CRYPTO_ADIANTUM is already enabled
> > > on those platforms too. For armel, it depends on whether kernel mode
> > > NEON is already enabled in the first place.
> > 
> > This is enabled now for armhf but not for arm64:
> > 
> > linux-signed-arm64 (5.10.9+1) unstable; urgency=medium
> > ...
> > * [arm] Enable CRYPTO_NHPOLY1305_NEON. (closes: #980214)
> 
> I first thought that '[arm]' was a shorthand for various ARM architectures, 
> but 
> I just confirmed that it is indeed not fixed/enabled in arm64:
> # grep CRYPTO_NHPOLY1305_NEON /boot/config-5.10.0-2-arm64 
> # CONFIG_CRYPTO_NHPOLY1305_NEON is not set

Indeed. I just sent a MR¹ to fix this.

Cheers,
Vincent

¹ https://salsa.debian.org/kernel-team/linux/-/merge_requests/312


signature.asc
Description: PGP signature

Bug#890343: linux: make fq_codel default for default_qdisc

[Vincent Blut]

Le 2021-01-20 14:46, Noah Meyerhans a écrit :
> On Wed, Jan 20, 2021 at 11:39:16PM +0100, Vincent Blut wrote:
> > > We could do that.  However, in the past (earlier in this bug, even) it's
> > > been pointed out that other packages should not be responsible for
> > > setting kernel policies, so changes like this should be the
> > > responsibility of the kernel packages.  That seems like a sensible
> > > position to take.
> > 
> > If this is the position of the kernel team, then fine. But some packages 
> > *do*
> > tweak kernel parameters using the sysctl interface mechanism. So does the 
> > kernel
> > team provides documention about what is acceptable?
> 
> I think the distinction is that the other packages that tweak sysctl
> values don't claim to be doing so on behalf of the kernel team.  If the
> kernel team is responsible for the values being set, then the settings
> should come from a package that the kernel team owns, not some other
> package.

Makes sense!

> AFAIK, there are no guidelines or policy anywhere in Debian about
> whether or not a package can provide its own sysctl settings.

That would be nice to have a statement on this, though.

> noah

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#890343: linux: make fq_codel default for default_qdisc

[Vincent Blut]

Le 2021-01-20 13:58, Noah Meyerhans a écrit :
> On Wed, Jan 20, 2021 at 10:22:16PM +0100, Vincent Blut wrote:
> > My proposal would differ from yours though in that it would not touch the 
> > kernel
> > configuration but would instead consist in patching procps to provide a
> > configuration file (let's say default_qdisc.conf) to set the value of the
> > net.core.default_qdisc variable to fq_codel via sysctl.
> > This would allow to benefit from FQ_Codel without depending on a specific 
> > Linux
> > version.
> 
> We could do that.  However, in the past (earlier in this bug, even) it's
> been pointed out that other packages should not be responsible for
> setting kernel policies, so changes like this should be the
> responsibility of the kernel packages.  That seems like a sensible
> position to take.

If this is the position of the kernel team, then fine. But some packages *do*
tweak kernel parameters using the sysctl interface mechanism. So does the kernel
team provides documention about what is acceptable?


signature.asc
Description: PGP signature

Bug#890343: linux: make fq_codel default for default_qdisc

[Vincent Blut]

Hi Noah,

Le 2021-01-07 16:12, Noah Meyerhans a écrit :
> On Thu, Apr 23, 2020 at 03:34:06PM -0700, Matt Taggart wrote:
> > #890343 was originally opened against systemd asking to install the upstream
> > systemd sysctl.d/50-default.conf file that sets:
> > 
> > net.core.default_qdisc = fq_codel
> > 
> > As explained in #950701 (and the systemd debian changelog) the debian
> > systemd maintainers felt that systemd in debian should not be changing
> > kernel policies (and I agree).
> > So #890343 was reassigned to linux to consider changing the default.
> > 
> > fq_codel is better in every way than pfifo_fast and I am unaware of any
> > reason why it would not be a better default. (but don't trust me, ask the
> > kernel networking experts)
> > 
> > Can we change it?
> 
> I strongly agree that we should make this change for the bullseye
> release.
> 
> I'm looking into provding a patch to implement the switch to fq_codel by
> default, but it appears to require something more than just a kernel
> config change.  I have tried the following with the 5.10 kernel from the
> current sid branch:
> 
> CONFIG_NET_SCH_FQ_CODEL=m
> CONFIG_DEFAULT_FQ_CODEL=y
> CONFIG_DEFAULT_NET_SCH="fq_codel"
> 
> Then we don't see any change at all to the qdisc in use:
> 
> admin@ip-10-0-0-162:~$ grep -i fq_codel /boot/config-$(uname -r)
> CONFIG_NET_SCH_FQ_CODEL=m
> CONFIG_DEFAULT_FQ_CODEL=y
> CONFIG_DEFAULT_NET_SCH="fq_codel"
> admin@ip-10-0-0-162:~$ /sbin/sysctl net.core.default_qdisc
> net.core.default_qdisc = pfifo_fast
> admin@ip-10-0-0-162:~$ tc qdisc show dev ens5
> qdisc mq 0: root
> qdisc pfifo_fast 0: parent :2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> qdisc pfifo_fast 0: parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> admin@ip-10-0-0-162:~$ ip link show dev ens5
> 2: ens5:  mtu 9001 qdisc mq state UP mode 
> DEFAULT group default qlen 1000
> link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff
> altname enp0s5
> 
> If we statically link the fq_codel module into the kernel, then we see:
> 
> admin@ip-10-0-0-162:~$ grep -i fq_codel /boot/config-$(uname -r)
> CONFIG_NET_SCH_FQ_CODEL=y
> CONFIG_DEFAULT_FQ_CODEL=y
> CONFIG_DEFAULT_NET_SCH="fq_codel"
> admin@ip-10-0-0-162:~$ /sbin/sysctl net.core.default_qdisc
> net.core.default_qdisc = fq_codel
> admin@ip-10-0-0-162:~$ /sbin/tc qdisc show dev ens5
> qdisc mq 0: root
> qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms 
> interval 100ms memory_limit 32Mb ecn drop_batch 64
> qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms 
> interval 100ms memory_limit 32Mb ecn drop_batch 64
> admin@ip-10-0-0-162:~$ ip link show dev ens5
> 2: ens5:  mtu 9001 qdisc mq state UP mode 
> DEFAULT group default qlen 1000
> link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff
> altname enp0s5
> 
> So in this case, we have fq_codel configured, but not as the root
> qdisc for the interface.  If we manually set it:
> 
> admin@ip-10-0-0-162:~$ sudo /sbin/tc qdisc add root dev ens5 fq_codel
> 
> Then we get the following configuration:
> 
> admin@ip-10-0-0-162:~$ /sbin/tc qdisc show dev ens5
> qdisc fq_codel 8001: root refcnt 3 limit 10240p flows 1024 quantum 9015 
> target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
> admin@ip-10-0-0-162:~$ ip link show dev ens5
> 2: ens5:  mtu 9001 qdisc fq_codel state UP 
> mode DEFAULT group default qlen 1000
> link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff
> altname enp0s5
> 
> I believe that this is what we want.  Is that accurate?
> 
> The recent thread at 
> https://www.mail-archive.com/netdev@vger.kernel.org/msg380410.html
> also seems relevant.

I was about to start a thread on the debian-kernel ML about switching from
pfifo_fast to FQ_Codel when I stumble across this bug report.

My proposal would differ from yours though in that it would not touch the kernel
configuration but would instead consist in patching procps to provide a
configuration file (let's say default_qdisc.conf) to set the value of the
net.core.default_qdisc variable to fq_codel via sysctl.
This would allow to benefit from FQ_Codel without depending on a specific Linux
version.

Opinion?

> noah

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#980164: tries resume

[Vincent Blut]

Hi Alain,

Le 2021-01-20 12:52, alain a écrit :
> tried this :
> 
> - firmware-amd-graphics 20201118-1 testing
> 
> - firmware-amd-graphics 20201218-1 sid
> 
> - firmware-amd-graphics 20201218-1 testing
> 
> - firmware-amd-graphics 22021218-2 (sid)
> 
> - amdgpu git
> 
> - amdgpu-pro 20.45
> 
> - mesa 21 dev (git)
> 
> nothing works  .
> 
> don't know where is the problem ?
> 
> in the kernel , in the firmware ? both ?
> 
> this card works perfectly on ubuntu 20.10 kernel 5.10
> 
> an english forum told me to modify amdgpu ' gcn 3.0 in the kernel
> 
> tried in kernel 5.10.8
> 
> but doesn't work no more .
> 
> wondering . what's happened ?

AFAICS, CONFIG_DRM_AMD_DC_DCN3_0 is missing in the kernel.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#978944: linux-image-5.10.0-1-amd64-unsigned: Please enable CONFIG_PCENGINES_APU2

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2020-12-31T23:52+0100, Maximilian Wilhelm a écrit :

Package: src:linux
Version: 5.10.4-1
Severity: wishlist

Dear Maintainer,

while booting the latest kernels on PCengins APU2 boards I noticed to following
entry in the kernel log:

leds_apu: No PC Engines APUv1 board detected. For APUv2,3 support, enable 
CONFIG_PCENGINES_APU2

It would be nice to have supporte for fiddling with the LEDs of the board so I
would like to ask you to enable above config option in future kernels if there
is no reasons to not to :)


CONFIG_PCENGINES_APU2 is already enabled. Could you please check that 
the "pcengines-apuv2" module is correctly loaded?



Thank you for you work!

Kind regards
Max


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#976791: closed by Debian FTP Masters (reply to Bastian Blank ) (Bug#976791: fixed in linux 5.10~rc7-1~exp1)

[Vincent Blut]

Control: reopen -1

Le 2020-12-28T13:01-0500, Matt Corallo a écrit :
Note that the CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH in the x86 
config is bogus - CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH depends on 
CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES which is not set.


Good catch Matt! I sent a merge request to fix this.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#977438: linux: Pls. consider DRM_VC4_HDMI_CEC

[Vincent Blut]

Hi,

Le 2020-12-15T15:21+0900, Ryutaroh Matsumoto a écrit :

Source: linux
Version: 5.9.11-1
Severity: wishlist

Dear Maintainer,

Could you consider to enable CONFIG_DRM_VC4_HDMI_CEC
for arm64 and possibly armhf?
It should enable cec-client command in Debian cec-util to
control some CEC-capable devices connected via HDMI.


I sent a merge request to enable this [1]. I see that in a follow-up 
email you're asking for more configuration options to be enabled; It 
would probably be better to open a new bug report for those.



Best regards, Ryutaroh Matsumoto


Cheers,
Vincent


[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/299


signature.asc
Description: PGP signature

Re: Modern TC schedulers in 5.8+ kernels

[Vincent Blut]

Hi,

Le 2020-11-26T01:50+0300, engine a écrit :

# CONFIG_NET_SCH_FQ_PIE is not set
# CONFIG_NET_SCH_ETS is not set


These are now enabled in Linux 5.10~rc7-1~exp1.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#977004: Please enable CONFIG_ATH11K for the XPS 13 9310

[Vincent Blut]

Hi Paul,

Le 2020-12-09T17:48-0500, Paul Tagliamonte a écrit :

Package: linux
Severity: wishlist
thanks

Hello Linux maintainers,

The spiffy new Dell XPS 13 9310 is shipping, but is not sold as supporting
linux yet -- but appears to work great, with the exception of the Qualcomm
Technologies 802.11ax chipset.

I installed Linux from experimental, and am able to confirm the driver is
not loaded. I believe CONFIG_ATH11K could be enabled to support this
platform.

Happy to reproduce and/or try images out to confirm! This isn't a daily
machine yet.


Newer version of firmware-atheros will be needed too since the one we 
currently provide contains no ath11k firmware blobs.



Thank you very much!
 Paul


Cheers,
Vincent


signature.asc
Description: PGP signature

Re: Modern TC schedulers in 5.8+ kernels

[Vincent Blut]

Hi Evgeniy,

On 2020-11-26T01:50+0300, engine wrote:


Hello
Kernel 5.8 has ETS and FQ_PIE schedulers disabled:
 
# CONFIG_NET_SCH_FQ_PIE is not set
# CONFIG_NET_SCH_ETS is not set
 
 
Are there good reasons behind this?


I opened a merge request [1] to enable these queueing disciplines.


--
Regards, Evgeniy


Cheers,
Vincent

[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/292


signature.asc
Description: PGP signature

Re: Uploading linux (5.9.1-1)

[Vincent Blut]

Hi,

On 2020-10-17T20:32+0300, Georgi Naplatanov wrote:

On 10/17/20 3:25 PM, Salvatore Bonaccorso wrote:

Hi

I would like to upload linux version 5.9.1-1 to unstable later today.

This is a new upstream version and therefore involves an ABI bump.



Hi Salvatore,

do you know which Linux kernel version will be the next LTS supported by
kernel.org - 5.9, 5.10 or ?


Greg Kroah-Hartman confirmed that Linux 5.10 is going to be the next
LTS release.


Kind regards
Georgi


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#896165: linux: request packaging of bpftool

[Vincent Blut]

On Mon, Nov 19, 2018 at 11:34:26PM -0800, Noah Meyerhans wrote:

On Fri, Apr 20, 2018 at 02:07:40PM +0200, Simon Horman wrote:

I would like to request packaging of bpftool which has been
included in upstream Linux tree since v4.15-rc1. I expect this can
be done in a similar manner to the way that perf, also present in
the upstream Linux kernel tree, is packaged.


[…]

Is the plan for buster to include 4.18, or 4.19? Or something else?


According to the last kernel team meeting¹, Linux 4.19 will be used for 
Buster.



noah


Cheers,
Vincent


¹ 
http://meetbot.debian.net/debian-kernel/2018/debian-kernel.2018-10-02-18.33.html



signature.asc
Description: PGP signature

Bug#891463: linux-image-4.15.0-1-amd64: Regression from 4.13 to 4.14 due to the use of alternate fixed mode for eDP

[Vincent Blut]

Package: src:linux
Version: 4.15.4-1
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

The introduction of commit dc911f5bd8aa (drm/i915/edp: Allow alternate 
fixed mode for eDP if available.) causes severe performance degradations 
on my system, especially noticeable while playing video games. There are 
some workarounds though:

- - Setting the screen refresh rate below 60 Hz. Might be inconvenient in 
  certain circumstances.
- - Using Jim Bride’s patch¹. According to some people it cures the issue.  
  Contrary to the above workaround, this one I did not test. It should 
  be noted that it seems to have fall through the cracks as I don’t see 
  any reference to it in Linus' tree.

As we are going to use 4.15.x for some more time, I propose that we 
revert the aforementioned commit until a solution is found upstream.  
Thought?

Cheers,
Vincent


¹ https://bugs.freedesktop.org/attachment.cgi?id=135277



- -- Package-specific info:
** Version:
Linux version 4.15.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-3)) #1 SMP Debian 4.15.4-1 (2018-02-18)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.15.0-1-amd64 
root=UUID=05885802-d6d1-4a25-b7ef-8c3e00c144b0 ro quiet pcie_aspm=force 
elevator=deadline intel_pstate=disable apparmor=1 security=apparmor

** Tainted: U (64)
 * Userspace-defined naughtiness.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: ASUSTeK COMPUTER INC.
product_name: UX31A
product_version: 1.0   
chassis_vendor: ASUSTeK COMPUTER INC.
chassis_version: 1.0   
bios_vendor: American Megatrends Inc.
bios_version: UX31A.219
board_vendor: ASUSTeK COMPUTER INC.
board_name: UX31A
board_version: 1.0   

** Loaded modules:
xt_CHECKSUM
iptable_mangle
devlink
ipt_MASQUERADE
nf_nat_masquerade_ipv4
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
xt_tcpudp
bridge
stp
llc
iptable_filter
ctr
ccm
fuse
arc4
binfmt_misc
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_core
intel_rapl
btusb
videodev
x86_pkg_temp_thermal
iTCO_wdt
intel_powerclamp
coretemp
media
btrtl
iTCO_vendor_support
asus_nb_wmi
btbcm
asus_wmi
kvm_intel
btintel
sparse_keymap
rtsx_usb_ms
bluetooth
memstick
kvm
irqbypass
drbg
crct10dif_pclmul
snd_hda_codec_hdmi
ansi_cprng
crc32_pclmul
snd_hda_codec_realtek
snd_hda_codec_generic
ecdh_generic
ghash_clmulni_intel
intel_cstate
iwlmvm
mac80211
iwlwifi
intel_uncore
intel_rapl_perf
evdev
joydev
pcspkr
serio_raw
snd_hda_intel
snd_hda_codec
cfg80211
i915
snd_hda_core
rfkill
snd_hwdep
lpc_ich
drm_kms_helper
sg
shpchp
snd_pcm
snd_timer
snd
drm
soundcore
i2c_algo_bit
wmi
button
int3403_thermal
acpi_als
kfifo_buf
video
battery
industrialio
ac
int3402_thermal
int340x_thermal_zone
int3400_thermal
asus_wireless
acpi_thermal_rel
acpi_cpufreq
ib_iser
rdma_cm
iw_cm
ib_cm
ib_core
configfs
iscsi_tcp
libiscsi_tcp
libiscsi
scsi_transport_iscsi
loop
parport_pc
ppdev
lp
parport
sunrpc
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
rtsx_usb_sdmmc
mmc_core
rtsx_usb
mfd_core
btrfs
zstd_decompress
zstd_compress
xxhash
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
hid_generic
usbhid
hid
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
sd_mod
crc32c_intel
aesni_intel
ahci
libahci
i2c_i801
aes_x86_64
xhci_pci
crypto_simd
cryptd
glue_helper
libata
ehci_pci
xhci_hcd
ehci_hcd
psmouse
scsi_mod
usbcore
usb_common
thermal
fan

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM 
Controller [8086:0154] (rev 09)
Subsystem: ASUSTeK Computer Inc. Zenbook Prime UX31A [1043:1517]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ivb_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core 
processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Zenbook Prime UX31A [1043:1517]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation 3rd Gen Core 
Processor Thermal Subsystem [8086:0153] (rev 09)
Subsystem: ASUSTeK Computer Inc. Zenbook Prime UX31A [1043:1517]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset 
Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])
Subsystem: 

Bug#845500: nftables: notrack target fails with No such file or directory

[Vincent Blut]

On Thu, Nov 24, 2016 at 08:46:27AM +0100, Arturo Borrero Gonzalez wrote:

On 24 November 2016 at 01:34, Peter Colberg  wrote:


While the nftables package in Debian stretch will support notrack, the
corresponding kernel support was committed after the 4.9 merge window:

https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/commit/net/netfilter/nft_ct.c?id=254432613c588640f8b8b5c3641a3c27bbe14688

Assuming 4.9 becomes the stretch kernel, could you backport the patch?



Debian stretch will include linux 4.10 [0], so no problem.


[0] https://lists.debian.org/debian-devel-announce/2016/03/msg0.html


Hi,

IIRC Ben said that the next upstream kernel being tagged as LTS will be 
the one included in Debian strech, so we’ll probably have 4.9… unless 
Greg KH changes his mind again. :D


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#842226: dmesg: read kernel buffer failed: Operation not permitted

[Vincent Blut]

On Thu, Oct 27, 2016 at 03:21:14PM +0900, Kyuma Ohta wrote:

Package: src:linux
Version: 4.8.4-1~exp1
Severity: normal

Dear Maintainer,

Using dmesg as non-root user at linux-4.8-trunk, failed to read
kernels' ring buffer as below:
$ dmesg
dmesg: read kernel buffer failed: Operation not permitted

As root user to read, succeeeded.
Is change security policy? If not, please fix.


Hello,

Part of the changelog from the aforementioned kernel:
* security,printk: Enable SECURITY_DMESG_RESTRICT, preventing non-root 
 users reading the kernel log by default (sysctl: kernel.dmesg_restrict)



Regards,
Ohta.


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#756900: #756900: nfs-utils: NFS 1.3 fixes NFS systemd integration

[Vincent Blut]

On Wed, May 25, 2016 at 10:45:43AM +1000, Trent W. Buck wrote:

I recently upgraded my NFSv3 clients from wheezy to jessie, and they just DID 
NOT WORK.
The NFS sysvinit init scripts had dependency cycles & race conditions when used 
under systemd.
I ended up writing my own systemd units for the parts I needed (foo.mount, statd, 
& rpcbind),
and disabling the rest.

While working on that, I discovered that upstream has already solved this 
problem.
nfs-utils 1.3.x includes native systemd integration.

This week I went to upgrade my NFSv3 server to stretch (from pre-systemd).
I was disappointed to discover that Debian STILL doesn't have nfs-utils 1.3.x.
I guess I'll have to write my own systemd units again! :-/

If upgrading nfs-utils right now will cause problems, I totally get that.
Keeping things working is a lot harder for all of Debian than for just me.
But can someone please at least reply and say what the blockers ARE?

This ticket has been open for nearly TWO YEARS, with no reply.
This makes it hard for me to manage $boss's expectations.


PS: some of my jessie issues were in rpcbind, not nfs-utils.
#806336 looks particularly relevant; which also appears to be ignored.

PPS: maybe this issue HAS been discussed, just somewhere else.
Due to the maintainer archive link on https://tracker.debian.org/pkg/nfs-utils,
I checked https://lists.debian.org/debian-kernel/, but I found nothing.
I also found nothing in "wnpp-check nfs-utils".


Hello,

Actually, nfs-utils seems to not have been touched in unstable since 
around mid 2014. Perhaps reporting its state to d-devel would help 
bringing new blood to work on it‽


Also, Joachim Wiedorm (cc’ed) provides¹ nfs-utils for Debian in its 
latest version, I guess his work could be a good base.


Cheers,
Vincent

¹ http://www.joonet.de/sources/nfs-utils/debian/


signature.asc
Description: PGP signature

Bug#808720: [regression 4.2 -> 4.3] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_drrs (expected 1, found 0)

[Vincent Blut]

fixed 808720 4.4~rc5-1~exp1
thanks

Hello,

I do have the same issue. This regression has been introduced in Linux 
4.3
by commit [cfb23ed622d0: drm/i915: Allow fuzzy matching in 
pipe_config_compare, v2]
and fixed upstream by commit [13b13dfaaa39: drm/i915: Don't compare 
has_drrs strictly in pipe config],
which hit Linux 4.4-rc4. Note that this patch has been marked as 
applicable to the linux-stable (>= 4.3)
tree, thus it should be fixed next time Ben upload a subsequent version 
of Linux 4.3.x.


Cheers,
Vincent

Bug#780773: Please backport EDAC_IE31200 to Linux 3.16.x

[Vincent Blut]

Le jeu. 19 mars 2015 à 7:59, Paul Menzel  a 
écrit :

[…]
Is that something that has to go over the Canonical Kernel Tree or 
does

Debian also carry such backports separately?


Hi Paul,

The Canonical kernel team follows the stable upstream acceptance 
rules¹, thus backporting this new driver² would have to be carry by 
the Debian kernel maintainers.


By the way, I think severity 'wishlist' would have been more 
appropriate.



Thanks,

Paul


Cheers,
Vincent

¹ https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt
² commit 7ee40b897d18


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1426877583.2898...@smtp.free.fr