Bug#1022126: New mainline kernel is out fixes for example 1022126 bug
Hello Salvatore, sorry for the delay. So lets hope, this will solve the problem for all the affected people. On Fri, 2023-03-10 at 17:11 +0100, Salvatore Bonaccorso wrote: > Hello Marc-Robin, > > > > Anyhow I had some errors: > > > > qla2xxx :61:00.1: swiotlb buffer is full (sz: 65536 bytes), > > total > > 32768 (slots), used 28799 (slots) > > > > But I'm not sure, if this is releated and it doesn't affect > > functions. > > > > Do you need further informations about the testing process? > > I assume this has to be tackled separately. You can confim it was not > seen before in earlier kernels? > > I checked with last working Kernel 5.10.136-1 and same errors there. So not related to our problem. Seems like is related to LVM. Thanks for you efforts. Greets Marc-Robin
Bug#1022126: New mainline kernel is out fixes for example 1022126 bug
Hello Salvatore, I followed instructions and it made me a linux-image-5.10.0-21-amd64- unsigned_5.10.162-1a~test_amd64.deb, which, after installed, boots nicely and seems to work without errors at mpt3sas anymore. All XEN-functionality seems to work in our environment. Anyhow I had some errors: qla2xxx :61:00.1: swiotlb buffer is full (sz: 65536 bytes), total 32768 (slots), used 28799 (slots) But I'm not sure, if this is releated and it doesn't affect functions. Do you need further informations about the testing process? -- Greetings Marc-Robin On Wed, 2023-03-08 at 17:38 +0100, Salvatore Bonaccorso wrote: > Hi Marc, > > On Sat, Mar 04, 2023 at 12:09:15PM +0100, Marc-Robin Wendt wrote: > > Its actually not my game, but if it speeds things up, I will help > > testing (if anyone tells me, what to do). > > Thank you. Can you try with the following series of 4 patches. > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > > will describe how to pass a series of patches to apply for testing. > > Thanks already in advance, > > Regards, > Salvatore
Bug#1022126: New mainline kernel is out fixes for example 1022126 bug
Its actually not my game, but if it speeds things up, I will help testing (if anyone tells me, what to do). On Sat, 2023-03-04 at 10:11 +0100, Salvatore Bonaccorso wrote: > Hi Marc-Robin, > > On Sat, Mar 04, 2023 at 09:36:35AM +0100, Marc-Robin Wendt wrote: > > Ok folks. That's it now. I have a server farm with Debian+Xen and > > I'm > > stuck in a dead end, because this Bug gets not fixed. I delayed > > kernel > > updates since 5 month now, but can't delay anymore, because of CVE- > > 2022-42328, CVE-2022-42329 and CVE-2022-3643. > > > > So I have to change to Redhat now? Means my servers will be lost > > for > > Debian for a pretty while. It's a pity, because like this, Debian > > Project goes down the drain. Maybe the maintainers should think > > about > > priorities. Bugs like this usually don't affect end consumer > > devices, > > but the big server farm provider, who btw. donate a pretty much of > > ressources to the Debian Project. > > People involved appear to prefer to rant on this bug instead of > providing help and taking note of what was mentioned in > https://bugs.debian.org/1022126#117 and earlier replies and the fact > that the discussion was brought up to upstream by the Debian > maintainers an happens on the upstream regression list: > > https://lore.kernel.org/regressions/754b030c-ba14-167c-e2d0-2f4f5bf55...@leemhuis.info/ > > I take your mail such that you are willing to test accordingly > patches > which would be followed by the above thread? Including adding > Tested-by on needed-to-backport patches? > > Regards, > Salvatore >
Bug#1022126: New mainline kernel is out fixes for example 1022126 bug
Ok folks. That's it now. I have a server farm with Debian+Xen and I'm stuck in a dead end, because this Bug gets not fixed. I delayed kernel updates since 5 month now, but can't delay anymore, because of CVE- 2022-42328, CVE-2022-42329 and CVE-2022-3643. So I have to change to Redhat now? Means my servers will be lost for Debian for a pretty while. It's a pity, because like this, Debian Project goes down the drain. Maybe the maintainers should think about priorities. Bugs like this usually don't affect end consumer devices, but the big server farm provider, who btw. donate a pretty much of ressources to the Debian Project. Greetings Marc-Robin Wendt On Mon, 2023-02-20 at 10:30 +0100, vmxevils...@gmail.com wrote: > Hello dear mantainers, > > I have stopped sending kernel packages as per your request (you > defined it spamming). > For who might be interested I am making the 6.2.0 kernel amd64 > packages myself (the 6.2.0 kernel announcement is not yet > on https://tracker.debian.org/pkg/linux). > Since this version fixes bug 1022126 (and, I am sure others), > Since all the CVE announcements on the site I read are about past > kernels.. > If you would like I can send the packages to debian mentor or > wherever is most convenient for you, for testing and review. > Sorry for my past mistakes (still have to fully comprehend where was > I failing, since I was following the manuals, including the source > etc, I'd like you to be more clear for what concerns where just > following your procedures was failing). > > > Thanks > Renato Gallo
Bug#1022126: mpt3sas broken with xen dom0
Hello, same problem here with linux-image-5.10.0-19-amd64 version 5.10.149-2. Went back to kernel linux-image-5.10.0-17-amd64 ver. 5.10.136-1, which still works fine. Greetings Marc
Bug#886731: linux-image-4.9.0-4-amd64: DKMS sends system in suspend since linux-image-4.9.0-3-amd64
Hello Michael, no, I'm using Intel driver and cards. i915 is loaded. Problem is not solved anyway. I helped myself in disabling automatic suspend at all and have to do it manually now. Greetings Marc-Robin On Mon, 2019-03-18 at 00:15 +0100, Michael Biebl wrote: > Picking up this old bug report... > > > Are you using the proprietary nvidia driver or noveau? >
Bug#886731: linux-image-4.9.0-4-amd64: DKMS sends system in suspend since linux-image-4.9.0-3-amd64
Problem not solved. Running my laptop with unsecure old kernel. Any suggestions? Marc.
Bug#886731: linux-image-4.9.0-4-amd64: DKMS sends system in suspend since linux-image-4.9.0-3-amd64
On Fri, 2018-01-12 at 01:12 +, Ben Hutchings wrote: > On Thu, 2018-01-11 at 12:25 +0100, Marc-Robin Wendt wrote: > > Hello Ben and Michael, > > > > thanks for taking time. Of course its DPMS. Sorry for the typo. > > > > Reproducing the bug turns out, it first appears in linux-image- > > 4.9.0-4- > > amd64 and now linux-image-4.9.0-5-amd64. > > > > When I boot the system from grub with old kernel linux-image-4.9.0- > > 3- > > amd64 or linux-image-4.9.0-2-amd64, behavior is as expected ok, > > means > > switching off the monitor doesnt trigger suspend of the system. > > So are *you* switching off the monitor? You mentioned DPMS, which is > the way for the display adapter to control the monitor - it doesn't > involve any signalling in the other direction. > > And is the monitor attached to a VGA or digital port? If it's a > digital port, turning off power to the monitor will look exactly the > same as unplugging it... > I examined the problem more closely. Lid is closed, because the laptop is on the dock. Connection via display port. When I connect via HDMI there are no problems with turning on or off the monitor. It doesn't matter how the monitor is switched off, manual or screensaver or even by command from command line. The suspend is actually triggered when you switch the monitor on(!) again. I didn't noticed it so far, because it happens instantly, when you touch anything keyboard or mouse to wake up the monitor from screensaver. So, monitor is switched off, system runs, I even could ping it. Wake up the monitor will send the system into suspend. Even more strange behavior. Graphic card, see my first mail. Its a Lenovo T430s, so probably NVIDIA > > NVS 5200M inside. Monitor is LG 34UM88C-P. > > ...and if you have a laptop that is already closed, unplugging the > last > external display is *supposed* to trigger suspend by default. (The > same as when you have the laptop open with no external display, and > then close the laptop.) > So you imply the old kernel had a bug? When I have my laptop on the docking station, I want it to behave like a desktop. I least this was the behavior the last 20 years. So of course the lid is closed and turning off and on the last monitor shouldn't suspend the system. > But if this happens with the laptop still open, then this might be a > kernel problem with lid switch detection. > > Ben. > > > Attached is the journalctl output once with linux-image-4.9.0-3- > > amd64 > > booted and once with linux-image-4.9.0-4-amd64. > >
Bug#886731: linux-image-4.9.0-4-amd64: DKMS sends system in suspend since linux-image-4.9.0-3-amd64
Hello Ben and Michael, thanks for taking time. Of course its DPMS. Sorry for the typo. Reproducing the bug turns out, it first appears in linux-image-4.9.0-4- amd64 and now linux-image-4.9.0-5-amd64. When I boot the system from grub with old kernel linux-image-4.9.0-3- amd64 or linux-image-4.9.0-2-amd64, behavior is as expected ok, means switching off the monitor doesnt trigger suspend of the system. Graphic card, see my first mail. Its a Lenovo T430s, so probably NVIDIA NVS 5200M inside. Monitor is LG 34UM88C-P. Attached is the journalctl output once with linux-image-4.9.0-3-amd64 booted and once with linux-image-4.9.0-4-amd64. Regards Marc-Robin On Wed, 2018-01-10 at 21:50 +0100, Michael Biebl wrote: > Control: tags -1 + moreinfo > > On Wed, 10 Jan 2018 18:12:46 + Ben Hutchings <b...@decadent.org.uk > > > wrote: > > Control: reassign -1 systemd > > > > On Tue, 2018-01-09 at 11:50 +0100, Marc-Robin Wendt wrote: > > > Package: src:linux > > > Version: 4.9.65-3+deb9u1 > > > Severity: normal > > > > > > Dear Maintainer, > > > > > > since linux-image-4.9.0-3-amd64 DKMS sends my system into > > > suspend. > > > > I guess you mean DPMS (Display Power Management System). > > > > > Switching off the monitor causes suspend of the system. > > > With Kernel-Versions linux-image-4.9.0-1-amd64 and linux-image- > > > 4.9.0-2- > > > amd64 I had no problems. > > > This problem is rather annoying, when my system starts the > > > screensaver > > > after 10 min, the monitor switches off and sends the system into > > > suspend. Screensaver is not meant to send the system into > > > suspend. > > > > The standard Linux kernel does not decide when to suspend. This is > > usually controlled by systemd-logind. > > Ben, were there any DRM related changes in the kernel which would > explain, why 4.9.0-2 behaves differently then 4.9.0-1? > > Marc-Robin, can you run (as root) > systemd-analyze set-log-level debug > then run journalctl -f > and then trigger a suspend by letting the screensaver kick in. > Then attach the output of journalctl. > > Which graphics gard and desktop environment do you use? > Jan 11 09:24:34 schroeder systemd[1]: Setting log level to debug. Jan 11 09:24:34 schroeder systemd[1]: Sent message type=method_return sender=n/a destination=n/a object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Jan 11 09:24:34 schroeder systemd[1]: Got disconnect on private connection. Jan 11 09:24:41 schroeder dhclient[2640]: DHCPREQUEST of 130.149.88.98 on eth0 to 192.168.2.133 port 67 Jan 11 09:25:01 schroeder dhclient[2640]: DHCPREQUEST of 130.149.88.98 on eth0 to 192.168.2.133 port 67 Jan 11 09:25:01 schroeder systemd[1]: systemd-journald.service: Got notification message from PID 327 (WATCHDOG=1) Jan 11 09:25:01 schroeder CRON[3806]: pam_unix(cron:session): session opened for user root by (uid=0) Jan 11 09:25:01 schroeder CRON[3807]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Jan 11 09:25:01 schroeder CRON[3806]: pam_unix(cron:session): session closed for user root Jan 11 09:25:03 schroeder systemd[1]: systemd-udevd.service: Got notification message from PID 368 (WATCHDOG=1) Jan 11 09:25:03 schroeder systemd[1]: systemd-logind.service: Got notification message from PID 694 (WATCHDOG=1) -- Logs begin at Thu 2018-01-11 09:28:20 CET. -- Jan 11 09:29:38 schroeder systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=JobRemoved cookie=387 reply_cookie=0 error=n/a Jan 11 09:29:38 schroeder systemd[1]: Startup finished in 6.955s (kernel) + 1min 11.695s (userspace) = 1min 18.650s. Jan 11 09:29:38 schroeder systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=StartupFinished cookie=388 reply_cookie=0 error=n/a Jan 11 09:29:38 schroeder systemd[1]: systemd-update-utmp-runlevel.service: cgroup is empty Jan 11 09:29:38 schroeder systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/unit/systemd_2dupdate_2dutmp_2drunlevel_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=389 reply_cookie=0 error=n/a Jan 11 09:29:38 schroeder systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/unit/systemd_2dupdate_2dutmp_2drunlevel_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=390 reply_cookie=0 error=n/a Jan 11 09:29:38 schroeder systemd[1]: systemd-journald.service: Received EPOLLHUP on stored fd 41 (stored), closing. Jan 11 09:29:38 schroeder sy
Bug#886731: linux-image-4.9.0-4-amd64: DKMS sends system in suspend since linux-image-4.9.0-3-amd64
Package: src:linux Version: 4.9.65-3+deb9u1 Severity: normal Dear Maintainer, since linux-image-4.9.0-3-amd64 DKMS sends my system into suspend. Switching off the monitor causes suspend of the system. With Kernel-Versions linux-image-4.9.0-1-amd64 and linux-image-4.9.0-2- amd64 I had no problems. This problem is rather annoying, when my system starts the screensaver after 10 min, the monitor switches off and sends the system into suspend. Screensaver is not meant to send the system into suspend. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: LENOVO product_name: 2356G3G product_version: ThinkPad T430s chassis_vendor: LENOVO chassis_version: Not Available bios_vendor: LENOVO bios_version: G7ET92WW (2.52 ) board_vendor: LENOVO board_name: 2356G3G board_version: Not Defined ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09) Subsystem: Lenovo 3rd Gen Core processor DRAM Controller [17aa:21fb] 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: Lenovo 3rd Gen Core processor Graphics Controller [17aa:21fb] 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: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: Lenovo 7 Series/C210 Series Chipset Family USB xHCI Host Controller [17aa:21fb] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04) Subsystem: Lenovo 7 Series/C216 Chipset Family MEI Controller [17aa:21fb] 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: mei_me Kernel modules: mei_me 00:16.3 Serial controller [0700]: Intel Corporation 7 Series/C210 Series Chipset Family KT Controller [8086:1e3d] (rev 04) (prog-if 02 [16550]) Subsystem: Lenovo 7 Series/C210 Series Chipset Family KT Controller [17aa:21fb] 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: serial 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04) Subsystem: Lenovo 82579LM Gigabit Network Connection [17aa:21f3] 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: e1000e Kernel modules: e1000e 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) (prog-if 20 [EHCI]) Subsystem: Lenovo 7 Series/C216 Chipset Family USB Enhanced Host Controller [17aa:21fb] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) Subsystem: Lenovo 7 Series/C216 Chipset Family High Definition Audio Controller [17aa:21fb] 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:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4) (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-
Bug#800380: please in jessie
Can you please provide this fix in jessie or jessie-backports. Its an annoying bug and its not motivated, why I should use workarounds when it is fixed. Thanks.
