Bug#989152: linux: Mouse wheel support is broken after resume

[Julien AUBIN]

Le jeudi 27 mai 2021, 13:40:39 CEST Romain Perier a écrit :
> Le mer. 26 mai 2021 à 23:27, Julien AUBIN  a écrit :
> > Source: linux
> > Version: Mouse wheel behaviour is broken after resume
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > I've remarked that on a specific laptop the mouse wheel function is not
> > restored after resume. This is a regression that has been introduced
> > between Buster and Bullseye, and only occurs on one of my hosts.
> > 
> > Laptop model : Dell Latitude e6540
> > Mouse model : Microsoft Intellimouse 4500
> > Desktop environment : KDE
> > 
> > Steps to reproduce :
> > DO : boot the computer and open KDE
> > DO : open whatever application with a scrollbar and use the mouse scroll
> > wheel EXPECT : the scrolling works.
> > DO : suspend the computer to RAM for 5 minutes
> > DO : resume your activity
> > DO : open whatever application with a scrollbar and use the mouse scroll
> > wheel EXPECT : the scrolling works.
> > ACTUAL : the scrolling does not work.
> > 
> > Workaround : unplug and plug the mouse, or use a tool like resetmsmice (it
> > would be great to include it in the archive :
> > https://github.com/paulrichards321/resetmsmice )
> 
> Hi,
> 
> Could you monitor the corresponding input device by the help of
> "evtest" ? That's a userspace tool that
> dumps evdev events reported by the kernel to userspace (so we can
> check if the kernel exposes the scrolling
> to userspace after resume or not... perhaps that's a kernel issue,
> perhaps that's an issue in the upper layers)
> 
> Could you :
> 1. install evtest : apt install evtest
> 2. With evtest /dev/input/event  locate the device corresponding to
> your mouse: when you scroll you should see events. Something like:
> 
> time 1622115506.006606, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
> 
> 3. Then when you have found the right device, check that the scrolling
> event is working as expected before resume (via evtest)
> 
> Now test suspend and check if you see the scrolling event via evtest
> after resume.
> Once done, past your result here.
> 
> Regards,
> Romain

Hi,

I tested. Before suspend :

Testing ... (interrupt to exit)
Event: time 1622117938.523711, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value 30
Event: time 1622117938.523711, -- SYN_REPORT 
Event: time 1622117938.611699, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value 30
Event: time 1622117938.611699, -- SYN_REPORT 
Event: time 1622117938.627713, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value 30
Event: time 1622117938.627713, -- SYN_REPORT 
Event: time 1622117938.635705, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1622117938.635705, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value 30
Event: time 1622117938.635705, -- SYN_REPORT 
Event: time 1622117938.643686, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value 30
Event: time 1622117938.643686, -- SYN_REPORT 
Event: time 1622117938.651677, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value 30
Event: time 1622117938.651677, -- SYN_REPORT 
Event: time 1622117938.667746, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value 30
Event: time 1622117938.667746, -- SYN_REPORT 
Event: time 1622117938.691713, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1622117938.691713, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value 30
Event: time 1622117938.691713, -- SYN_REPORT 
Event: time 1622117938.723710, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value 30
Event: time 1622117938.723710, -- SYN_REPORT 
Event: time 1622117938.891708, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value 30
Event: time 1622117938.891708, -- SYN_REPORT 
Event: time 1622117938.963715, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value -30
Event: time 1622117938.963715, -- SYN_REPORT 
Event: time 1622117938.979698, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value -30
Event: time 1622117938.979698, -- SYN_REPORT 
Event: time 1622117938.987728, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value -60
Event: time 1622117938.987728, -- SYN_REPORT 
Event: time 1622117938.995722, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value -30
Event: time 1622117938.995722, -- SYN_REPORT 
Event: time 1622117939.003760, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1622117939.003760, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), 
value -60
Event: time 1622117939.003760, -- SYN_REPORT -

Bug#989152: linux: Mouse wheel support is broken after resume

[Julien AUBIN]

Source: linux
Version: Mouse wheel behaviour is broken after resume
Severity: normal

Dear Maintainer,

I've remarked that on a specific laptop the mouse wheel function is not
restored after resume. This is a regression that has been introduced between
Buster and Bullseye, and only occurs on one of my hosts.

Laptop model : Dell Latitude e6540
Mouse model : Microsoft Intellimouse 4500
Desktop environment : KDE

Steps to reproduce :
DO : boot the computer and open KDE
DO : open whatever application with a scrollbar and use the mouse scroll wheel
EXPECT : the scrolling works.
DO : suspend the computer to RAM for 5 minutes
DO : resume your activity
DO : open whatever application with a scrollbar and use the mouse scroll wheel
EXPECT : the scrolling works.
ACTUAL : the scrolling does not work.

Workaround : unplug and plug the mouse, or use a tool like resetmsmice (it
would be great to include it in the archive :
https://github.com/paulrichards321/resetmsmice )

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#930904: closed by Salvatore Bonaccorso (Bug#930904: fixed in linux 4.9.184-1)

[Julien Aubin]

b
>  11906f48a17b1046033042b1c4e44a98b41ad615 7692126 
> linux-headers-4.9.0-10-common_4.9.184-1_all.deb
>  f1e203b8ac0280eaaeb2b9b6a91bcefe5d5c90d0 3231900 
> linux-manual-4.9_4.9.184-1_all.deb
>  54a97f142afff5d697d4dafa353935b43df51ff3 96879532 
> linux-source-4.9_4.9.184-1_all.deb
>  675fbb16547924f28ef5a5ec7bdfff3da8b3e701 693392 
> linux-support-4.9.0-10_4.9.184-1_all.deb
> Checksums-Sha256:
>  bbf0086c83616e0d9d6bd5854b77eb6ceb06a672b94381fcd503926e389b6d09 125180 
> linux_4.9.184-1.dsc
>  71dcebacfec777b23e1f65d9147b21d0f20c0c909f6258b560ff2d2886920b03 94808164 
> linux_4.9.184.orig.tar.xz
>  0f32576e5a37d1012cab75a0f8a12d8311a247aa7af49fc594c79801c9628d45 1245040 
> linux_4.9.184-1.debian.tar.xz
>  d4831074bb2393bb37436c4305e6f9de4ee6da4b90ce025db5c02e68c573902f 12515092 
> linux-doc-4.9_4.9.184-1_all.deb
>  07f70033482e282e8a856e40440c867e0cba0f4a3d55120a124a989b3f5f43ef 5758230 
> linux-headers-4.9.0-10-common-rt_4.9.184-1_all.deb
>  0984b28912fea98903d9dfb7c27aca8ac6e14ce48e5922e045bee9809abcc2b3 7692126 
> linux-headers-4.9.0-10-common_4.9.184-1_all.deb
>  43dde9f1aa65b90f0a28ec59ac16b27de03fa35ef3191486a3

Bug#930904: linux-image-4.19.0-5-amd64: Latest kernel upgrades on unstable break Steam (link to fix included)

[Julien Aubin]

Package: src:linux
Version: 4.19.37-5
Severity: important

Dear Maintainer,

Latest security fixes in the kernel (from 4.19.37-4 onwards) break some
apps like at least Steam. The fix already exists as mentioned there :
https://www.phoronix.com/scan.php?page=news_item=Steam-Linux-Network-One-Line

A workaround exists for Steam but it may not be the case for other
apps.

Could you please backport the fix and re-release the kernel ?

Thanks and regards

-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-kernel@lists.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-5 (2019-06-19)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64
root=UUID=b762a3a5-b58c-46e5-9fbd-15927e33bdf9 ro apparmor=1
security=apparmor quiet

** Tainted: POE (12289)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[24717.439314]  cache: parent cpu1 should not be sleeping
[24717.439513] CPU1 is up
[24717.439534] smpboot: Booting Node 0 Processor 2 APIC 0x4
[24717.441249]  cache: parent cpu2 should not be sleeping
[24717.441460] CPU2 is up
[24717.441479] smpboot: Booting Node 0 Processor 3 APIC 0x6
[24717.443255]  cache: parent cpu3 should not be sleeping
[24717.443486] CPU3 is up
[24717.443505] smpboot: Booting Node 0 Processor 4 APIC 0x1
[24717.443993]  cache: parent cpu4 should not be sleeping
[24717.444307] CPU4 is up
[24717.444326] smpboot: Booting Node 0 Processor 5 APIC 0x3
[24717.444743]  cache: parent cpu5 should not be sleeping
[24717.444944] CPU5 is up
[24717.444960] smpboot: Booting Node 0 Processor 6 APIC 0x5
[24717.445376]  cache: parent cpu6 should not be sleeping
[24717.445594] CPU6 is up
[24717.445609] smpboot: Booting Node 0 Processor 7 APIC 0x7
[24717.446037]  cache: parent cpu7 should not be sleeping
[24717.446817] CPU7 is up
[24717.471699] ACPI: Waking up from system sleep state S3
[24717.472540] ACPI: EC: interrupt unblocked
[24717.510729] ACPI: EC: event unblocked
[24717.511197] sd 0:0:0:0: [sda] Starting disk
[24717.511202] sd 1:0:0:0: [sdb] Starting disk
[24717.511204] sd 2:0:0:0: [sdc] Starting disk
[24717.511208] sd 4:0:0:0: [sdd] Starting disk
[24717.512015] serial 00:06: activated
[24717.638422] nvme nvme0: Shutdown timeout set to 8 seconds
[24717.801991] usb 2-14: reset high-speed USB device number 11 using xhci_hcd
[24717.888248] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[24717.888263] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[24717.888306] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[24717.889184] ata1.00: supports DRM functions and may not be fully accessible
[24717.889484] ACPI BIOS Error (bug): Could not resolve
[\_SB.PCI0.SAT0.SPT5._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330)
[24717.889487] ACPI Error: Method parse/execution failed
\_SB.PCI0.SAT0.SPT5._GTF, AE_NOT_FOUND (20180810/psparse-516)
[24717.889942] ata1.00: supports DRM functions and may not be fully accessible
[24717.890490] ata1.00: configured for UDMA/133
[24717.905182] ata4.00: configured for UDMA/100
[24717.929649] ACPI BIOS Error (bug): Could not resolve
[\_SB.PCI0.SAT0.SPT5._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330)
[24717.929652] ACPI Error: Method parse/execution failed
\_SB.PCI0.SAT0.SPT5._GTF, AE_NOT_FOUND (20180810/psparse-516)
[24717.929657] ata6.00: configured for UDMA/100
[24718.434026] usb 2-14.1: reset low-speed USB device number 12 using xhci_hcd
[24718.990103] usb 2-14.2: reset low-speed USB device number 13 using xhci_hcd
[24719.546162] usb 2-14.3: reset low-speed USB device number 14 using xhci_hcd
[24719.847479] OOM killer enabled.
[24719.847481] Restarting tasks ...
[24719.847718] pci_bus :04: Allocating resources
[24719.847749] pci :03:00.0: PCI bridge to [bus 04]
[24719.847757] pci :03:00.0:   bridge window [io  0x2000-0x2fff]
[24719.847770] pci :03:00.0:   bridge window [mem 0xd200-0xd21f]
[24719.847779] pci :03:00.0:   bridge window [mem
0xd220-0xd23f 64bit pref]
[24719.870016] done.
[24719.875143] PM: suspend exit
[24720.535943] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[24722.913896] ata2: link is slow to respond, please be patient (ready=0)
[24722.929856] ata3: link is slow to respond, please be patient (ready=0)
[24722.929912] ata5: link is slow to respond, please be patient (ready=0)
[24725.149911] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[24725.151800] ata2.00: configured for UDMA/133
[24725.593906] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[24725.596123] ata3.00: configured for UDMA/100
[24726.725884] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[24726.726910] ACPI BIOS Error (bug): Could not resolve
[\_SB.PCI0.SAT0.SPT4._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330)
[24726.726916] ACPI Error: Method parse/execution failed
\_SB.PCI0.SAT0.SPT4._GTF, AE_NOT_FOUND (20180810/psparse-516)
[24726.728284] ACPI BIOS Error (bug): Could not 

Bug#920547: Crashes every few hours

[Julien Aubin]

On Sun, 27 Jan 2019 15:10:39 -0500 Chris Manougian  wrote:
> Hi Toni. I have an XPS  15 9570, which, I think, is basically the same
> machine, except yours uses an NVIDIA Quadro vs my GeForce GTX 1050Ti as a
> 2nd graphics card.
>
> A lot of problems with that secondary graphics card and linux.  Are you
> attempting to use it via Bumblebee?
>
> See this thread (and links within the thread) - BIOS related:
> https://bugzilla.redhat.com/show_bug.cgi?id=1610727
>
> I did my best to disable the NVIDIA card:
> https://wiki.archlinux.org/index.php/Dell_XPS_15_9570
>
> One of my more recent "important" gnome-logs file is:
>
> 03:16:35 kernel: ath10k_pci :3b:00.0: firmware: failed to load
> ath10k/cal-pci-:3b:00.0.bin (-2)
> 03:16:35 kernel: firmware_class: See https://wiki.debian.org/Firmware for
> information about missing firmware
> 03:16:35 kernel: ath10k_pci :3b:00.0: firmware: failed to load
> ath10k/pre-cal-pci-:3b:00.0.bin (-2)
> 03:16:34 kernel: iTCO_wdt iTCO_wdt: can't request region for resource [mem
> 0x00c5fffc-0x00c5]
> 03:16:34 kernel: ACPI Error: Skip parsing opcode OpcodeName unavailable
> (20180531/psloop-542)
> 03:16:34 kernel: ACPI Error: Skip parsing opcode OpcodeName unavailable
> (20180531/psloop-542)
> 03:16:34 kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
> (20180531/psobject-221)
> 03:16:34 kernel: ACPI BIOS Error (bug): Failure creating
> [\_SB.PCI0.XHC.RHUB.SS10._PLD], AE_ALREADY_EXISTS (20180531/dswload2-316)
> 03:16:34 kernel: ACPI Error: Skip parsing opcode OpcodeName unavailable
> (20180531/psloop-542)
> 03:16:34 kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
> (20180531/psobject-221)
> 03:16:34 kernel: ACPI BIOS Error (bug): Failure creating
> [\_SB.PCI0.XHC.RHUB.SS10._UPC], AE_ALREADY_EXISTS (20180531/dswload2-316)
> 03:16:34 kernel: ACPI Error: Skip parsing opcode OpcodeName unavailable
> (20180531/psloop-542)
> 03:16:34 kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
> (20180531/psobject-221)
> 03:16:34 kernel: ACPI BIOS Error (bug): Failure creating
> [\_SB.PCI0.XHC.RHUB.SS09._PLD], AE_ALREADY_EXISTS (20180531/dswload2-316)
> 03:16:34 kernel: ACPI Error: Skip parsing opcode OpcodeName unavailable
> (20180531/psloop-542)
> 03:16:34 kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
> (20180531/psobject-221)
> 03:16:34 kernel: ACPI BIOS Error (bug): Failure creating
> [\_SB.PCI0.XHC.RHUB.SS09._UPC], AE_ALREADY_EXISTS (20180531/dswload2-316)
> 03:16:34 kernel: ACPI Error: Skip parsing opcode OpcodeName unavailable
> (20180531/psloop-542)
> 03:16:34 kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
> (20180531/psobject-221)
> 03:16:34 kernel: ACPI BIOS Error (bug): Failure creating
> [\_SB.PCI0.XHC.RHUB.SS08._PLD], AE_ALREADY_EXISTS (20180531/dswload2-316)
> 03:16:34 kernel: ACPI Error: Skip parsing opcode OpcodeName unavailable
> (20180531/psloop-542)
> 03:16:34 kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
> (20180531/psobject-221)
> 03:16:34 kernel: ACPI BIOS Error (bug): Failure creating

Hi,

If it may help (I'm on testing w/ 4.9.12) this bug seems to be
NVidia-specific. Never encountered such things on my laptop which has
an AMD GPU with the FOSS driver. Reference is Dell Latitude e6540.

Rgds,

Re: Bug#919107: udev : suspend-to-ram randomly fails

[Julien Aubin]

Le lun. 14 janv. 2019 à 19:47, Julien Aubin  a écrit :
>
> Hi
>
> I could figure out a workaround :
> - my keyboard and mouse are usb devices plugged to my box with a KVM.
> - now if I unplug and then replug them to the kvm suspend works fine again.
>
> My mouse is a Microsoft Comfort Mouse 4500, my keyboard a Microsoft
> Wired Keyboard 600. The KVM is a Trendnet TK 214i.
>
> Le sam. 12 janv. 2019 à 21:36, Julien Aubin  a écrit :
> >
> > Le sam. 12 janv. 2019 à 21:25, Michael Biebl  a écrit :
> > >
> > > Control: reassign -1 linux-image-4.19.0-1-amd64
> > >
> > > Am 12.01.19 um 21:14 schrieb Julien Aubin:
> > > > Le sam. 12 janv. 2019 à 21:07, Michael Biebl  a écrit 
> > > > :
> > > >>
> > > >> Control: tags -1 + moreinfo
> > > >> On Sat, 12 Jan 2019 20:12:22 +0100 Julien Aubin 
> > > >> 
> > > >> wrote:
> > > >>> Package: udev
> > > >>> Version: 240-2
> > > >>> Severity: normal
> > > >>>
> > > >>> Dear Maintainer,
> > > >>>
> > > >>> After upgrading from Stretch to Buster I noticed that my computer had
> > > >>> problems suspending to RAM, basically it fails randomly. It was not 
> > > >>> the
> > > >>> case with Stretch.
> > > >>>
> > > >>> When trying to suspend to RAM the system displays briefly message :
> > > >>> "device usb-2-3 failed to suspend"
> > > >>
> > > >> That doesn't look like a udev problem.
> > > >> Please elaborate why you filed this against udev.
> > > >
> > > > Hi,
> > > >
> > > > Actually I see two possible suspects :
> > > > - The kernel itself
> > > > - Udev
> > > >
> > > > I dunno which one is involved but as it targets USB devices I thought 
> > > > of udev.
> > > >
> > > > If you think it targets the kernel, please reassign the ticket.
> > > >
> > >
> > > udev is not involved in the suspend process.
> > >
> > > Please attach the output of
> > > reportbug --template linux-image-4.19.0-1-amd64
> > > to the bug report so the kernel maintainers have some context.
> > >
> > > Michael
> > > --
> > > Why is it that all of the instruments seeking intelligent life in the
> > > universe are pointed away from Earth?
> > >
> >
> > Hi,
> >
> > Attached the report.
> >
> > Rgds

Hi all,

The problem actually came from KDE. Applying latest patches which
upgraded it to version 5.14.5-1 (was previously 5.14.3-1) solved the
issue. I guess it has something to see with KDE's own power daemons.

Rgds,

Re: Bug#919107: udev : suspend-to-ram randomly fails

[Julien Aubin]

Hi

I could figure out a workaround :
- my keyboard and mouse are usb devices plugged to my box with a KVM.
- now if I unplug and then replug them to the kvm suspend works fine again.

My mouse is a Microsoft Comfort Mouse 4500, my keyboard a Microsoft
Wired Keyboard 600. The KVM is a Trendnet TK 214i.

Le sam. 12 janv. 2019 à 21:36, Julien Aubin  a écrit :
>
> Le sam. 12 janv. 2019 à 21:25, Michael Biebl  a écrit :
> >
> > Control: reassign -1 linux-image-4.19.0-1-amd64
> >
> > Am 12.01.19 um 21:14 schrieb Julien Aubin:
> > > Le sam. 12 janv. 2019 à 21:07, Michael Biebl  a écrit :
> > >>
> > >> Control: tags -1 + moreinfo
> > >> On Sat, 12 Jan 2019 20:12:22 +0100 Julien Aubin 
> > >> wrote:
> > >>> Package: udev
> > >>> Version: 240-2
> > >>> Severity: normal
> > >>>
> > >>> Dear Maintainer,
> > >>>
> > >>> After upgrading from Stretch to Buster I noticed that my computer had
> > >>> problems suspending to RAM, basically it fails randomly. It was not the
> > >>> case with Stretch.
> > >>>
> > >>> When trying to suspend to RAM the system displays briefly message :
> > >>> "device usb-2-3 failed to suspend"
> > >>
> > >> That doesn't look like a udev problem.
> > >> Please elaborate why you filed this against udev.
> > >
> > > Hi,
> > >
> > > Actually I see two possible suspects :
> > > - The kernel itself
> > > - Udev
> > >
> > > I dunno which one is involved but as it targets USB devices I thought of 
> > > udev.
> > >
> > > If you think it targets the kernel, please reassign the ticket.
> > >
> >
> > udev is not involved in the suspend process.
> >
> > Please attach the output of
> > reportbug --template linux-image-4.19.0-1-amd64
> > to the bug report so the kernel maintainers have some context.
> >
> > Michael
> > --
> > Why is it that all of the instruments seeking intelligent life in the
> > universe are pointed away from Earth?
> >
>
> Hi,
>
> Attached the report.
>
> Rgds

Re: Bug#919107: udev : suspend-to-ram randomly fails

[Julien Aubin]

Le sam. 12 janv. 2019 à 21:36, Julien Aubin  a
écrit :

> Le sam. 12 janv. 2019 à 21:25, Michael Biebl  a écrit :
> >
> > Control: reassign -1 linux-image-4.19.0-1-amd64
> >
> > Am 12.01.19 um 21:14 schrieb Julien Aubin:
> > > Le sam. 12 janv. 2019 à 21:07, Michael Biebl  a
> écrit :
> > >>
> > >> Control: tags -1 + moreinfo
> > >> On Sat, 12 Jan 2019 20:12:22 +0100 Julien Aubin <
> julien.au...@gmail.com>
> > >> wrote:
> > >>> Package: udev
> > >>> Version: 240-2
> > >>> Severity: normal
> > >>>
> > >>> Dear Maintainer,
> > >>>
> > >>> After upgrading from Stretch to Buster I noticed that my computer had
> > >>> problems suspending to RAM, basically it fails randomly. It was not
> the
> > >>> case with Stretch.
> > >>>
> > >>> When trying to suspend to RAM the system displays briefly message :
> > >>> "device usb-2-3 failed to suspend"
> > >>
> > >> That doesn't look like a udev problem.
> > >> Please elaborate why you filed this against udev.
> > >
> > > Hi,
> > >
> > > Actually I see two possible suspects :
> > > - The kernel itself
> > > - Udev
> > >
> > > I dunno which one is involved but as it targets USB devices I thought
> of udev.
> > >
> > > If you think it targets the kernel, please reassign the ticket.
> > >
> >
> > udev is not involved in the suspend process.
> >
> > Please attach the output of
> > reportbug --template linux-image-4.19.0-1-amd64
> > to the bug report so the kernel maintainers have some context.
> >
> > Michael
> > --
> > Why is it that all of the instruments seeking intelligent life in the
> > universe are pointed away from Earth?
> >
>
> Hi,
>
> Attached the report.
>
> Rgds
>

Hi

I could figure out a workaround :
- my keyboard and mouse are usb devices plugged to my box with a KVM.
- now if I unplug and then replug them to the kvm suspend works fine again.

My mouse is a Microsoft Comfort Mouse 4500, my keyboard a Microsoft Wired
Keyboard 600. The KVM is a Trendnet TK 214i.

>

Re: Bug#919107: udev : suspend-to-ram randomly fails

[Julien Aubin]

Le sam. 12 janv. 2019 à 21:25, Michael Biebl  a écrit :
>
> Control: reassign -1 linux-image-4.19.0-1-amd64
>
> Am 12.01.19 um 21:14 schrieb Julien Aubin:
> > Le sam. 12 janv. 2019 à 21:07, Michael Biebl  a écrit :
> >>
> >> Control: tags -1 + moreinfo
> >> On Sat, 12 Jan 2019 20:12:22 +0100 Julien Aubin 
> >> wrote:
> >>> Package: udev
> >>> Version: 240-2
> >>> Severity: normal
> >>>
> >>> Dear Maintainer,
> >>>
> >>> After upgrading from Stretch to Buster I noticed that my computer had
> >>> problems suspending to RAM, basically it fails randomly. It was not the
> >>> case with Stretch.
> >>>
> >>> When trying to suspend to RAM the system displays briefly message :
> >>> "device usb-2-3 failed to suspend"
> >>
> >> That doesn't look like a udev problem.
> >> Please elaborate why you filed this against udev.
> >
> > Hi,
> >
> > Actually I see two possible suspects :
> > - The kernel itself
> > - Udev
> >
> > I dunno which one is involved but as it targets USB devices I thought of 
> > udev.
> >
> > If you think it targets the kernel, please reassign the ticket.
> >
>
> udev is not involved in the suspend process.
>
> Please attach the output of
> reportbug --template linux-image-4.19.0-1-amd64
> to the bug report so the kernel maintainers have some context.
>
> Michael
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>

Hi,

Attached the report.

Rgds


reportbug-linux-image-4.19.0-1-amd64-backup-20190112-32740-8o_gqlx3
Description: Binary data

Re: Re: Bug#888263: Spectre : release kernel 4.9.77 to stretch before p-u

[Julien Aubin]

Hi,

I guess the kernel will be rebuilt due to the ARM64 breakage but I confirm
it works fine on the following machines :
Intel Core i7 4790 w/ GeForce GTX 1070 and NVidia BLOB 384.111
Intel Core i7 4800 MQ
Intel Pentium N3700
AMD Phenom x4 9840 w/ GeForce GTX 970 and NVidia BLOB 384.111

However it seems that  the updated kernel does not fix against variant 1
and 2 of Spectre. :'(

Rgds

Bug#888263: Spectre : release kernel 4.9.77 to stretch before p-u

[Julien Aubin]

Le 24 janv. 2018 14:07, "Yves-Alexis Perez" <cor...@debian.org> a écrit :

On Wed, 2018-01-24 at 14:03 +0100, Julien Aubin wrote:
> I know it... :'( But as you rebuild the kernel image the updated compiler
> may come a bit later w/o needing another kernel update ?

I'm not really sure we will do a kernel binNMU in stretch-pu, but in any
case
that's a discussion for when we will actually have a fix.
>
> Anyway if you want someone to test the updates please push the updated
> packages to stretch-p-u and I'll tell you if it works on my four boxes
which
> are :
> - An Intel Core i7 4790 w/ NVidia blob 384.111
> - An AMD Phenom 9850 w/ NVidia blob 384.111
> - An Intel Core i7 4800MQ laptop
> - An Intel NUC Atom Apollo Lake

You'll be notified when the upload is done and this bug is closed, so you'll
be able to test at that point.

Regards,
--
Yves-Alexis


Okay so whatever you decide w/ security team (retpoline fixes only or full
4.9.77) I can test if it helps.

Bug#888263: Spectre : release kernel 4.9.77 to stretch before p-u

[Julien Aubin]

2018-01-24 13:52 GMT+01:00 Yves-Alexis Perez <cor...@debian.org>:

> On Wed, 2018-01-24 at 13:43 +0100, Julien Aubin wrote:
> > Package: linux-image-4.9.0-5-amd64
> > Version: 4.9.65-3+deb9u2
> > Severity: serious
> > Tags: security
> > Justification: root security hole
> >
> > Hi,
> >
> > Now that kernel release 4.9.77 has been released and contains the full
> > retpoline fixes, could you please bring it to stretch before the next
> p-u ?
>
> Hi,
>
> work on 4.9.77 is mostly done, so yes I'd like to push it to stretch before
> next point relase. 4.9.78 is just out but I'm unsure if we want to hold it
> or
> not.
> >
> > I know this situation is quite exceptionnal, but all the Spectre story
> is.
> > I'm not sure backporting only the required changes for retpoline would be
> > that easy.
>
> That beeing said, retpoline support in the kernel is not enough. It also
> needs
> gcc fixes, which are not yet available, as far as I can tell. So while we
> can
> push an updated kernel to stretch, spectre won't be mitigated.
>

I know it... :'( But as you rebuild the kernel image the updated compiler
may come a bit later w/o needing another kernel update ?

Anyway if you want someone to test the updates please push the updated
packages to stretch-p-u and I'll tell you if it works on my four boxes
which are :
- An Intel Core i7 4790 w/ NVidia blob 384.111
- An AMD Phenom 9850 w/ NVidia blob 384.111
- An Intel Core i7 4800MQ laptop
- An Intel NUC Atom Apollo Lake

Rgds,

>
> Regards,
> --
> Yves-Alexis

Bug#888263: Spectre : release kernel 4.9.77 to stretch before p-u

[Julien Aubin]

Package: linux-image-4.9.0-5-amd64
Version: 4.9.65-3+deb9u2
Severity: serious
Tags: security
Justification: root security hole

Hi,

Now that kernel release 4.9.77 has been released and contains the full
retpoline fixes, could you please bring it to stretch before the next p-u ?

I know this situation is quite exceptionnal, but all the Spectre story is.
I'm not sure backporting only the required changes for retpoline would be
that easy.

Thanks a lot,

Bug#875881: linux: CVE-2017-1000251

[Julien Aubin]

On Sat, 16 Sep 2017 16:40:24 +0200 Julien Aubin <julien.au...@gmail.com>
wrote:
> 2017-09-15 21:03 GMT+02:00 Christoph Anton Mitterer <cales...@scientia.net
>:
>
> > On Fri, 2017-09-15 at 19:18 +0100, Ben Hutchings wrote:
> > > Probably less critical than you think, since we enable
> > > CONFIG_CC_STACKPROTECTOR.
> >
> > Well... yes, but it wouldn't be the first time in history, that such
> > defence could then also be circumvented in the next evolution of an
> > exploit :-)
> >
> > But of course you can lower the bug severity if you think this is
> > appropriate.
> >
> > Cheers
>
>
> Looks like such issue has been found, stack clash is back :
> https://security-tracker.debian.org/tracker/CVE-2017-1000379

Could you please backport the fix to stable ?

Thanks !

Bug#875881: linux: CVE-2017-1000251

[Julien Aubin]

2017-09-15 21:03 GMT+02:00 Christoph Anton Mitterer :

> On Fri, 2017-09-15 at 19:18 +0100, Ben Hutchings wrote:
> > Probably less critical than you think, since we enable
> > CONFIG_CC_STACKPROTECTOR.
>
> Well... yes, but it wouldn't be the first time in history, that such
> defence could then also be circumvented in the next evolution of an
> exploit :-)
>
> But of course you can lower the bug severity if you think this is
> appropriate.
>
> Cheers


Looks like such issue has been found, stack clash is back :
https://security-tracker.debian.org/tracker/CVE-2017-1000379

Bug#875881: linux: CVE-2017-1000251

[Julien Aubin]

Still, it can lead to system crashes from a remote device.

See https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/BlueBorne

2017-09-15 20:18 GMT+02:00 Ben Hutchings :

> On Fri, 15 Sep 2017 16:31:13 +0200 Christoph Anton Mitterer
>  wrote:
> > Source: linux
> > Version: 4.12.12-2
> > Severity: critical
> > Tags: security
> > Justification: root security hole
> >
> >
> > Hi.
> >
> > Any chance to get CVE-2017-1000251, which seems to be quite critical
> fixed
> > anytime soon? :-)
> >
> > https://security-tracker.debian.org/tracker/CVE-2017-1000251
>
> Probably less critical than you think, since we enable
> CONFIG_CC_STACKPROTECTOR.
>
> Ben.
>
> --
> Ben Hutchings
> Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it in
> your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'
>
>

Bug#875881: linux: CVE-2017-1000251

[Julien Aubin]

On Fri, 15 Sep 2017 16:31:13 +0200 Christoph Anton Mitterer <
cales...@scientia.net> wrote:
> Source: linux
> Version: 4.12.12-2
> Severity: critical
> Tags: security
> Justification: root security hole
>
>
> Hi.
>
> Any chance to get CVE-2017-1000251, which seems to be quite critical fixed
> anytime soon? :-)
>
> https://security-tracker.debian.org/tracker/CVE-2017-1000251
>
> Thx,
> Chris
>
>

Hi,

Note that this bug also applies to stable, which is even more critical.

Bug#858122: Upgrade linux kernel to 4.9.15 in sid and stretch

[Julien Aubin]

Yup checked. These drivers are used for satellite communication devices.
Unsure many desktop and server users need them.

Le 18 mars 2017 23:01, "Ben Hutchings" <b...@decadent.org.uk> a écrit :

> On Sat, Mar 18, 2017 at 10:08:10PM +0100, Julien Aubin wrote:
> > OK I did this. Does it have a huge impact on the system except mitigating
> > the flaw ? (I don't think I have an HDLC hardware...)
>
> If you don't know whether you have it, you don't have it. :-)
>
> Ben.
>
> --
> Ben Hutchings
> Life is like a sewer:
> what you get out of it depends on what you put into it.
>

Bug#858122: Upgrade linux kernel to 4.9.15 in sid and stretch

[Julien Aubin]

OK I did this. Does it have a huge impact on the system except mitigating
the flaw ? (I don't think I have an HDLC hardware...)

2017-03-18 21:54 GMT+01:00 Ben Hutchings <b...@decadent.org.uk>:

> On Sat, 2017-03-18 at 17:01 +0100, Julien Aubin wrote:
> > Source: linux
> > Severity: critical
> > Tags: security
> > Justification: root security hole
> >
> > Hi,
> >
> > Security issue CVE-2017-2636 (severity 7.8) has been disclosed and the
> fix
> > has
> > been provided for Jessie and Wheezy. The problem is that there's as of
> now
> > no
> > fix available for sid and stretch while things become more and more
> critical
> > due to the severity of the issue.
> >
> > Kernel 4.9.15 contains a fix for this. Could you please integrate it
> ASAP on
> > Stretch ?
> [...]
>
> Note that we already documented a mitigation for this in the DSA.
>
> Ben.
>
> --
> Ben Hutchings
> Editing code like this is akin to sticking plasters on the bleeding
> stump
> of a severed limb. - me, 29 June 1999
>
>

Bug#858122: Upgrade linux kernel to 4.9.15 in sid and stretch

[Julien Aubin]

Source: linux
Severity: critical
Tags: security
Justification: root security hole

Hi,

Security issue CVE-2017-2636 (severity 7.8) has been disclosed and the fix
has
been provided for Jessie and Wheezy. The problem is that there's as of now
no
fix available for sid and stretch while things become more and more critical
due to the severity of the issue.

Kernel 4.9.15 contains a fix for this. Could you please integrate it ASAP on
Stretch ?

Thanks in advance.

More info at :
https://www.ptsecurity.com/ww-en/about/news/199636/



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#851702: linux-image-amd64: Important (and unacceptable) delay for providing updates for users of signed linux kernels

[Julien Aubin]

Package: linux-image-amd64
Version: 4.8+77~bpo8+1
Severity: critical
Tags: security
Justification: root security hole

Hi,

As of now two flavours of Linux kernels are released. The default ones are
signed ones while other unsigned kernels are available.

The problem is that there's a significant delay between the release of the
two
flavours, often more than one week, which exposes users of signed kernels to
critical vulnerabilities addressed in the newer kernel releases. The only
possible workaround is to switch on
-unsigned linux kernels, but this is messy and clearly unwanted.

I've raised an issue on BPO mailing list here : https://lists.debian.org
/debian-backports/2017/01/msg00033.html (the issue also applies to testing
and
unstable).

The answer is basically that :
1/ - unsigned kernels are only available for testing purposes
2/ - it is not possible to build simultaneously signed and unsigned kernels.

I'm okay with the latter as long as there's only a couple of hours between
the
two kernel releases. Now if we must wait more than one week to get the
signed
image it clearly reveals there's an issue in the signed image build process
which must be addressed before Stretch release.

Otherwise a possibility would be to use by default -unsigned image and
create
an optional linux-image-amd64-signed metapackage like the one which exists
for
grsec.



-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.8.0-0.bpo.2-amd64-unsigned [linux-image-4.8.
 4.8.15-2~bpo8+1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#851680: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#851680: Please provide linux-image-amd64-unsigned et al. metapackages (was Re: Please upload signed kernel images at the same time a

[Julien Aubin]

Hi Ben,

In that case you have to find a way to provide signed and unsigned images
simultaneously.

Otherwise to me it looks like a release blocker and I'll raise a ticket
about this.



2017-01-17 18:55 GMT+01:00 Thorsten Glaser <t.gla...@tarent.de>:

> Hello Ben,
>
> >No, there will be no such meta-packages.  The -unsigned packages are
> >only meant for developer testing and as build dependencies for signed
> >binary packages.
>
> then, would you please kindly explain how you plan to address the
> issue of not getting the security updates from newer kernel packages
> installed on Debian systems for a week or so?
>
>
> On Tue, 17 Jan 2017, Julien Aubin wrote:
>
> > Could you raise a ticket about this instead of the -unsigned metapackage?
> > (Actually a -signed metapackage would make much more sense)
>
> That’s precisely what I already did, which you might have noticed.
> And yes, that would make much more sense, because 90% or more of
> Debian users have absolutely zero need, nor any surplus value a̲t̲
> a̲l̲l̲, from the signed images.
>
>
> Thanks,
> //mirabilos
> --
> tarent solutions GmbH
> Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
> Tel: +49 228 54881-393 • Fax: +49 228 54881-235
> HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
> Steeg
>

Bug#851680: Please upload signed kernel images at the same time as unsigned ones

[Julien Aubin]

Could you raise a ticket about this instead of the -unsigned metapackage ?
(Actually a -signed metapackage would make much more sense)

2017-01-17 16:03 GMT+01:00 Thorsten Glaser <t.gla...@tarent.de>:

> On Tue, 17 Jan 2017, Julien Aubin wrote:
>
> > ... or even better : the unsigned image is the default image (ends with
> > -amd64) and the signed image (ends with -amd64-signed) provides the
> kernel
> > unsigned package
>
> That would be even better, yes.
>
> bye,
> //mirabilos
> --
> tarent solutions GmbH
> Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
> Tel: +49 228 54881-393 • Fax: +49 228 54881-235
> HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
> Steeg
>

Bug#828087: Bug #828087

[Julien Aubin]

 ahci(E) libahci(E) xhci_pci(E) xhci_hcd(E) r8169(E) mii(E)
libata(E) usbcore(E) usb_common(E) scsi_mod(E) sdhci_pci(E) i2c_hid(E)
hid(E) sdhci_acpi(E) sdhci(E) mmc_core(E) fjes(E)
[  144.829127] CPU: 0 PID: 43 Comm: kworker/0:1 Tainted: G U  E
4.6.0-0.bpo.1-amd64 #1 Debian 4.6.1-1~bpo8+1
[  144.829129] Hardware name:  /NUC5PPYB, BIOS
PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015
[  144.829164] Workqueue: events intel_mmio_flip_work_func [i915]
[  144.829167]  0286 89db3039 813123c5
880275e23d88
[  144.829171]   8107af94 88023bab7980
880275e23de0
[  144.829175]  88023b997900  e8c02200

[  144.829179] Call Trace:
[  144.829189]  [] ? dump_stack+0x5c/0x77
[  144.829194]  [] ? __warn+0xc4/0xe0
[  144.829197]  [] ? warn_slowpath_fmt+0x5f/0x80
[  144.829231]  [] ?
intel_mmio_flip_work_func+0x464/0x490 [i915]
[  144.829235]  [] ? process_one_work+0x14b/0x400
[  144.829239]  [] ? worker_thread+0x65/0x4a0
[  144.829242]  [] ? rescuer_thread+0x340/0x340
[  144.829246]  [] ? kthread+0xdf/0x100
[  144.829251]  [] ? ret_from_fork+0x22/0x40
[  144.829254]  [] ? kthread_park+0x50/0x50
[  144.829262] ---[ end trace 496474f31124a6b4 ]---
[  144.834113] drm/i915: Resetting chip after gpu hang

2016-06-27 8:50 GMT+02:00 Julien Aubin <julien.au...@gmail.com>:

> Hi
>
> I have tried again and found out that even with the kernel command line
> switch the bug still occurs.
>

Bug#828087: Bug #828087

[Julien Aubin]

  0286 89db3039 813123c5
880275e23d88
[  144.829171]   8107af94 88023bab7980
880275e23de0
[  144.829175]  88023b997900  e8c02200

[  144.829179] Call Trace:
[  144.829189]  [] ? dump_stack+0x5c/0x77
[  144.829194]  [] ? __warn+0xc4/0xe0
[  144.829197]  [] ? warn_slowpath_fmt+0x5f/0x80
[  144.829231]  [] ?
intel_mmio_flip_work_func+0x464/0x490 [i915]
[  144.829235]  [] ? process_one_work+0x14b/0x400
[  144.829239]  [] ? worker_thread+0x65/0x4a0
[  144.829242]  [] ? rescuer_thread+0x340/0x340
[  144.829246]  [] ? kthread+0xdf/0x100
[  144.829251]  [] ? ret_from_fork+0x22/0x40
[  144.829254]  [] ? kthread_park+0x50/0x50
[  144.829262] ---[ end trace 496474f31124a6b4 ]---
[  144.834113] drm/i915: Resetting chip after gpu hang

2016-06-27 8:50 GMT+02:00 Julien Aubin <julien.au...@gmail.com>:

> Hi
>
> I have tried again and found out that even with the kernel command line
> switch the bug still occurs.
>

Bug#828087: Bug #828087

[Julien Aubin]

Hi

I have tried again and found out that even with the kernel command line
switch the bug still occurs.

Bug#828087: Kernel 4.6 causes X session freezes with Intel NUCs

[Julien Aubin]

Package: linux-image-amd64
Version: 4.6+74~bpo8+1
Severity: important

Hi,

I have an Intel Nuc BOXNUC5PPYH Barebone PC and upgraded to kernel 4.6.
Since
then I've seen that within the X session I get many freezes, which did not
occur with kernel 4.5. Is there a regression around ?

To reproduce the issue :
DO : start KDM
DO : open a KDE session with graphic effects enabled (like transparency)
EXPECT : the session is usable
ACTUAL : the session freezes while the mouse is still operational

Note :
I can see the following message in the logs :
Jun 24 22:20:06 pccore2duo kernel: [  217.909567]
[drm:intel_check_cpu_fifo_underruns [i915]] *ERROR* pipe A underrun

The computer then becomes frozen under an X session but it can be reached
through SSH.

The issue did not appear with kernel 4.5.x

Workaround :
Add the following parameter to kernel command line :  i915.enable_fbc=0

Rgds

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.6.0-0.bpo.1-amd64  4.6.1-1~bpo8+1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information