Bug#1016827: fixed 5.10.0-23-amd64 Bullseye

2023-05-24 Thread ng

Hello!

I just noticed this bug can't be reproduced anymore since linux 
5.10.0-23-amd64 (5.10.179-1).   Hopefully this will help to track what 
was the exact issue and how did it got fixed.



Thanks!.



Bug#978043: Bug#1016827: Fixed

2023-04-11 Thread ng
Please delete this email and the one I'm quoting; sent to Bug#978043, it 
was by accident.



> Hi
>
> Well, at least for linux 5.10.162-1 the bug is still present, kernel
> panic at the very end of reboot/power off process,  can be sorted out
> with the 'ccp.dmaengine=0' parameter.
>
> That's all I  can share,  the archlinux bug report I quoted didn't had
> any activity since feb 2022, and the lkml I also quoted had the same
> luck.  All I know is that using linux from backports works correctly
> with debian's default parameters.
>
>
> (Oops, once again, sending the email to the wrong receipt)
>
>
> > Source-Version: 6.1.15-1
> >
> > Hi
> >
> > On Mon, Apr 10, 2023 at 09:01:13AM -0300, ng wrote:
> >> Morning.
> >>
> >> I just booted into linux 6.1.15-1~bpo11+1 and it was already fixed,
> >> no need
> >> to use use 'ccp.dmaengine=0' anymore.  Great!
> >>
> >> Bug resolved.
> > Thanks, marking it as fixed accordingly, though would be nice to
> > better understand the issue and to verify if it get fixed as well in
> > the 5.10.y stable series.
> >
> > Regards,
> > Salvatore
>
>



Bug#1016827: Fixed

2023-04-11 Thread ng

Hi

Well, at least for linux 5.10.162-1 the bug is still present, kernel 
panic at the very end of reboot/power off process,  can be sorted out 
with the 'ccp.dmaengine=0' parameter.


That's all I  can share,  the archlinux bug report I quoted didn't had 
any activity since feb 2022, and the lkml I also quoted had the same 
luck.  All I know is that using linux from backports works correctly 
with debian's default parameters.



(Oops, once again, sending the email to the wrong receipt)



Source-Version: 6.1.15-1

Hi

On Mon, Apr 10, 2023 at 09:01:13AM -0300, ng wrote:

Morning.

I just booted into linux 6.1.15-1~bpo11+1 and it was already fixed, 
no need

to use use 'ccp.dmaengine=0' anymore.  Great!

Bug resolved.

Thanks, marking it as fixed accordingly, though would be nice to
better understand the issue and to verify if it get fixed as well in
the 5.10.y stable series.

Regards,
Salvatore




Bug#978043: Bug#1016827: Fixed

2023-04-11 Thread ng

Hi

Well, at least for linux 5.10.162-1 the bug is still present, kernel 
panic at the very end of reboot/power off process,  can be sorted out 
with the 'ccp.dmaengine=0' parameter.


That's all I  can share,  the archlinux bug report I quoted didn't had 
any activity since feb 2022, and the lkml I also quoted had the same 
luck.  All I know is that using linux from backports works correctly 
with debian's default parameters.



(Oops, once again, sending the email to the wrong receipt)



Source-Version: 6.1.15-1

Hi

On Mon, Apr 10, 2023 at 09:01:13AM -0300, ng wrote:

Morning.

I just booted into linux 6.1.15-1~bpo11+1 and it was already fixed, 
no need

to use use 'ccp.dmaengine=0' anymore.  Great!

Bug resolved.

Thanks, marking it as fixed accordingly, though would be nice to
better understand the issue and to verify if it get fixed as well in
the 5.10.y stable series.

Regards,
Salvatore




Bug#978043: bug#978043: fixed

2023-04-10 Thread ng
https://bugzilla.kernel.org/show_bug.cgi?id=201817 contains info about a 
patch that solved this.  It was either that or a BIOS update, or both.


At least for my machine, this is solved.



Bug#1016827: Fixed

2023-04-10 Thread ng

Morning.

I just booted into linux 6.1.15-1~bpo11+1 and it was already fixed, no 
need to use use 'ccp.dmaengine=0' anymore.  Great!


Bug resolved.

Have a nice day.



Bug#1016827: (linux-image-amd64: __dma_async_device_channel_unregister called while 2 clients hold a reference)

2022-08-07 Thread ng

Forgot to attach dmesg
[0.00] Linux version 5.10.0-16-amd64 (debian-kernel@lists.debian.org) 
(gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 
2.35.2) #1 SMP Debian 5.10.127-2 (2022-07-23)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-5.10.0-16-amd64 
root=UUID=e2621cc7-952f-4003-a3eb-60c1d6b188cd ro acpi_osi=Linux 
ccp.dmaengine=0 drm.edid_firmware=HDMI-A-1:edid/edid.bin quiet
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x09bf] usable
[0.00] BIOS-e820: [mem 0x09c0-0x09d80fff] reserved
[0.00] BIOS-e820: [mem 0x09d81000-0x09ef] usable
[0.00] BIOS-e820: [mem 0x09f0-0x09f0afff] ACPI NVS
[0.00] BIOS-e820: [mem 0x09f0b000-0xb8d8dfff] usable
[0.00] BIOS-e820: [mem 0xb8d8e000-0xbbd7dfff] reserved
[0.00] BIOS-e820: [mem 0xbbd7e000-0xbdd7dfff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbdd7e000-0xbddfdfff] ACPI data
[0.00] BIOS-e820: [mem 0xbddfe000-0xbeff] usable
[0.00] BIOS-e820: [mem 0xbf00-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xfd20-0xfd2f] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed80fff] reserved
[0.00] BIOS-e820: [mem 0x0001-0x0002beff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: update [mem 0xb3ff1018-0xb3fff057] usable ==> usable
[0.00] e820: update [mem 0xb3ff1018-0xb3fff057] usable ==> usable
[0.00] e820: update [mem 0xb3fe3018-0xb3ff0457] usable ==> usable
[0.00] e820: update [mem 0xb3fe3018-0xb3ff0457] usable ==> usable
[0.00] extended physical RAM map:
[0.00] reserve setup_data: [mem 0x-0x0009efff] 
usable
[0.00] reserve setup_data: [mem 0x0009f000-0x0009] 
reserved
[0.00] reserve setup_data: [mem 0x000e-0x000f] 
reserved
[0.00] reserve setup_data: [mem 0x0010-0x09bf] 
usable
[0.00] reserve setup_data: [mem 0x09c0-0x09d80fff] 
reserved
[0.00] reserve setup_data: [mem 0x09d81000-0x09ef] 
usable
[0.00] reserve setup_data: [mem 0x09f0-0x09f0afff] 
ACPI NVS
[0.00] reserve setup_data: [mem 0x09f0b000-0xb3fe3017] 
usable
[0.00] reserve setup_data: [mem 0xb3fe3018-0xb3ff0457] 
usable
[0.00] reserve setup_data: [mem 0xb3ff0458-0xb3ff1017] 
usable
[0.00] reserve setup_data: [mem 0xb3ff1018-0xb3fff057] 
usable
[0.00] reserve setup_data: [mem 0xb3fff058-0xb8d8dfff] 
usable
[0.00] reserve setup_data: [mem 0xb8d8e000-0xbbd7dfff] 
reserved
[0.00] reserve setup_data: [mem 0xbbd7e000-0xbdd7dfff] 
ACPI NVS
[0.00] reserve setup_data: [mem 0xbdd7e000-0xbddfdfff] 
ACPI data
[0.00] reserve setup_data: [mem 0xbddfe000-0xbeff] 
usable
[0.00] reserve setup_data: [mem 0xbf00-0xbfff] 
reserved
[0.00] reserve setup_data: [mem 0xfd20-0xfd2f] 
reserved
[0.00] reserve setup_data: [mem 0xfed8-0xfed80fff] 
reserved
[0.00] reserve setup_data: [mem 0x0001-0x0002beff] 
usable
[0.00] efi: EFI v2.70 by Lenovo
[0.00] efi: ACPI=0xbddfd000 ACPI 2.0=0xbddfd014 TPMFinalLog=0xbdc2d000 
SMBIOS=0xba72c000 SMBIOS 3.0=0xba71f000 MEMATTR=0xb6a92018 ESRT=0xb92c9000 
MOKvar=0xb6a83000 RNG=0xba839598 TPMEventLog=0xb418 
[0.00] efi: seeding entropy pool
[0.00] random: crng init done
[0.00] Kernel is locked down from EFI Secure Boot; see man 
kernel_lockdown.7
[0.00] secureboot: Secure boot enabled
[0.00] SMBIOS 3.1.1 present.
[0.00] DMI: LENOVO 20NECTO1WW/20NECTO1WW, BIOS R11ET45P (1.25 ) 
07/04/2022
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 2096.078 MHz processor
[0.15] e820: 

Bug#1002553: firmware-amd-graphics: Memory clock always at 100% (thinkpads w/ryzen 3XXXu)

2022-06-21 Thread ng
I tried on a separate partition to run Fedora with the firmware 
20220310,  and it works correctly there.  You were right.



Have a nice day.

El 12/06/22 a las 8:38, Diederik de Haas escribió:

Control: tag -1 - moreinfo
Control: forwarded -1 https://gitlab.freedesktop.org/drm/amd/-/issues/1455
Control: tag -1 fixed-upstream

On Sunday, 12 June 2022 06:59:12 CEST ng wrote:

Hi, I went on and installed the respective image from
https://snapshot.debian.org/package/linux/5.10.46-5/#linux-image-5.10.0-8-am
d64-unsigned_5.10.46-5 and had no luck, no change whatsoever.

Hi!

Thanks for testing, then this is a separate issue.

https://lore.kernel.org/linux-firmware/CADnq5_PYhDcR3tNYgzQ-uz80Nf++oMPsF3=huk+qcgntiy_...@mail.gmail.com/
is where a fix has been proposed+merged upstream (date: 2022-02-28).

An update of the firmware to version >= 20220310 _should_ fix this issue.
If such a version becomes available, could you test whether it indeed 
fixes

your issue and report your findings back to this bug report?

TIA,
Diederik




Bug#1002553: firmware-amd-graphics: Memory clock always at 100% (thinkpads w/ryzen 3XXXu)

2022-06-11 Thread ng
Hi,  I went on and installed the respective image from 
https://snapshot.debian.org/package/linux/5.10.46-5/#linux-image-5.10.0-8-amd64-unsigned_5.10.46-5 
and had no luck,  no change whatsoever.


Later next week I'll try running Fedora or Arch on a different drive to 
see if it has been corrected on the firmware/kernel side, like the git said.


El 10/06/22 a las 10:57, Diederik de Haas escribió:

Could you try *downgrading* your kernel to 5.10.46-5, to be found here:
https://snapshot.debian.org/package/linux/5.10.46-5/#linux-image-5.10.0-8-amd64-unsigned_5.10.46-5

The reason for this is https://bugs.debian.org/990312 with a possible 
similar

cause and therefor solution, which was part of 5.10.46-3.

The fix was reverting 2 commits wrt 'CP_MEC_DOORBELL_RANGE' and in
kernel 5.10.61 there was another commit related to that, and I'd like 
to know

if that caused a regression. I don't expect it, but it's better to verify.

The symptom of bug 990312 were easy to detect with:
cat /sys/class/drm/card0/device/gpu_busy_percent




Bug#995425: Possible to get fix to 5.10?

2021-10-08 Thread ng
Hello,  I was just wondering if in the near future this fix will be 
available for linux in the stable branch.


Thanks.



Bug#995425: linux-image-amd64: kernel BUG at fs/ext4/ext4_extents.h:199! (fast_commit feature)

2021-10-02 Thread ng

It fixes the issue!   Works correctly with that patch.


El 2/10/21 a las 3:52 a. m., Salvatore Bonaccorso escribió:

Control: tags -1 + moreinfo

On Thu, Sep 30, 2021 at 08:26:38PM -0500, Nelson G wrote:

Package: linux-image-amd64
Version: 5.10.46-5
Severity: normal

Hello,

There's a bug for the ext4 filesystem, when the fast_commit flag is enabled and
you use fallocate or any other task that allocates space.


You can easily reproduce this bug on a VM or raw hardware by doing the
following:

1° You'll need a drive formatted with ext4 of course.
2° Enable fast_commit in that drive:  tune2fs -O fast_commit /dev/yourdrive
3° mount 'yourdrive', and inside 'yourdrive' try the following: fallocate -l
2000MB file

Can you check if the following fixes your issue?

https://lore.kernel.org/linux-ext4/20210820044505.474318-1-hout...@huawei.com/

https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=dev=a2c2f0826e2b75560b31daf1cd9a755ab93cf4c6

Regards,
Salvatore




Bug#978084: CPU: 2 PID: 5507 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2548

2021-05-10 Thread NG

Hi there,
I cannot reproduce this bug anymore (tested with linux 5.10.28-1 aka 
linux 5.10.0-6-amd64 debian sid)



Great!
Peace.

El 8/05/21 a las 8:02 a. m., Salvatore Bonaccorso escribió:

is this still something you can reproduce with a recent 5.10.y kernel?

Regards,
Salvatore




Bug#978043: linux-image-5.10.0-trunk-amd64: irq 7: nobody cared (ryzen 3500u)

2021-05-08 Thread NG

Hello,

Since my bugzilla kernel report was a duplicate, I added myself to the 
following CC list: 201817 

No progress at all.  I'm currently running linux 5.10.0-6-amd64 
(5.10.28-1), in a sid installation.  And also tried linux 5.12.2 with 
fedora.  And is still the same.



El 8/05/21 a las 8:00 a. m., Salvatore Bonaccorso escribió:

Hi,

On Thu, Dec 24, 2020 at 07:17:29PM -0500, Neil wrote:

Package: src:linux
Version: 5.10.2-1~exp1
Severity: minor

Dear Maintainer,

Hello there,
I just wanted to report this dmesg message here,  I already reported it to
kernel.org and redhat's bugzilla (fedora),  but who knows, maybe reporting it
here before debian 11 gets released is worth it,  I hope it doesn't bother :)

can you reference the upstream report from you? Was there any
progress, is this fixed with a recent kernel or still reproducible?

Regards,
Salvatore


Bug#922658: linux-image-4.19.0-0.bpo.2-amd64: NETDEV WATCHDOG: enp1s0f1 (r8169): transmit queue 0 timed out

2019-02-18 Thread NG
Package: src:linux
Version: 4.19.16-1~bpo9+1
Severity: normal

Dear Maintainer,

When enp1s0f1 is under heavy download stress (downloading large files, watching
a stream, or even when installing debian packages) it tends to hang. Depending
on which download activity it's being ran, downloads will remain active but
with 0Kbpps, some others will just get canceled.
Best thing to do it's to run 'sudo modprobe -r r8169 && sudo modprobe r8169',
restarting networkmanager does nothing.  But sometimes it doesn't solve the
problem, not even rebooting does the trick network manager applet will say that
the network it's being connected but it never reaches connected state. So the
best thing to do it's to power off the computer completely and then power on
again freshly.

I've been experiencing this since kernel 4.19 bpo.1 but it got worse with bpo.2
(I tested Fedora with kernel 4.20.8 and it's even worse, same with debian's
testing and unstable branch)




-- Package-specific info:
** Version:
Linux version 4.19.0-0.bpo.2-amd64 (debian-kernel@lists.debian.org) (gcc
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.16-1~bpo9+1
(2019-02-07)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-0.bpo.2-amd64 root=/dev/mapper/firebolt-root ro
amdgpu.dpm=0 amdgpu.dc=0 quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

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

** Model information
sys_vendor: Acer
product_name: Aspire A515-41G
product_version: V1.09
chassis_vendor: Acer
chassis_version: V1.09
bios_vendor: Insyde Corp.
bios_version: V1.09
board_vendor: BR
board_name: Wartortle_BS
board_version: V1.09

** Loaded modules:
rfcomm
pci_stub
vboxpci(OE)
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
ctr
ccm
fuse
bnep
btusb
arc4
btrtl
btbcm
btintel
bluetooth
amdkfd
amdgpu
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
drbg
ansi_cprng
ecdh_generic
media
rtsx_pci_ms
joydev
memstick
rtsx_pci_sdmmc
mmc_core
edac_mce_amd
kvm_amd
dcdbas
dell_wmi_descriptor
wmi
ccp
rng_core
ath10k_pci
ath10k_core
kvm
ath
chash
mac80211
snd_hda_codec_realtek
gpu_sched
snd_hda_codec_generic
ttm
snd_hda_codec_hdmi
irqbypass
xhci_pci
snd_hda_intel
snd_hda_codec
xhci_hcd
snd_hda_core
r8169
crct10dif_pclmul
snd_hwdep
rtsx_pci
cfg80211
snd_pcm
libphy
drm_kms_helper
ehci_pci
crc32_pclmul
ehci_hcd
usbcore
snd_timer
i2c_piix4
rfkill
ghash_clmulni_intel
snd
drm
sg
soundcore
psmouse
usb_common
k10temp
fam15h_power
video
i2c_algo_bit
battery
ac
button
pcc_cpufreq
acpi_cpufreq
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
dm_crypt
dm_mod
sd_mod
crc32c_intel
ahci
libahci
libata
aesni_intel
aes_x86_64
crypto_simd
cryptd
glue_helper
evdev
scsi_mod
serio_raw

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:1576]
Subsystem: Acer Incorporated [ALI] Device [1025:1201]
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Carrizo [1002:9874] (rev c8) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Carrizo [1025:1201]
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: amdgpu
Kernel modules: amdgpu

00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Kabini
HDMI/DP Audio [1002:9840]
Subsystem: Acer Incorporated [ALI] Kabini HDMI/DP Audio [1025:1201]
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: snd_hda_intel
Kernel modules: snd_hda_intel

00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:157b]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device
[1022:157c] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:03.0 Host bridge