Conditional compiler flags based on the compiler (version) used

Hi, I want to add "EXTRA_CFLAGS += -Werror=date-time" to the Makefile of my kernel module project (https://github.com/diederikdehaas/rtl8812AU) to support Reproducible Builds. But this makes the build fail when using Jessie (or older) since that flag isn't supported on GCC < 4.9. While

Re: Conditional compiler flags based on the compiler (version) used

On Thursday 01 October 2015 18:06:21 Ben Hutchings wrote: > Use the cc-option macro defined by Kbuild: > > EXTRA_CFLAGS += $(call cc-option,-Werror=date-time) Awesome, thank you so much! Diederik signature.asc Description: This is a digitally signed message part.

Testing versatile kernel on Raspberry Pi?

Hi! I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's 4.4 kernel for it. At least it is/was my understanding that the versatile kernel is meant for the Raspberry Pi. But when I (globally) compare config-4.4.0-rc8-versatile with kernel configs taken from my Pi's I see HUGE

Re: Testing versatile kernel on Raspberry Pi?

Thanks for your response :-) On Monday 25 January 2016 13:23:20 Ian Campbell wrote: > > I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's 4.4 > > kernel for it. At least it is/was my understanding that the versatile > > kernel is meant for the Raspberry Pi. > > The versatile

Re: Testing versatile kernel on Raspberry Pi?

On Monday 25 January 2016 15:07:50 Ian Campbell wrote: > > The armmp kernel flavour should now support the BCM2836 and the Pi 2, > > I missed this going in, thanks! > > > but *not* the BCM2835. Also, Debian's armhf port is built for ARMv7 > > whereas the BCM2835 implements ARMv6. Most of the

Re: Testing versatile kernel on Raspberry Pi?

On Monday 25 January 2016 14:58:27 Ian Campbell wrote: > > As I got the impression that support for the RPi was now present in > > upstream and (therefor) the Debian kernels, > > The "therefor" won't happen automatically, someone will need to file a > wishlist bug asking for the relevant options

Re: Testing versatile kernel on Raspberry Pi?

On Tuesday 26 January 2016 08:24:16 Ian Campbell wrote: > The Debian armhf kernels do not have support for ARMv6 enabled. AIUI > moving to a v6+v7 capable kernel, other than muddying the waters WRT > what "armhf" means, would also mean falling back to ARMv6 features only > missing out on ARMv7

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

On Sun, 10 Apr 2016 20:14:19 +0100 Ben Hutchings wrote: > I checked the latest Raspbian kernel I could find > (,3.16.7-ckt11-1+deb8u4+rpi1) and they don't have any patches to that > driver (other than adding a module parameter for no good reason). Where did you look? At

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

On Thursday 28 April 2016 17:12:27 Ben Hutchings wrote: > Could you test with turbo_mode re-enabled and with this patch applied? Which patch? (or do I need more coffee?) I did find a commit in git which may be related, but I didn't see a direct reference to this issue.

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

On Saturday 07 May 2016 12:44:41 Ben Hutchings wrote: > If this patch reduces the risk of > failed buffer allocations then I think it's still a win. I agree (fwiw). signature.asc Description: This is a digitally signed message part.

Bug#808792: firmware-iwlwifi: iwlwifi-7260-17.ucode is missing

> It looks like -17 reached linux-firmware.git a few hours ago. Maybe > it's time to update firmware-nonfree? Yes please, as it also contains iwlwifi-7265D-21.ucode which was needed for my ASUS ZenBook UX305CA. I managed to workaround it, but I doubt the average user would. signature.asc

Bug#852324: x86/mm: Found insecure W+X mapping

Package: xen-linux-system-4.8.0-2-amd64 Version: 4.8.15-2 Severity: normal When I boot my system with Xen, I get the following section in dmesg: [ 13.588381] [ cut here ] [ 13.588386] WARNING: CPU: 18 PID: 1 at

Bug#853193: linux-image-4.9.0-1-amd64: [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC: 1

Package: src:linux Version: 4.9.6-3 Severity: normal Tags: upstream, patch Since kernel version 4.9.2-2 I get the following line in dmesg for each core in my system, except CPU0. (when booting under Xen) : [] [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC:1 I did not get these

Bug#837200: linux-image-3.16.0-4-amd64: kernel crash: /build/linux-7z1rSb/linux-3.16.7-ckt25/net/sched/sch_generic.c:264 dev_watchdog+0x236/0x240()

Package: src:linux Version: 3.16.36-1+deb8u1 Severity: important After the latest kernel upgrade I've now had 2 kernel crashes and on first look they seem rather similar and I don't recall that I got them before the kernel update of 03 Sep 2016, so it is likely that that change introduced it.

Bug#852324: Not a fatal error/warning

On Wed, 26 Jul 2017 19:23:23 +0200 Helio Loureiro wrote: > He clearly states it isn't booting. It is crashing. No, that is an incorrect assessment. I called it an error because I saw a stacktrace which I associate with an error, even though the first line after "[ cut here ]" said warning.

Bug#852324: closed by Ben Hutchings (Re: [xen] x86/mm: Found insecure W+X mapping)

On woensdag 31 oktober 2018 04:27:04 CET you wrote: > Version: 4.17~rc3-1~exp1 > > This was fixed upstream in Linux 4.17-rc1. > > Ben. You are awesome :) I was/am on the verge of upgrading that system from Stretch to Buster, which would upgrade both Xen (to 4.11) and the kernel (some which

Bug#852324: closed by Ben Hutchings (Re: [xen] x86/mm: Found insecure W+X mapping)

On zaterdag 3 november 2018 03:02:07 CET Ben Hutchings wrote: > > I was/am on the verge of upgrading that system from Stretch to Buster, > > which would upgrade both Xen (to 4.11) and the kernel (some which would > > include the fix). > > Would it be useful to first upgrade just the kernel (and

No problems since updating ucodes from upstream git

I updated /lib/firmware/amd-ucode/*.bin from upstream git (commit 7bc246451318b3536d9bfd3c4e46d541a9831b33) and updated initramfs (I'm not sure that's the right place) and since then I haven't had the problem anymore. I realize that we're in freeze mode, but the 18.50 release looks to become

Bug#928631: Question

On vrijdag 21 juni 2019 16:53:11 CEST Dean Loros wrote: > Can I confirm that this is a problem with AMD graphics only--or will this > affect all systems regardless of Video card type? Yes. (bug is filed against firmware-amd-graphics) Michael Becker: what CPU do you have? Antonio De Luci: Are

Bug#928631: Question

Just got a msg from Michael send to me personally, I assume by accident. Summary of the affected systems: AMD Ryzen 1700X + VEGA64 + Sid AMD Ryzen 2700X + VEGA64 + Sid AMD Ryzen 2700X + VEGA56 + Sid It's up to the maintainers, but as I said, I would be fine if severity of the bug is lowered or

Re: Updating microcode files didn't help, maybe a kernel problem after all

On dinsdag 26 maart 2019 16:11:47 CEST Diederik de Haas wrote: > I updated /lib/firmware/amd-ucode/*.bin from upstream git (commit > 7bc246451318b3536d9bfd3c4e46d541a9831b33) and updated initramfs (I'm not > sure that's the right place) and since then I haven't had the problem

Bug#928631: firmware-amd-graphics: Update to 20190502-1 causus hang of system directly after grub

On zaterdag 18 mei 2019 14:08:17 CEST Michael Becker wrote: > But I did not notice any spontaneous reboots so far. The spontaneous reboots seems to be an entirely different issue, see https:// bugs.debian.org/cgi-bin/bugreport.cgi?bug=924895#15 for details. signature.asc Description: This is a

Bug#928631: firmware-amd-graphics: Update to 20190502-1 causus hang of system directly after grub

On dinsdag 21 mei 2019 19:24:07 CEST Romain Perier wrote: > Hi, Hi, > firmware-amd-graphics 20190502-1 is based onto upstream commit > 92e17d0dd2437140fab044ae62baf69b35d7d1fa, that is commit "amdgpu: update > vega20 to the latest 19.10 firmware" . Two commits behind there is commit > "amdgpu:

Bug#928631: firmware-amd-graphics: Update to 20190502-1 causus hang of system directly after grub

On dinsdag 21 mei 2019 21:20:18 CEST Diederik de Haas wrote: > Checking 'git log' for that specific file before I did the test made me > conclude it wouldn't make a difference with packaged version 20190114-1 > (but did the test anyway as requested). To verify whether that single fi

Bug#928631: firmware-amd-graphics: Update to 20190502-1 causus hang of system directly after grub

On dinsdag 21 mei 2019 21:20:18 CEST Diederik de Haas wrote: > What was the reason for the test? FTR: before I did the test I had already downgraded firmware-amd-graphics and consequently also firmware-linux-nonfree and firmware-misc-nonfree back to version 20190114-1 signature.asc Descript

Bug#928631: firmware-amd-graphics: Update to 20190502-1 causus hang of system directly after grub

Package: firmware-amd-graphics Version: 20190502-1 Severity: critical Justification: breaks the whole system Today's Sid update brought in new kernel and various firmware updates, after which I rebooted the system. Saw Grub loading, but after it started kernel 4.19.0-5-amd64, it stopped loading

Bug#928631:

Hi, On zondag 14 juli 2019 21:38:14 CEST Hillel Lubman wrote: > 20190502-1 is already outdated, since amdgpu firmware had some updates > upstream: > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > /log/amdgpu > > Does this problem still occur if you use latest

Bug#944661: I don't think RPCNFSDPRIORITY value actually works

In the initial bug report, you can see that /etc/default/nfs-kernel-server has RPCNFSDPRIORITY=-10 But I don't think that has the intended effect, because all the nfsd processes have a priority of 0, not -10. I tried a local path to implement ionice-ness. Added to

Bug#944661: nfs-kernel-server: Please support specifying ionice-ness

Package: nfs-kernel-server Version: 1:1.3.4-2.5 Severity: wishlist Once can already specify nice-ness through RPCNFSDPRIORITY which sets the --nicelevel parameter of start-stop-daemon. But I want to also specify the ionice-ness and start-stop-daemon already supports that through the --iosched

Bug#969916: linux-image-5.8.0-1-arm64: USB3 port not working on Pine64's Rock64

Package: src:linux Version: 5.8.7-1 Severity: normal When connecting a USB device to the USB3 port on the Rock64, nothing appears in dmesg and lsblk doesn't show the device either. But when I boot into armbian, it does appear in both dmesg and lsblk. Then I found commit "[ rockchip64 ] add USB3

Bug#883194: please convert mountstats and nfsiostat scripts to Python3

On Tue, 22 Oct 2019 20:34:44 +0200 Laurent Bigonville wrote: > On Thu, 30 Nov 2017 16:37:52 +0100 Matthias Klose wrote: > > > > the changelog reads: > > > > - nfs-common: Add Recommends python for mountstats and nfsiostat > > > > Please convert these scripts to python3, and recommend

Bug#971892: linux: Please enable modules for HDMI audio

On Fri, 9 Oct 2020 08:39:48 +0200 harr...@gmx.ph wrote: > Please could you enable these modules: > > CONFIG_SND_SUN4I_I2S=m ("Allwinner A10 I2S Support") > CONFIG_DRM_DW_HDMI_I2S_AUDIO=m ("Synopsys Designware I2S Audio interface") They are enabled in the 5.9.0-1-arm64 kernel, but noticed

Possible initramfs-tools issue

Hi, Recently there were 2 issues raised wrt raspi-firmware: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975943 and https://salsa.debian.org/raspi-team/image-specs/-/issues/37 And (especially) the latter one gave rise to the idea that the problem may be in initramfs-tools(-core) and not in

Bug#968181: linux-image-5.7.0-2-arm64: DRM unavailable on Rapsberry Pi 4B

On Wed, 4 Nov 2020 09:09:55 +0100 Lucas Nussbaum wrote: > Outside of the kernel, there's nothing else needed. What I haven't seen mentioned thus far and is AFAIUI essential, is the following line in /boot[/firmware/]/config.txt: dtoverlay=vc4-kms-v3d Note that it is not the -fkms- variant and

Re: Possible initramfs-tools issue

On donderdag 10 december 2020 00:39:55 CET Diederik de Haas wrote: > Recently there were 2 issues raised wrt raspi-firmware: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975943 and > https://salsa.debian.org/raspi-team/image-specs/-/issues/37 > > In my last comment on the

Bug#968181: linux-image-5.7.0-2-arm64: DRM unavailable on Rapsberry Pi 4B

On donderdag 17 december 2020 15:28:45 CET Lucas Nussbaum wrote: > On 17/12/20 at 13:49 +0100, Diederik de Haas wrote: > > On Wed, 4 Nov 2020 09:09:55 +0100 Lucas Nussbaum wrote: > > > Outside of the kernel, there's nothing else needed. > > > > What I h

Bug#976635: linux-image-arm64: Accelerated crypto modules missing from kernel config

Hi Ard, On vrijdag 11 december 2020 12:26:43 CET Ard Biesheuvel wrote: > > Are you the same Ard Biesheuvel that 'Signed-off-by' the patch in: > > https://salsa.debian.org/kernel-team/linux/-/commit/ > > 8332600d1188a6d1fc835dfcd392a20f6bfc > > Presumably, yes. But I cannot access that link.

Bug#976635: linux-image-arm64: Accelerated crypto modules missing from kernel config

On Sun, 06 Dec 2020 09:34:36 +0100 Ard Biesheuvel wrote: > Currently, arm64 kernel packages are built with the following Kconfig symbols unset: > > # CONFIG_CRYPTO_SHA512_ARM64 is not set > # CONFIG_CRYPTO_SHA512_ARM64_CE is not set > # CONFIG_CRYPTO_SHA3_ARM64 is not set > #

Bug#977645: linux-image-5.10.0-trunk-arm64: Both 5.10.1 and .2 do work on RPi3B+ with ext4 rootfs on sdcard

Package: src:linux Version: 5.10.2-1~exp1 Followup-For: Bug #977645 Just wanted to mention that this version as well as 5.10.1 do boot on a RPi3B+. It's not in any way contradicting this bug, but may be useful to know nonetheless. -- Package-specific info: ** Version: Linux version

Bug#978025: linux-image-5.10.0-trunk-arm64: alsa audio output problems since 5.10 kernel

Package: src:linux Version: 5.10.2-1~exp1 Severity: normal On my RPi3B+ (named rpi-mpd) I have the following sound cards: $ cat /proc/asound/cards 0 [ALSA ]: bcm2835_alsa - bcm2835 ALSA bcm2835 ALSA 1 [vc4hdmi]: vc4-hdmi - vc4-hdmi

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

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

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

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 Ar

Bug#980214: Fix found version

Control: notfound -1 5.10.9+1 Control: found -1 5.10.9-1 signature.asc Description: This is a digitally signed message part.

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

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

Bug#977645: 5.10.1 Debian kernel does not boot on raspi 4 with ext4 rootfs and sdcard

Control: reassign -1 src:linux 5.10.1-1~exp1 Control: found -1 5.10.2-1~exp1 Control: found -1 5.10.4-1 Control: retitle -1 5.10.x Debian kernel does not boot on raspi 4 with ext4 rootfs and sdcard On Mon, 04 Jan 2021 09:24:09 +0900 (JST) Ryutaroh Matsumoto wrote: > Control: reassign -1

Bug#883194: please convert mountstats and nfsiostat scripts to Python3

On maandag 21 juni 2021 13:20:46 CEST Drew Parsons wrote: > I was surprised to see python2 pulled in on a new bullseye > installation using nfs. > > It's a trivial patch of course to update the hashbangs for mountstats > and nfsiostat in nfs-common 1:1.3.4-5 to python3.

Bug#990106:

On maandag 21 juni 2021 03:14:47 CEST Davide Beatrici wrote: > I reproduced the problem on 5.10.0-6 as well > I believe the relay in the amplifier is going bad It maybe useful to try a 5.9.x kernel as well, to properly rule out the kernel as the source of the issues. Difference between -6 and -7

Bug#987576: linux: Please enable CONFIG_SND_AUDIO_GRAPH_CARD

There's an upstream commit (part of 5.12) that Vincent referenced that nicely illustrates the difference between what I want to achieve with this bug report and a possible solution applied in that commit (IIUC):

Bug#969916: Updating metadata

Control: found -1 5.10.46 Control: tag -1 upstream patch commit 44dd5e2106dc2fd01697b539085818d1d1c58df0 from 5.13 commit bbac8bd65f5402281cb7b0452c1c5f367387b459 from linux-next from 20210701 Those 2 patches make USB3 work on the Rock64 :) signature.asc Description: This is a digitally signed

Bug#969916: Correcting updated metadata

Control: found -1 5.10.46-1 signature.asc Description: This is a digitally signed message part.

Bug#990536: linux: Please enable RK805 PMIC components for Rock64 SBC.

001 From: Diederik de Haas Date: Sun, 23 May 2021 23:53:22 +0200 Subject: [PATCH 4/4] Enable Power Management ICs for RK805 components. https://www.cnx-software.com/pdf/Rockchip-Roadmap-2019-.11_mts.pdf says on page 3 that RK805 is used for RK3328/RK3228 SOCs and Pine64's Rock64 is a SBC that u

Bug#989229: Possibly related bug?

I filed the following bug which may be related? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990867 Even though the (error) messages are/seem quite different, maybe the 'Read-only file system' message is also kernel related? I don't know the details anymore, but I've seen 'efivars' come by

Bug#883194: please convert mountstats and nfsiostat scripts to Python3

On zondag 27 juni 2021 22:37:10 CEST Salvatore Bonaccorso wrote: > Let's ask the release team instead. Here my arguments why: nfs-utils > needs a major rehaul, this was not possible to finish in time for > bullseye, so this means nfs-utils is generally in not a very good > shape for

Bug#987576: linux: Please enable CONFIG_SND_AUDIO_GRAPH_CARD

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

Bug#978025: Problem also present in 5.10.13-1

Control: found -1 5.10.13-1 signature.asc Description: This is a digitally signed message part.

Bug#978025: Forwarded to linux-rpi-kernel ML

Control: forwarded -1 https://lists.infradead.org/pipermail/linux-rpi-kernel/2021-February/008002.html signature.asc Description: This is a digitally signed message part.

Bug#978025: Seems un-fixed again

Control: found -1 5.10.12-1 Control: retitle -1 "linux-image-5.10.x: alsa audio output problems on RPi since 5.10 kernel" On zaterdag 23 januari 2021 20:16:45 CET you wrote: > Version: 5.10.9-1 > > Just played various tracks with this (new) kernel and they all play fine :) > Don't know what the

Bug#978025: Fixing title

Control: retitle -1 linux-image-5.10.x: alsa audio output problems on RPi since 5.10 kernel signature.asc Description: This is a digitally signed message part.

Bug#982408: correction PCM 2901 not 3901

Control: retitle -1 linux-image-5.10.0-3-armmp: odroid u3 with Icom IC-7300 sound card (PCM2901) no output sound device On dinsdag 9 februari 2021 22:04:50 CET Rusan Ioan wrote: > Correction, sound card is By PCM2901 not PCM3901 Updating title accordingly. signature.asc Description: This is a

Bug#963025: fixing metadata

Control: found -1 20210315-2 Control: tags -1 moreinfo

Bug#985615: Updating metadata

Control: found -1 4.19.171-2 Control: fixed -1 4.19.181-1

Bug#985615: Updating metadata

Control: retitle -1 4.19.0-14-amd64: USB keyboard no longer reliably works, requires restart

Bug#984873: linux-image-5.10.0-4-arm64: RPi4 8 GB lost USB support (doesn't start with / on USB device)

On dinsdag 9 maart 2021 15:17:01 CET Jan Huijsmans wrote: > Updating from linux-image-5.9.0-4-arm64 to linux-image-5.10.0-3/4-arm64 > resulted in a non-booting system due to missing/incorrect USB support > for the RPi4 8GB. (system has / on USB SSD) > > Only method to get the system booting again

Bug#944560: Bug solved with kernel 4.19.0-14-amd64

Control: fixed -1 4.19.171-2 On zaterdag 20 maart 2021 19:10:27 CET pham...@bluewin.ch wrote: > Bug solved with kernel 4.19.0-14-amd64 Marking as fixed with the proper version. signature.asc Description: This is a digitally signed message part.

Bug#944560: Correcting found version

Control: found -1 4.19.67-2 signature.asc Description: This is a digitally signed message part.

Bug#984852: firmware-amd-graphics: Please add cezanne ("green sardine")

On dinsdag 9 maart 2021 10:31:33 CET maximilian attems wrote: > > I've received my new laptop with a Ryzen R7 5800U ... > > The relevant files are amdgpu/green_sardine_* > > right, they only got pushed upstream in linux-firmware git on 11/2/2021 > after the latest 20210208 release, hence

Bug#986881: iw: Incorporate useful bits of crda?

Package: iw Version: 5.9-3 Severity: wishlist X-Debbugs-Cc: debian-kernel@lists.debian.org Earlier I filed bug #972994 to remove the Recommends on crda, which was then fixed, thanks. Today I got an update of network-manager which fixed bug #973241 for which the request and fix was similar to

Bug#986863: correcting metadata

Control: notfound -1 5.8.14-1 Control: found -1 5.10.28-1 signature.asc Description: This is a digitally signed message part.

Bug#900821: metadata + get others involved?

Control: found -1 5.10.28-1 On Wed, 21 Apr 2021 11:01:48 +0200 dee...@gmx.net wrote: > It is still reproducible Updated metadata accordingly. The primary reason I'm responding is that this bug seems to center around 3 components: kernel, apache and samba/cifs. Yet, it seems to me that this bug

Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

On zaterdag 21 augustus 2021 17:38:51 CEST Kobus van Schoor wrote: > Enabling/disabling it however has no effect It was worth a shot ;-) > (it was set to "Bad" anyway). I don't expect much from it, but you could set them all to "Bad". If that still doesn't make a difference, then you can fully

Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

On zaterdag 21 augustus 2021 16:42:21 CEST Kobus van Schoor wrote: > - My battery lasts significantly longer after upgrading to bullseye > (around 2 hours extra I would guess). I'm not sure if there is now > extra power saving features present in the kernel which might be > interfering with my USB

Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

Control: retitle -1 Too aggressive energy savings on kernel 5.10 cause some devices to malfunction On zaterdag 21 augustus 2021 18:48:31 CEST Kobus van Schoor wrote: > Thanks Diederik, that did the trick! > After setting "Runtime PM for PCI Device Intel Corporation Sunrise > Point-LP CSME HECI

Bug#992637: Too aggressive energy savings on kernel 5.10 cause some USB devices to malfunction

Control: retitle -1 Too aggressive energy savings on kernel 5.10 cause some USB devices to malfunction signature.asc Description: This is a digitally signed message part.

Bug#992184: linux: Should CONFIG_LEDS_TRIGGER_HEARTBEAT be builtin?

Source: linux Version: 5.13.9-1~exp2 Severity: wishlist Currently there are some LED triggers builtin and some as modules: $ grep 'CONFIG_LEDS_TRIGGER' /boot/config-5.13.0-trunk-arm64 CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_ONESHOT=m CONFIG_LEDS_TRIGGER_DISK=y

Bug#992184: #992184 linux: Should CONFIG_LEDS_TRIGGER_HEARTBEAT be builtin?

Control: found -1 5.14.3-1~exp1 Control: tag -1 patch On 15 Aug 2021 13:06:48 +0200 Diederik de Haas wrote: > Most are in arch arm*, but also in arc/powerpc/microblaze/mips. At https://salsa.debian.org/kernel-team/linux/-/merge_requests/390 I submitted a MR which makes this trigger buil

Bug#991967: Simply ACPI powerdown/reset issue?

Adding pkg-xen-de...@lists.alioth.debian.org into the loop. Chuck Zmudzinski replied to the bug and later replied to his own reply. To give full context, I've added the original reply in full and Chuck's reply to that (as it only quoted part of the context there). On zondag 19 september 2021

Bug#984873: Bug#991714: linux-image-5.10.0-8-arm64: RPi 4 (8 GB) - CPU stuck in highest speed

On vrijdag 30 juli 2021 17:22:06 CEST Jan Huijsmans wrote: > ** Command line: > ... root=/dev/sda1 I'm assuming you're the same person as in #984873, but iirc my mail to you wrt that bug report bounced and hasn't received an answer. Given that you're now booting from USB (again), it may be

Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1

Source: linux Version: 5.10.46-3 Severity: wishlist Tags: patch At https://salsa.debian.org/raspi-team/image-specs/-/issues/7#note_206349 it was reported that CPU frequency scaling was enabled for armhf and arm64, but not for armel. I (and others) have been able to confirm that. So I build my

Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1

On vrijdag 6 augustus 2021 16:07:18 CEST Diederik de Haas wrote: > > > -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y > > > +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > > > -# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set > > > +CO

Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1

On donderdag 5 augustus 2021 19:26:09 CEST Diederik de Haas wrote: > I 'heard' that the schedutil governor is good for big.little CPUs, but On my amd64 machine (with Ryzen 1800X CPU) 'schedutil' is enabled and set as default, so the above statement is a bit too simplistic. > the RPi

Bug#984873: Bug#991714: linux-image-5.10.0-8-arm64: RPi 4 (8 GB) - CPU stuck in highest speed

On vrijdag 30 juli 2021 21:28:54 CEST Diederik de Haas wrote: > On vrijdag 30 juli 2021 17:22:06 CEST Jan Huijsmans wrote: > I'm assuming you're the same person as in #984873, but iirc my mail to you > wrt that bug report bounced and hasn't received an answer. And that mail bounced as

Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1

Hi, On vrijdag 6 augustus 2021 15:14:26 CEST Uwe Kleine-König wrote: > On Thu, Aug 05, 2021 at 05:26:09PM +0000, Diederik de Haas wrote: > > https://salsa.debian.org/raspi-team/image-specs/-/issues/7#note_206349 > > > > So I build my own kernel wit

Bug#995923: linux: Regression in 5.14: no more multichannel audio on Rock64

Control: tag -1 patch On Friday, 8 October 2021 10:43:14 CEST Diederik de Haas wrote: > In kernel 5.13 on my Rock64, `pactl list cards` correctly identified my > AVR (SC-1224) and had various multichannel audio profiles I could choose > from. Since kernel 5.14, `paclt list cards`

debian/patches/bugfix/all/tools-perf-man-date.patch applied upstream?

Hi, At debian/patches/bugfix/all/tools-perf-man-date.patch is a patch to "allow man pages to be built reproducibly" I just stumbled upon a commit with title "perf doc: Set man page date to last git commit" (from 2020-03-10)

Bug#955407: linux-image-4.19.0-8-amd64: "Uhhuh. NMI received for unknown reason" on AMD Ryzen

Package: src:linux Version: 5.14.9-2 Followup-For: Bug #955407 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I had seen this issue before too and actually had a knuckle and assumed it was a one-time thing. But I've had 2 more in the last 2 days. It *may* be related to hibernation as I usually

Bug#955407: linux-image-4.19.0-8-amd64: "Uhhuh. NMI received for unknown reason" on AMD Ryzen

On Saturday, 9 October 2021 21:28:19 CEST Diederik de Haas wrote: > I'll try later whether I can reliably reproduce it with hibernate mode. That appears to be the case. Hibernated my PC yesterday and started it up today. After some time, I got the msgs again, this time also in dmesg: # dm

Bug#995923: Forwarded upstream

Control: forwarded -1 https://lore.kernel.org/all/4974503.Y8KB3sNASq@bagend/ signature.asc Description: This is a digitally signed message part.

Bug#996951: linux-image-5.14.0-3-amd64: iouring looses requests

On Thursday, 21 October 2021 12:41:34 CEST Salvatore Bonaccorso wrote: > On Thu, Oct 21, 2021 at 09:38:00AM +, Daniel Black wrote: > > Package: src:linux > > Version: 5.14.12-1 > > The good news is I've validated that the linux mainline 5.14.14 build > > from

Bug#995923: linux: Regression in 5.14: no more multichannel audio on Rock64

Source: linux Version: 5.14-1~exp1 Severity: normal Tags: upstream In kernel 5.13 on my Rock64, `pactl list cards` correctly identified my AVR (SC-1224) and had various multichannel audio profiles I could choose from. Since kernel 5.14, `paclt list cards` no longer identifies my AVR and I only

Re: patch Re: kvm crash in 5.14.1?

Hi, On Sunday, 10 October 2021 23:42:39 CEST Francois Le Hir wrote: > I am not sure what is the correct process and I apologize if this is not the > appropriate way to do it, but could you please include this patch in your > next testing, unstable or experimental kernel ? Please don't use HTML

Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1

Hi, On vrijdag 6 augustus 2021 16:07:18 CEST Diederik de Haas wrote: > On vrijdag 6 augustus 2021 15:14:26 CEST Uwe Kleine-König wrote: > > On Thu, Aug 05, 2021 at 05:26:09PM +, Diederik de Haas wrote: > > > https://salsa.debian.org/raspi-team/image-specs/-/is

Bug#991967: #991967: Simply ACPI powerdown/reset issue?

On dinsdag 21 september 2021 01:15:15 CEST Elliott Mitchell wrote: > Merely having the path is a sufficiently strong indicator for me to > simply wave it past. I though would suggest Debian should instead > cherry-pick commit 0f089bbf43ecce6f27576cb548ba4341d0ec46a8. > > This is available as a

Bug#992184: #992184 linux: Should CONFIG_LEDS_TRIGGER_HEARTBEAT be builtin?

Control: tag -1 pending On 14 Sep 2021 02:16:18 +0200 Diederik de Haas wrote: > At https://salsa.debian.org/kernel-team/linux/-/merge_requests/390 > I submitted a MR which makes this trigger builtin on arm* platforms. That MR got merged into the 'master' branch with: https://salsa.debi

Bug#991967: Simply ACPI powerdown/reset issue?

Hi Elliott, On zondag 26 september 2021 05:27:07 CEST Elliott Mitchell wrote: > I checked out the Debian Xen source via git. I got the current > "master" branch which is presently the candidate 4.14.3-1 version, > which includes urgent fixes. The hash is: >

Bug#1001080: linux: Previously enabled IIO ADC drivers are no longer enabled

Source: linux Version: 5.10.1-1_exp1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 In commit aa87da1f902dba04f3b15680e178ad336e985f4f titled "Enable all Industrial I/O ADC" various IIO ADC drivers which were enabled for armhf and arm64 got disabled, while a whole bunch of

Bug#962003: A bit more info

I put "*ERROR* Failed to wait for idle; VT'd may hang" into a search engine and found the following: Second result was https://bugs.archlinux.org/task/65362 which said: "The change to CONFIG_INTEL_IOMMU_DEFAULT_ON=yes on 5.5.1.arch1-1 causes random system freezes" and a possible workaround is:

Bug#996713: firmware-brcm80211: firmware becomes non-responsive while running as an access point on RPI4

On Sun, 17 Oct 2021 13:10:19 -0400 Andres Salomon wrote: > Package: firmware-brcm80211 > Version: 20210315-3 > Severity: normal > > This bug is mostly for documentation purposes. > > When running a raspberry pi 4b as an access point, after a random > period of time the on-chip firmware will

Bug#996951: linux-image-5.14.0-3-amd64: iouring looses requests

Control: Forwarded -1 https://lore.kernel.org/linux-block/cabvffennj8jkp7etuutqi+vkjdbfu37w1uxe4q3cb7-ixxh...@mail.gmail.com/ On Saturday, 23 October 2021 23:29:21 CEST Daniel Black wrote: > https://marc.info/?l=linux-block=163489378723217=2 Looked up your upstream message on lore.k.o and set

Bug#991453: linux-image-5.10.0-8-amd64: Radeon 6800 XT: 100% GPU core usage & 74 Watts when idle

lid-until=no] https://snapshot.debian.org/archive/debian/20210529T204006Z/ sid main Installed linux-image-5.10.0-7-amd64 and rebooted into that ... On zaterdag 24 juli 2021 14:22:38 CEST Diederik de Haas wrote: > On zaterdag 24 juli 2021 01:29:55 CEST piorunz wrote: > > GPU core works at

Bug#991453: linux-image-5.10.0-8-amd64: Radeon 6800 XT: 100% GPU core usage & 74 Watts when idle

Control: tags -1 confirmed On zaterdag 24 juli 2021 01:29:55 CEST piorunz wrote: > GPU core works at 100% usage at all times, even at idle. > > $ cat /sys/class/drm/card0/device/gpu_busy_percent > 99 > > $ sensors > (...) > amdgpu-pci-0900 > Adapter: PCI adapter > vddgfx:1.14 V > fan1:

  1   2   3   4   5   6   7   >