Bug#1077516: amdgpu (xorg) crashes with kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled
Package: firmware-amd-graphics Version: 20230210-5 *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? Occasionally, the screen of my Lenovo/T14s goes black or the X-session is restarted. Here is a procedure how reproduce this issue: - running the installer of flowjo [1] within wine [2] crashes the x-sessions or the [1] https://fjinstallers.s3.amazonaws.com/FlowJo/FlowJo-Win64-10.10.0.exe [2] I used wine-devel (wine 9.13), but I expect this this will be reproducible with wine 8.x too. However, occassianally the issue occurs also in other cases. The logs during this crash are attached. After uninstalling "firmware-amd-graphics/20230210-5" from debian bookworm and rebooting the machine, the problem went away (also at the cost that no 2nd screen is available). Installing the more recent version of firmware-amd-graphics/20240709-1 from testing repository fixes this issue. Therefore, I believe that firmware-amd-graphics/20230210-5 is buggy, and the more recent version of firmware-amd-graphics should be used. *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.6 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-23-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-amd-graphics depends on no packages. firmware-amd-graphics recommends no packages. Versions of packages firmware-amd-graphics suggests: ii initramfs-tools 0.142Jul 29 15:27:49 pascal kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=834899, emitted seq=834901 Jul 29 15:27:49 pascal kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 23803 thread Xorg:cs0 pid 23804 Jul 29 15:27:49 pascal kernel: amdgpu :c3:00.0: amdgpu: GPU reset begin! Jul 29 15:27:49 pascal kernel: [drm] REG_WAIT timeout 1us * 10 tries - optc1_wait_for_state line:817 Jul 29 15:27:49 pascal kernel: [drm] REG_WAIT timeout 1us * 10 tries - optc1_wait_for_state line:817 Jul 29 15:27:49 pascal kernel: [drm] REG_WAIT timeout 1us * 10 tries - optc1_wait_for_state line:817 Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue Jul 29 15:27:50 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 Jul 29 15:27:50 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue Jul 29 15:27:51 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 Jul 29 15:27:51 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue Jul 29 15:27:51 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 Jul 29 15:27:51 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue Jul 29 15:27:51 pascal kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3 Jul 29 15:27:51 pascal kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue Jul 29 15:27:51 pascal kernel: [drm:gfx_v11_0_hw_fini [amdgpu]] *ERROR* failed to halt cp gfx
Bug#1050446: nfs over rdma between debian12 client and debian11 server can cause data corruption
Severity: wishlist We run more tests, and observed that pgrading the storage server to Debian12(/bookwork solves the issue. The storage server can be accessed through rdma from debian11 and 12. That means, the problem occurs only when the storage server is on debian11, the client is on debian11 mounted with proto=rdma. This information is good enough for us, as we'll upgrade first the storage server. Another workaround is to switch to proto=tcp As this issue (proto=rdma from debian12 client to debian11 server) is difficult to fix and a workaround exists, I'll downgrade the severity.
Bug#1050446: nfs over rdma between debian12 client and debian11 server can cause data corruption
Package: nfs-common,rdma-core I've been testing the upgrade of a compute node from Debian11 to Debian12. That node was connected through nfs with rdma protocol to a zfs-storage server running on Debian11. The compute node and the storage server are part of a high-performance compute cluster, connected over infiniband. Not sure whether this is important, but the storage server is using zfs. After the upgrade of the compute node (node client) to Debian 12, this machine could not correctly read a few (small) files. The files were correctly shown with "ls", and the size matched as well. However the content was corrupted (looked like random garbage). In one case the .ssh/authorized_keys was corrupted, in some other case the "version.lua" from the lmod system was affected, rendering lmod unusable. Interestingly, only very few files seemed to be affected. Most files were correctly retrieved. So this is a very subtle error, and not obvious. When retrieving these files, no error was reported, but data of the expected size was retrieved. Effectively, the retrieved data was corrupted, and could lead to potential data loss. The compute node on Debian12 had ii libnfsidmap1:amd641:2.6.2-4 amd64NFS idmapping library ii nfs-common1:2.6.2-4 amd64NFS support files common to client and server ii librdmacm1:amd64 44.0-2 amd64Library for managing RDMA connections ii rdma-core 44.0-2 amd64RDMA core userspace infrastructure and documentation ii rdmacm-utils 44.0-2 amd64Examples for the librdmacm library The storage server on Debian11 had ii nfs-common 1:1.3.4-6 amd64 NFS support files common to client and server ii nfs-kernel-server 1:1.3.4-6 amd64 support for NFS kernel server ii librdmacm1:amd64 33.2-1 amd64 Library for managing RDMA connections The problem went away, when changing nfs mount protocal from proto=rdma to proto=tcp. I tried to learn about this incompatibility, but did not find any information. I'm also curious whether an nfs 2.6 server would correctly talk to an nfs 1.3 client over rdma ? Can anyone provide more information on that topic ?
Bug#924913: trackpad on L480 unusable after upgrade to testing
Am 5/31/21 um 8:19 AM schrieb Alois Schlögl: Am 5/29/21 um 1:59 PM schrieb Salvatore Bonaccorso: Control: tags -1 + moreinfo Hi Alois, On Fri, May 31, 2019 at 09:24:03PM +0200, Romain Perier wrote: On Wed, May 29, 2019 at 05:54:22PM +0200, Alois Schlögl wrote: On 3/26/19 9:03 PM, Romain Perier wrote: On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote: On 3/18/19 7:46 PM, Romain Perier wrote: On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote: On 3/18/19 12:20 PM, Romain Perier wrote: Hello, On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote: Source: linux Severity: normal Dear Maintainer, On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 (testing). After the upgrade, the touchpad and the trackpoint was not usable anymore. This already has some bug report here, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 As a workaround, one can run the command, sudo sh -c 'echo -n "elantech"> /sys/bus/serio/devices/serio1/protocol' in order to use the touchpad. However, on a GUI Interface and without an external mouse, it's impossible to apply this workaround (switching to the terminal -F1, login, and run the command above might work) I expect to be able to use the touchpad just out of the box, not needing to run the above workaround Could you : - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and confirm or not is the problem still exists ? Dear Romain I upgraded the kernel and rebooted: schloegl@debian10:~$ uname -a Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux With this kernel the trackpoint is working, the trackpad is still not usable. (This improves the situation because now at least one pointer device is available). Good, we did some progress :) - According to the bug on launchpad and to the fix pushed upstream, the fix seems to be an hardware quirks, could you give me the output of the following command : $ /sys/bus/serio/devices/serio1/firmware_id root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id PNP: LEN2036 PNP0f13 Could you test the patch attached to this reply ? (if you don't know how to do this, I can provide support) Regards, Romain I tried to followed these instructions: https://kernel-team.pages.debian.net/kernel-handbook/ch-comm 4.5. Building a custom kernel from Debian kernel source Specifically using the patched the sources, *scripts/config --disable MODULE_SIG* **scripts/config --disable DEBUG_INFO** ||*|make clean|* ||*|make deb-pkg |* and ended up with a kernel that does not boot (missing HD audio firmware), Which procedure do you recommend to build and install a modified kernel ? Hi, Section 4.2 from https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official , until test-patches should work. For the test-patches script, use the flavour and a featureset as argument, when you invoke it, like this : # debian/bin/test-patches -f amd64 -s none /path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch This will apply the patch on the fly, configure the kernel for amd64 and build a version with a special changelog entry and a special suffix version dedicated to the test version you generate. In case of troubles, I can provide another way, from git with few commands. Hope this helps, Regards, Romain Dear Romain, your instructions to build the kernel worked fine, when trying to install the kernel, sudo dpkg -i linux-headers-4.19.0-5-amd64_4.19.37-3a~test_amd64.deb linux-image-4.19.0-5-amd64-unsigned_4.19.37-3a~test_amd64.deb I run into problem, getting this warning. │ You are running a kernel (version 4.19.0-5-amd64) and attempting to remove the same version. │ │ │ │ This can make the system unbootable as it will remove /boot/vmlinuz-4.19.0-5-amd64 and all modules under the directory /lib/modules/4.19.0-5-amd64. This can only be fixed with a copy │ │ of the kernel image and the corresponding modules. │ │ │ │ It is highly recommended to abort the kernel removal unless you are prepared to fix the system after removal. │ │ │ │ Abort kernel removal? I'm not sure if I'm "prepared to fix the system". Can you recommend a reasonable save way to go forward ? Cheers, Alois Hello, Well, this is something I have tested here myself, from the linux git repository (on salsa.debian.org). I have built a 4.19.37-4a~test with the patch , then I have forced the install with the same question than you. And he did the trick ! So what you can do is: - When the dialog interface (the blue one) asks you to abort or continue the install, press "no" to don't abort and continue the install - Once done, you can reboot - Check that the boot is working fine and you're running the inte
Bug#924913: trackpad on L480 unusable after upgrade to testing
Am 5/29/21 um 1:59 PM schrieb Salvatore Bonaccorso: Control: tags -1 + moreinfo Hi Alois, On Fri, May 31, 2019 at 09:24:03PM +0200, Romain Perier wrote: On Wed, May 29, 2019 at 05:54:22PM +0200, Alois Schlögl wrote: On 3/26/19 9:03 PM, Romain Perier wrote: On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote: On 3/18/19 7:46 PM, Romain Perier wrote: On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote: On 3/18/19 12:20 PM, Romain Perier wrote: Hello, On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote: Source: linux Severity: normal Dear Maintainer, On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 (testing). After the upgrade, the touchpad and the trackpoint was not usable anymore. This already has some bug report here, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 As a workaround, one can run the command, sudo sh -c 'echo -n "elantech"> /sys/bus/serio/devices/serio1/protocol' in order to use the touchpad. However, on a GUI Interface and without an external mouse, it's impossible to apply this workaround (switching to the terminal -F1, login, and run the command above might work) I expect to be able to use the touchpad just out of the box, not needing to run the above workaround Could you : - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and confirm or not is the problem still exists ? Dear Romain I upgraded the kernel and rebooted: schloegl@debian10:~$ uname -a Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux With this kernel the trackpoint is working, the trackpad is still not usable. (This improves the situation because now at least one pointer device is available). Good, we did some progress :) - According to the bug on launchpad and to the fix pushed upstream, the fix seems to be an hardware quirks, could you give me the output of the following command : $ /sys/bus/serio/devices/serio1/firmware_id root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id PNP: LEN2036 PNP0f13 Could you test the patch attached to this reply ? (if you don't know how to do this, I can provide support) Regards, Romain I tried to followed these instructions: https://kernel-team.pages.debian.net/kernel-handbook/ch-comm 4.5. Building a custom kernel from Debian kernel source Specifically using the patched the sources, *scripts/config --disable MODULE_SIG* **scripts/config --disable DEBUG_INFO** ||*|make clean|* ||*|make deb-pkg |* and ended up with a kernel that does not boot (missing HD audio firmware), Which procedure do you recommend to build and install a modified kernel ? Hi, Section 4.2 from https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official , until test-patches should work. For the test-patches script, use the flavour and a featureset as argument, when you invoke it, like this : # debian/bin/test-patches -f amd64 -s none /path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch This will apply the patch on the fly, configure the kernel for amd64 and build a version with a special changelog entry and a special suffix version dedicated to the test version you generate. In case of troubles, I can provide another way, from git with few commands. Hope this helps, Regards, Romain Dear Romain, your instructions to build the kernel worked fine, when trying to install the kernel, sudo dpkg -i linux-headers-4.19.0-5-amd64_4.19.37-3a~test_amd64.deb linux-image-4.19.0-5-amd64-unsigned_4.19.37-3a~test_amd64.deb I run into problem, getting this warning. │ You are running a kernel (version 4.19.0-5-amd64) and attempting to remove the same version. │ │ │ │ This can make the system unbootable as it will remove /boot/vmlinuz-4.19.0-5-amd64 and all modules under the directory /lib/modules/4.19.0-5-amd64. This can only be fixed with a copy │ │ of the kernel image and the corresponding modules. │ │ │ │ It is highly recommended to abort the kernel removal unless you are prepared to fix the system after removal. │ │ │ │ Abort kernel removal? I'm not sure if I'm "prepared to fix the system". Can you recommend a reasonable save way to go forward ? Cheers, Alois Hello, Well, this is something I have tested here myself, from the linux git repository (on salsa.debian.org). I have built a 4.19.37-4a~test with the patch , then I have forced the install with the same question than you. And he did the trick ! So what you can do is: - When the dialog interface (the blue one) asks you to abort or continue the install, press "no" to don't abort and continue the install - Once done, you can reboot - Check that the boot is working fine and you're running the intended kernel: 4.19.37-3a~test (via uname -a) - Check if your problem is
Bug#983255: firmware-realtek: Direct firmware load for rtw88/rtw8821c_fw.bin failed with error -2
Package: firmware-realtek Version: 20210208-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? security update, on linux backports kernel (upgrade from 5.9 to 5.10) * What exactly did you do (or not do) that was effective (or ineffective)? apt update && apt upgrade && reboot * What was the outcome of this action? wlan adapter was not available after reboot dmesg has these lines: lspci | grep -i wire 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe Wireless Network Adapter dmesg contains these lines: [4.938468] rtw_8821ce :02:00.0: Direct firmware load for rtw88/rtw8821c_fw.bin failed with error -2 [4.938472] rtw_8821ce :02:00.0: failed to request firmware [4.938543] rtw_8821ce :02:00.0: failed to load firmware [4.938571] rtw_8821ce :02:00.0: failed to setup chip efuse info [4.938599] rtw_8821ce :02:00.0: failed to setup chip information [4.939514] rtw_8821ce: probe of :02:00.0 failed with error -22 tried to install also latest firmware-realtek from unstable ii firmware-realtek20210208-1 all Binary firmware for Realtek wired/wifi/BT adapters but this did also not change anything. * What outcome did you expect instead? wlan working as before. *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de_AT:de (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-realtek depends on no packages. firmware-realtek recommends no packages. Versions of packages firmware-realtek suggests: ii initramfs-tools 0.133+deb10u1 -- no debconf information
Bug#924913: trackpad on L480 unusable after upgrade to testing
On 3/26/19 9:03 PM, Romain Perier wrote: > On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote: >> On 3/18/19 7:46 PM, Romain Perier wrote: >>> On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote: >>>> On 3/18/19 12:20 PM, Romain Perier wrote: >>>>> Hello, >>>>> >>>>> On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote: >>>>>> Source: linux >>>>>> Severity: normal >>>>>> >>>>>> Dear Maintainer, >>>>>> >>>>>> On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 >>>>>> (testing). >>>>>> After the upgrade, the touchpad and the trackpoint was not usable >>>>>> anymore. >>>>>> >>>>>> >>>>>> This already has some bug report here, >>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 >>>>>> >>>>>> As a workaround, one can run the command, >>>>>> sudo sh -c 'echo -n "elantech"> >>>>>> /sys/bus/serio/devices/serio1/protocol' >>>>>> in order to use the touchpad. However, on a GUI Interface and without >>>>>> an external mouse, it's impossible to apply this workaround >>>>>> (switching to the terminal -F1, login, and run the command >>>>>> above might work) >>>>>> >>>>>> I expect to be able to use the touchpad just out of the box, not >>>>>> needing >>>>>> to run the above workaround >>>>>> >>>>> Could you : >>>>> >>>>> - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and >>>>> confirm or >>>>> not is the problem still exists ? >>>> Dear Romain >>>> >>>> >>>> I upgraded the kernel and rebooted: >>>> >>>> schloegl@debian10:~$ uname -a >>>> Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) >>>> x86_64 GNU/Linux >>>> >>>> >>>> With this kernel the trackpoint is working, the trackpad is still not >>>> usable. >>>> >>>> (This improves the situation because now at least one pointer device is >>>> available). >>>> >>>> >>> Good, we did some progress :) >>> >>>>> - According to the bug on launchpad and to the fix pushed upstream, the >>>>> fix seems to be an hardware quirks, could you give me the output of the >>>>> following command : >>>>> $ /sys/bus/serio/devices/serio1/firmware_id >>>> root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id >>>> PNP: LEN2036 PNP0f13 >>>> >>> Could you test the patch attached to this reply ? >>> (if you don't know how to do this, I can provide support) >>> >>> Regards, >>> Romain >> >> >> I tried to followed these instructions: >> >> https://kernel-team.pages.debian.net/kernel-handbook/ch-comm >> >> 4.5. Building a custom kernel from Debian kernel source >> >> Specifically using the patched the sources, >> >> *scripts/config --disable MODULE_SIG* >> **scripts/config --disable DEBUG_INFO** >> ||*|make clean|* ||*|make deb-pkg >> >> |* >> >> and ended up with a kernel that does not boot (missing HD audio firmware), >> >> >> Which procedure do you recommend to build and install a modified kernel ? >> >> > Hi, > > Section 4.2 from > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official > , until test-patches should work. For the test-patches script, use the > flavour and a > featureset as argument, when you invoke it, like this : > > # debian/bin/test-patches -f amd64 -s none > /path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch > > This will apply the patch on the fly, configure the kernel for amd64 > and build a version with a special changelog entry and a special suffix > version dedicated to the test version you generate. > > > In case of troubles, I can provide another way, from git with few > commands. > > > Hope this helps, > Regards, > Romain Dear Romain, your instructions to build the kernel worked fine, when trying to install the kernel, sudo dpkg -i linux-
Bug#924913: trackpad on L480 unusable after upgrade to testing
On 3/18/19 7:46 PM, Romain Perier wrote: > On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote: >> On 3/18/19 12:20 PM, Romain Perier wrote: >>> Hello, >>> >>> On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote: >>>> Source: linux >>>> Severity: normal >>>> >>>> Dear Maintainer, >>>> >>>> On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 >>>> (testing). >>>> After the upgrade, the touchpad and the trackpoint was not usable >>>> anymore. >>>> >>>> >>>> This already has some bug report here, >>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 >>>> >>>> As a workaround, one can run the command, >>>> sudo sh -c 'echo -n "elantech"> >>>> /sys/bus/serio/devices/serio1/protocol' >>>> in order to use the touchpad. However, on a GUI Interface and without >>>> an external mouse, it's impossible to apply this workaround >>>> (switching to the terminal -F1, login, and run the command >>>> above might work) >>>> >>>> I expect to be able to use the touchpad just out of the box, not needing >>>> to run the above workaround >>>> >>> Could you : >>> >>> - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and >>> confirm or >>> not is the problem still exists ? >> Dear Romain >> >> >> I upgraded the kernel and rebooted: >> >> schloegl@debian10:~$ uname -a >> Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) >> x86_64 GNU/Linux >> >> >> With this kernel the trackpoint is working, the trackpad is still not >> usable. >> >> (This improves the situation because now at least one pointer device is >> available). >> >> > Good, we did some progress :) > >>> - According to the bug on launchpad and to the fix pushed upstream, the >>> fix seems to be an hardware quirks, could you give me the output of the >>> following command : >>> $ /sys/bus/serio/devices/serio1/firmware_id >> root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id >> PNP: LEN2036 PNP0f13 >> > Could you test the patch attached to this reply ? > (if you don't know how to do this, I can provide support) > > Regards, > Romain I tried to followed these instructions: https://kernel-team.pages.debian.net/kernel-handbook/ch-comm 4.5. Building a custom kernel from Debian kernel source Specifically using the patched the sources, *scripts/config --disable MODULE_SIG* **scripts/config --disable DEBUG_INFO** ||*|make clean|* ||*|make deb-pkg |* and ended up with a kernel that does not boot (missing HD audio firmware), Which procedure do you recommend to build and install a modified kernel ? Regards, Alois
Bug#924913: trackpad on L480 unusable after upgrade to testing
On 3/18/19 12:20 PM, Romain Perier wrote: > Hello, > > On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote: >> Source: linux >> Severity: normal >> >> Dear Maintainer, >> >> On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 >> (testing). >> After the upgrade, the touchpad and the trackpoint was not usable >> anymore. >> >> >> This already has some bug report here, >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 >> >> As a workaround, one can run the command, >> sudo sh -c 'echo -n "elantech"> >> /sys/bus/serio/devices/serio1/protocol' >> in order to use the touchpad. However, on a GUI Interface and without >> an external mouse, it's impossible to apply this workaround >> (switching to the terminal -F1, login, and run the command >> above might work) >> >> I expect to be able to use the touchpad just out of the box, not needing >> to run the above workaround >> > Could you : > > - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and > confirm or > not is the problem still exists ? Dear Romainm I upgraded the kernel and rebooted: schloegl@debian10:~$ uname -a Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux With this kernel the trackpoint is working, the trackpad is still not usable. (This improves the situation because now at least one pointer device is available). > - According to the bug on launchpad and to the fix pushed upstream, the > fix seems to be an hardware quirks, could you give me the output of the > following command : > $ /sys/bus/serio/devices/serio1/firmware_id root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id PNP: LEN2036 PNP0f13 > > Thanks, > Regards, > Romain Thank You, Alois >> -- System Information: >> Debian Release: buster/sid >> APT prefers testing >> APT policy: (990, 'testing'), (500, 'stable') >> Architecture: amd64 (x86_64) >> >> Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) >> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE >> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), >> LANGUAGE=en_US:en (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: systemd (via /run/systemd/system) >> LSM: AppArmor: enabled
Bug#924913: trackpad on L480 unusable after upgrade to testing
Source: linux Severity: normal Dear Maintainer, On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10 (testing). After the upgrade, the touchpad and the trackpoint was not usable anymore. This already has some bug report here, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600 As a workaround, one can run the command, sudo sh -c 'echo -n "elantech"> /sys/bus/serio/devices/serio1/protocol' in order to use the touchpad. However, on a GUI Interface and without an external mouse, it's impossible to apply this workaround (switching to the terminal -F1, login, and run the command above might work) I expect to be able to use the touchpad just out of the box, not needing to run the above workaround -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#911743: enabling orange-fs in linux
Package: linux Version: unstable Severity: wishlist Source: linux We are looking into distributed, parallel filesystems like beegfs and orangefs. I'd prefer orangefs (mainly because of its license terms). We'd like to use Debian/stable for this set up, unfortunately, the current debian kernel has orange-fs support disabled. Based on an initial response from https://lists.debian.org/debian-kernel/2018/10/msg00181.html I'm asking to enable orange-fs support in the linux kernel Thanks for considering, Alois
