[Kernel-packages] [Bug 1828906] Re: upgrade to Linux 4.15.0-48-generic crashes display on lenovo G500

2019-07-20 Thread Launchpad Bug Tracker
[Expired for linux (Ubuntu) because there has been no activity for 60
days.]

** Changed in: linux (Ubuntu)
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1828906

Title:
  upgrade to Linux 4.15.0-48-generic crashes display on lenovo G500

Status in linux package in Ubuntu:
  Expired

Bug description:
  Last week my Lenovo G500 laptop running ubuntu 18.04 reported an
  available system update of about 180 MBs, which included a kernel
  version update. I installed it and following the reboot, the display
  hung with a purple screen with bands of random colored pixels across
  the screen.

  If I reboot and hold down SHIFT to get to GRUB, it presents the
  following choices under Advanced Options:

Ubuntu, with Linux 4.15.0-48-generic
Ubuntu, with Linux 4.15.0-48-generic (recovery mode)
Ubuntu, with Linux 4.15.0-47-generic
Ubuntu, with Linux 4.15.0-47-generic (recovery mode)

  If I select 4.15.0-48-generic, I get the display hang problem
  described above or other forms of display misbehavior (sometimes it
  flashes continuously, sometimes it just hangs at a black screen, its
  not consistent).

  If I select 4.15.0-47-generic, it boots up just fine to a completely
  usable desktop. Every time.

  I've tried running boot-repair. It reported that it had repaired GRUB,
  but the problem persists. So I don't think its a boot parameters
  problem. I conclude that the problem has something to do with the
  display driver in 4.15.0-48-generic that was not present in
  4.15.0-47-generic.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: ubuntu-release-upgrader-core 1:18.04.31
  ProcVersionSignature: Ubuntu 4.15.0-47.50-generic 4.15.18
  Uname: Linux 4.15.0-47-generic i686
  NonfreeKernelModules: wl
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: i386
  CrashDB: ubuntu
  CurrentDesktop: ubuntu:GNOME
  Date: Mon May 13 18:11:02 2019
  InstallationDate: Installed on 2019-04-18 (25 days ago)
  InstallationMedia: Ubuntu 16.04.6 LTS "Xenial Xerus" - Release i386 
(20190227.1)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: ubuntu-release-upgrader
  Symptom: release-upgrade
  UpgradeStatus: No upgrade log present (probably fresh install)
  VarLogDistupgradeAptlog:
   Log time: 2019-05-13 16:34:52.461061
   Starting pkgProblemResolver with broken count: 0
   Starting 2 pkgProblemResolver with broken count: 0
   Done
   Log time: 2019-05-13 16:35:07.526926

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1828906/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1829915] Re: Radeon receives invalid EDID (all zeroes)

2019-07-20 Thread Launchpad Bug Tracker
[Expired for linux (Ubuntu) because there has been no activity for 60
days.]

** Changed in: linux (Ubuntu)
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829915

Title:
  Radeon receives invalid EDID (all zeroes)

Status in linux package in Ubuntu:
  Expired

Bug description:
   I installed ubuntu 18.04 than upgraded to 19.04 and everything was 
fine(resolution 1920x1080 on a samsung TV) for a few weeks than suddenly it 
dropped to 1024x768.
I'm running a AMD HD7670 video card with a display port to HDMI cable to 
the tv

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: xorg 1:7.7+19ubuntu12
  ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6
  Uname: Linux 5.0.0-15-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Tue May 21 21:25:49 2019
  DistUpgraded: 2019-05-20 01:35:47,157 ERROR got error from PostInstallScript 
./xorg_fix_proprietary.py (g-exec-error-quark: Failed to execute child process 
“./xorg_fix_proprietary.py” (No such file or directory) (8))
  DistroCodename: disco
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Caicos XT [Radeon HD 7470/8470 / R5 
235/310 OEM] [1002:6778] (prog-if 00 [VGA controller])
 Subsystem: Dell Radeon HD 7470 [1028:2120]
  InstallationDate: Installed on 2019-05-19 (1 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Dell Inc. OptiPlex 755
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-15-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UpgradeStatus: Upgraded to disco on 2019-05-19 (1 days ago)
  dmi.bios.date: 06/11/2012
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A22
  dmi.board.name: 0PU052
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 15
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA22:bd06/11/2012:svnDellInc.:pnOptiPlex755:pvr:rvnDellInc.:rn0PU052:rvr:cvnDellInc.:ct15:cvr:
  dmi.product.name: OptiPlex 755
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.98+git1905161830.922d92~oibaf~d
  version.libgl1-mesa-dri: libgl1-mesa-dri 19.2~git1905190730.4689e9~oibaf~d
  version.libgl1-mesa-glx: libgl1-mesa-glx 19.2~git1905190730.4689e9~oibaf~d
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.4-1ubuntu3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-0ubuntu1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20180925-2
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829915/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1836878] Re: linux-snapdragon: 4.4.0-1120.126 -proposed tracker

2019-07-20 Thread Ubuntu Kernel Bot
** Description changed:

  This bug will contain status and test results related to a kernel source
  (or snap) as stated in the title.
  
  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  
  derivatives: bug 1836877 (dragonboard-kernel)
  
  -- swm properties --
  boot-testing-requested: true
  kernel-stable-master-bug: 1836880
- phase: Testing
- phase-changed: Friday, 19. July 2019 13:30 UTC
+ phase: Ready for Testing
+ phase-changed: Saturday, 20. July 2019 21:45 UTC
  proposed-announcement-sent: true
  proposed-testing-requested: true
  reason:
-   certification-testing: Ongoing -- testing in progress
verification-testing: Ongoing -- testing in progress
  trackers:
xenial:linux-snapdragon:dragonboard-kernel: bug 1836877
  variant: debs

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-snapdragon in Ubuntu.
https://bugs.launchpad.net/bugs/1836878

Title:
  linux-snapdragon: 4.4.0-1120.126 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Fix Released
Status in Kernel SRU Workflow certification-testing series:
  Fix Released
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Invalid
Status in Kernel SRU Workflow security-signoff series:
  Fix Released
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux-snapdragon package in Ubuntu:
  Invalid
Status in linux-snapdragon source package in Xenial:
  Confirmed

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  derivatives: bug 1836877 (dragonboard-kernel)

  -- swm properties --
  boot-testing-requested: true
  kernel-stable-master-bug: 1836880
  phase: Ready for Testing
  phase-changed: Saturday, 20. July 2019 21:45 UTC
  proposed-announcement-sent: true
  proposed-testing-requested: true
  reason:
verification-testing: Ongoing -- testing in progress
  trackers:
xenial:linux-snapdragon:dragonboard-kernel: bug 1836877
  variant: debs

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1836878/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1836878] Re: linux-snapdragon: 4.4.0-1120.126 -proposed tracker

2019-07-20 Thread Taihsiang Ho
Hardware Certification have completed testing this -proposed kernel. No
regressions were observed, results are available here:
http://people.canonical.com/~hwcert/sru-
testing/snapdragon/4.4.0-1120.126/snapdragon-4.4-proposed-published.html

** Tags added: certification-testing-passed

** Changed in: kernel-sru-workflow/certification-testing
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-snapdragon in Ubuntu.
https://bugs.launchpad.net/bugs/1836878

Title:
  linux-snapdragon: 4.4.0-1120.126 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  Fix Released
Status in Kernel SRU Workflow certification-testing series:
  Fix Released
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  Invalid
Status in Kernel SRU Workflow security-signoff series:
  Fix Released
Status in Kernel SRU Workflow verification-testing series:
  Confirmed
Status in linux-snapdragon package in Ubuntu:
  Invalid
Status in linux-snapdragon source package in Xenial:
  Confirmed

Bug description:
  This bug will contain status and test results related to a kernel
  source (or snap) as stated in the title.

  For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow

  derivatives: bug 1836877 (dragonboard-kernel)

  -- swm properties --
  boot-testing-requested: true
  kernel-stable-master-bug: 1836880
  phase: Ready for Testing
  phase-changed: Saturday, 20. July 2019 21:45 UTC
  proposed-announcement-sent: true
  proposed-testing-requested: true
  reason:
verification-testing: Ongoing -- testing in progress
  trackers:
xenial:linux-snapdragon:dragonboard-kernel: bug 1836877
  variant: debs

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1836878/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1826730] Re: [ASUS X555YI] audio crackle when the sound a little loud.

2019-07-20 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: pulseaudio (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1826730

Title:
  [ASUS X555YI] audio crackle when the sound a little loud.

Status in linux package in Ubuntu:
  Incomplete
Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  both mpv and vlc have this problem, even when I use firefox see youtube 
video, if I turn the sound a little loud, the sound will with a lot of crackle 
sound.
  I ubuntu18.04 all the thing update to date.
  widon@widon-X555YI:~$ dpkg -l | grep pulseaudio
  ii  gstreamer1.0-pulseaudio:amd64 
1.14.1-1ubuntu1~ubuntu18.04.1amd64GStreamer plugin for 
PulseAudio
  ii  pulseaudio1:11.1-1ubuntu7.2   
 amd64PulseAudio sound server
  ii  pulseaudio-module-bluetooth   1:11.1-1ubuntu7.2   
 amd64Bluetooth module for PulseAudio sound server
  ii  pulseaudio-utils  1:11.1-1ubuntu7.2   
 amd64Command line tools for the PulseAudio sound server
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  widon  1517 F pulseaudio
   /dev/snd/controlC0:  widon  1517 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2018-11-24 (156 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Package: pulseaudio 1:11.1-1ubuntu7.2 [origin: unknown]
  PackageArchitecture: amd64
  ProcVersionSignature: Ubuntu 4.15.0-46.49-generic 4.15.18
  Tags: bionic third-party-packages
  Uname: Linux 4.15.0-46-generic x86_64
  UnreportableReason: 这不是官方的 Ubuntu 软件包。请删除所有第三方软件包,然后重试。
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 11/13/2015
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: X555YI.510
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: X555YI
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: ATN12345678901234567
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrX555YI.510:bd11/13/2015:svnASUSTeKCOMPUTERINC.:pnX555YI:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX555YI:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: X
  dmi.product.name: X555YI
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK COMPUTER INC.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1826730/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1828596] Re: kdump fails when crash is triggered after DLPAR cpu add operation

2019-07-20 Thread Thadeu Lima de Souza Cascardo
Disabling the ratelimit in general would break other failure modes, so I
would rather just reset-failed when calling try-restart because of the
hotplug events.

Can you try the package in ppa:cascardo/kdump2? Packages for eoan, disco
and bionic available.

Thanks.
Cascardo.

** Description changed:

  [Impact]
  After a CPU add/hotplug operation on Power systems, kdump will fail after a 
crash. The kdump kernel needs to be reloaded after a CPU add/hotplug.
  
  [Test case]
  Do CPU add/hotplug, trigger a crash, and check for a successful kdump.
  
  [Regression potential]
- Multiple reloads caused by multiple sequential CPU adds may cause spurious 
log results, and systemd may fail to properly reload the kdump kernel.
- 
+ Multiple reloads caused by multiple sequential CPU adds may cause spurious 
log results, and systemd may fail to properly reload the kdump kernel. This has 
been handled by resetting the failure counter when doing such reloads.
  
  == Comment: #0 - Hari Krishna Bathini - 2019-05-10 05:55:40 ==
  ---Problem Description---
  kdump fails when crash is triggered after CPU add operation.
  
  Machine Type = na
  
  ---System Hang---
   Crashed in early boot process of kdump kernel after crash
  
  Had to issue system reset from HMC to reclaim
  
  ---Steps to Reproduce---
   1. Configure kdump.
  2. Add cpu from HMC.
  3. Trigger crash.
  4. Machine hangs after crash as below:
  
  ---
  [169250.213166] IPI complete
  [169250.234331] kexec: Starting switchover sequence.
  I'm in purgatory
   --- STRUCK HERE ---
  
  ---uname output---
  na
  
  ---Debugger---
  A debugger is not configured
  
  == Comment: #1 - Hari Krishna Bathini  - 2019-05-10 05:56:46 ==
  The problem is, kexec udev rule to restart kdump-tools service - when a core 
is added,
  is not being triggered. The old DT created by kexec (before the core is added)
  is being used by KDump Kernel. So, when system crashes on a thread from
  the added core(s), KDump kernel is failing to get the 'boot_cpuid' and
  eventually failing to boot..
  
  == Comment: #2 - Hari Krishna Bathini - 2019-05-10 06:02:27 ==
  The udev rule when CPU is added is not triggered because ppc64 does not
  eject add/remove event when a CPU is hot added/removed. It only ejects
  online/offline event to user space when CPU is hot added/removed.
  
  So, the below udev rules are never triggered when needed:
  
  SUBSYSTEM=="cpu", ACTION=="add", PROGRAM="/bin/systemctl try-restart 
kdump-tools.service"
  SUBSYSTEM=="cpu", ACTION=="remove", PROGRAM="/bin/systemctl try-restart 
kdump-tools.service"
  
  Also, with how CPU hot add & remove are handled in ppc64, a udev trigger
  to reload kdump after CPU is hot removed is NOT necessary. So, fix the CPU
  hot add case by updating the udev rule and drop the udev rule meant for CPU
  hot remove in the kdump udev rules file:
  
  SUBSYSTEM=="cpu", ACTION=="online", PROGRAM="/bin/systemctl try-restart
  kdump-tools.service"

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1828596

Title:
  kdump fails when crash is triggered after DLPAR cpu add operation

Status in The Ubuntu-power-systems project:
  Incomplete
Status in kexec-tools package in Ubuntu:
  Invalid
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  New
Status in makedumpfile source package in Xenial:
  New
Status in kexec-tools source package in Bionic:
  New
Status in makedumpfile source package in Bionic:
  New
Status in kexec-tools source package in Cosmic:
  New
Status in makedumpfile source package in Cosmic:
  New
Status in kexec-tools source package in Disco:
  New
Status in makedumpfile source package in Disco:
  New
Status in kexec-tools source package in Eoan:
  Invalid
Status in makedumpfile source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  After a CPU add/hotplug operation on Power systems, kdump will fail after a 
crash. The kdump kernel needs to be reloaded after a CPU add/hotplug.

  [Test case]
  Do CPU add/hotplug, trigger a crash, and check for a successful kdump.

  [Regression potential]
  Multiple reloads caused by multiple sequential CPU adds may cause spurious 
log results, and systemd may fail to properly reload the kdump kernel. This has 
been handled by resetting the failure counter when doing such reloads.

  == Comment: #0 - Hari Krishna Bathini - 2019-05-10 05:55:40 ==
  ---Problem Description---
  kdump fails when crash is triggered after CPU add operation.

  Machine Type = na

  ---System Hang---
   Crashed in early boot process of kdump kernel after crash

  Had to issue system reset from HMC to reclaim

  ---Steps to Reproduce---
   1. Configure kdump.
  2. Add cpu from HMC.
  3. Trigger crash.
  4. Machine hangs after crash as below:

  ---
  [169250.213166] IPI complete
  [169250.234331] kexec: Starting 

[Kernel-packages] [Bug 1828597] Re: KDump boot fails with nr_cpus=1

2019-07-20 Thread Thadeu Lima de Souza Cascardo
** Description changed:

  [Impact]
  The kdump kernel will crash during its boot if booted on a CPU other than 0.
  
  [Test case]
  Trigger a crash using taskset -c X, where X is not 0 and is a present CPU. 
Check that the dump is successful.
  
+ echo c | sudo taskset -c 1 tee /proc/sysrq-trigger
+ 
  [Regression potential]
  This will cause more memory to be used by the dump kernel, which may cause 
OOMs during the dump. The fix is restricted to ppc64el.
- 
  
  == Comment: #0 - Hari Krishna Bathini  - 2019-05-10 06:38:21 ==
  
  ---Problem Description---
  kdump boots fails in some environments when nr_cpus=1 is passed
  
  ---uname output---
  na
  
  Machine Type = na
  
  ---Debugger---
  A debugger is not configured
  
  ---Steps to Reproduce---
   1. configure kdump
  2. trigger crash on non-boot cpu
  
  Expected result:
  Capture dump and reboot
  
  Actual result:
  Hang in early kdump boot process after crash
  
  Userspace tool common name: kdump-tools
  
  The userspace tool has the following bit modes: 64-bit
  
  Userspace rpm: kdump-tools
  
  Userspace tool obtained from project website:  na
  
  == Comment: #1 - Hari Krishna Bathini - 2019-05-10 06:45:46 ==
  Launchpad bug 1560552 added "nr_cpus=1" support on ppc64 though
  this change never made it upstream as maintainer has a few apprehensions..
  
  With 4.18 kernels, this change is dropped on Ubuntu kernels too.
  With nr_cpus=1 support in kernel, kdump-tools was also updated to
  use "nr_cpsu=1" by default instead of "maxcpus=1" (see launchpad
  bug 1568952). This kdump-tools change has to be reverted to make
  it consist with the kernel change. Note that "nr_cpus=1 change had
  a issues in kdump guest environment even with "nr_cpus=1" support
  for kdump in kernel. So, even not withstanding the kernel revert, it is
  better to default to "maxcpus=1" on all kernel versions. So, please
  revert the kdump-tools fix that went in with launchpad bug 1568952

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1828597

Title:
  KDump boot fails with nr_cpus=1

Status in The Ubuntu-power-systems project:
  Confirmed
Status in kexec-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Cosmic:
  Invalid
Status in linux source package in Cosmic:
  Confirmed
Status in makedumpfile source package in Cosmic:
  New
Status in kexec-tools source package in Disco:
  Invalid
Status in linux source package in Disco:
  Confirmed
Status in makedumpfile source package in Disco:
  New
Status in kexec-tools source package in Eoan:
  Invalid
Status in linux source package in Eoan:
  Confirmed
Status in makedumpfile source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  The kdump kernel will crash during its boot if booted on a CPU other than 0.

  [Test case]
  Trigger a crash using taskset -c X, where X is not 0 and is a present CPU. 
Check that the dump is successful.

  echo c | sudo taskset -c 1 tee /proc/sysrq-trigger

  [Regression potential]
  This will cause more memory to be used by the dump kernel, which may cause 
OOMs during the dump. The fix is restricted to ppc64el.

  == Comment: #0 - Hari Krishna Bathini  - 2019-05-10 06:38:21 ==

  ---Problem Description---
  kdump boots fails in some environments when nr_cpus=1 is passed

  ---uname output---
  na

  Machine Type = na

  ---Debugger---
  A debugger is not configured

  ---Steps to Reproduce---
   1. configure kdump
  2. trigger crash on non-boot cpu

  Expected result:
  Capture dump and reboot

  Actual result:
  Hang in early kdump boot process after crash

  Userspace tool common name: kdump-tools

  The userspace tool has the following bit modes: 64-bit

  Userspace rpm: kdump-tools

  Userspace tool obtained from project website:  na

  == Comment: #1 - Hari Krishna Bathini - 2019-05-10 06:45:46 ==
  Launchpad bug 1560552 added "nr_cpus=1" support on ppc64 though
  this change never made it upstream as maintainer has a few apprehensions..

  With 4.18 kernels, this change is dropped on Ubuntu kernels too.
  With nr_cpus=1 support in kernel, kdump-tools was also updated to
  use "nr_cpsu=1" by default instead of "maxcpus=1" (see launchpad
  bug 1568952). This kdump-tools change has to be reverted to make
  it consist with the kernel change. Note that "nr_cpus=1 change had
  a issues in kdump guest environment even with "nr_cpus=1" support
  for kdump in kernel. So, even not withstanding the kernel revert, it is
  better to default to "maxcpus=1" on all kernel versions. So, please
  revert the kdump-tools fix that went in with launchpad bug 1568952

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1828597/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to 

[Kernel-packages] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-07-20 Thread Thadeu Lima de Souza Cascardo
** Patch added: "SRU for disco"
   
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+attachment/5278173/+files/makedumpfile_1.6.5-1ubuntu1.1_disco.debdiff

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  In Progress
Status in makedumpfile source package in Xenial:
  In Progress
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  In Progress
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  In Progress

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-07-20 Thread Thadeu Lima de Souza Cascardo
Fix for eoan at my ppa. ppa:cascardo/kdump2.

Attaching SRU for disco and bionic.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  In Progress
Status in makedumpfile source package in Xenial:
  In Progress
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  In Progress
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  In Progress

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-07-20 Thread Thadeu Lima de Souza Cascardo
** Patch added: "SRU for bionic"
   
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+attachment/5278174/+files/makedumpfile_1.6.5-1ubuntu1~18.04.2_bionic.debdiff

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  In Progress
Status in makedumpfile source package in Xenial:
  In Progress
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  In Progress
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  In Progress

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1830961] Re: Kernels & kernel drivers fail to build with gcc-9 [error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible]

2019-07-20 Thread Doug Smythies
Several posters are asking for the mainline builds to be fixed. The
mainline builds are an exact reflection of the upstream git master
repositories. Therefore they have to wait for Seth's patch submission,
which has been picked up and accepted by the kbuild team, to propagate
it's way to the mainline upstream git branch. Earlier today, a kernel
5.3-rc1 merge request was issued by the kbuild team [1]. Once that
branch has been "pulled" into the upstream mainline, the Ubuntu mainline
daily compiles should start working the next day. In about 8 days there
will be kernel 5.3-rc1, which should have the patch.

[1] https://www.spinics.net/lists/linux-kbuild/msg22526.html

Other references:

https://kernel.ubuntu.com/~kernel-ppa/mainline/daily/
https://www.spinics.net/lists/linux-kbuild/msg22298.html
https://patchwork.kernel.org/patch/11037379/

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1830961

Title:
  Kernels & kernel drivers fail to build with gcc-9 [error: ‘-mindirect-
  branch’ and ‘-fcf-protection’ are not compatible]

Status in gcc-9 package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in nvidia-graphics-drivers-430 package in Ubuntu:
  Fix Released
Status in virtualbox package in Ubuntu:
  Won't Fix
Status in xtables-addons package in Ubuntu:
  Won't Fix

Bug description:
  Compiling kernels & kernel modules fails due to these errors:

  ./include/linux/compiler.h:193:1: error: ‘-mindirect-branch’ and
  ‘-fcf-protection’ are not compatible

  (This happens with any kernel modules.)

  This appears to be due to the changes in 9.1.0-3ubuntu1 enabling -fcf-
  protection by default on 19.10's gcc-9.

  Switching to gcc-8 allows compilation to proceed.

  WORKAROUND:

  sudo ln -fs gcc-8 /usr/bin/gcc

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1830961/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1798921] Re: sky2 ethernet card don't work after returning from suspension

2019-07-20 Thread kris
4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64
x86_64 x86_64 GNU/Linux

with me nothing has changed the error remained
I returned to:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=nomsi,noaer"

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1798921

Title:
  sky2 ethernet card don't work after returning from suspension

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released

Bug description:
  [SRU justification]

  == Impact ==
  Ethernet connection using a SKY2 card stops working after suspend.

  == Fix ==
  A fix for this landed in v5.0 upstream and was picked up in Xenial via 
upstream stable but not yet in Bionic and Cosmic. The change simply increases a 
timeout.

  == Testcase ==
  Suspend/resume with affected hardware present.

  == Risk of Regression ==
  Very low as only changing a timeout value in a specific hardware driver.

  ---

  Bug very similar to #1752772
  (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772) but
  affecting the sky2 driver instead of r8169.

  After system suspend the ethernet connection stops working. The card
  is still up and the modem can see it is connected, but the card
  doesn't get an ip address. Ifconfig down/up and restarting network-
  manager does not solve the issue. Similarly to the other bug, "sudo
  modprobe sky2 -r" an then "sudo modprobe sky2" solves the issue.

  Relevant: 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772/comments/107
  

  Linux 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018
  x86_64 x86_64 x86_64 GNU/Linux

    *-network
     description: Ethernet interface
     product: 88E8040 PCI-E Fast Ethernet Controller
     vendor: Marvell Technology Group Ltd.
     physical id: 0
     bus info: pci@:09:00.0
     logical name: enp9s0
     version: 13
     serial:
     size: 100Mbit/s
     capacity: 100Mbit/s
     width: 64 bits
     clock: 33MHz
     capabilities: pm msi pciexpress bus_master cap_list ethernet physical 
tp 10bt 10bt-fd 100bt 100bt-fd autonegotiation
     configuration: autonegotiation=on broadcast=yes driver=sky2 
driverversion=1.30 duplex=full latency=0 link=yes multicast=yes port=twisted 
pair speed=100Mbit/s
     resources: irq:24 memory:f68fc000-f68f ioport:de00(size=256)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1837073] Re: linux 5.2.0-8.9 disabled backlight on s390x.

2019-07-20 Thread Seth Forshee
We need a fix to the dkms test script. When the build is skipped due to
the BUILD_EXCLUSIVE directive the tar command fails, causing the script
to fail since it contains "set -eu". I'd suggest we do something like
the attached.

** Patch added: "dkms_2.7.1-1ubuntu2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837073/+attachment/5278140/+files/dkms_2.7.1-1ubuntu2.debdiff

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1837073

Title:
  linux 5.2.0-8.9 disabled backlight on s390x.

Status in ddcci-driver-linux package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Looks like ddcci-driver-linux started to fail on s390x with the switch
  from kernel 5.0.0-21-generic to 5.2.0-8-generic

  http://autopkgtest.ubuntu.com/packages/d/ddcci-driver-linux/eoan/s390x


  According to changelog and diff:
  - [Config] CONFIG_BACKLIGHT_CLASS_DEVICE=n on s390x

  from Seth Forshee.

  According to the build log of ddci backlight

  rm: cannot remove '.tmp_versions/ddcci-backlight.mod': No such file or 
directory
  Makefile:227: = WARNING 
  Makefile:228: 'SUBDIRS' will be removed after Linux 5.3
  Makefile:229: Please use 'M=' or 'KBUILD_EXTMOD' instead
  Makefile:230: ==
  Makefile:227: = WARNING 
  Makefile:228: 'SUBDIRS' will be removed after Linux 5.3
  Makefile:229: Please use 'M=' or 'KBUILD_EXTMOD' instead
  Makefile:230: ==
  ERROR: "devm_backlight_device_register" 
[/var/lib/dkms/ddcci/0.3.2/build/ddcci-backlight/ddcci-backlight.ko] undefined!
  make[3]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
  make[2]: *** [Makefile:1628: modules] Error 2
  make[1]: *** [Makefile:37: ddcci-backlight.ko] Error 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ddcci-driver-linux/+bug/1837073/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1830961] Re: Kernels & kernel drivers fail to build with gcc-9 [error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible]

2019-07-20 Thread oscarbg
maybe Seth Forshee  is the guy to ask

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1830961

Title:
  Kernels & kernel drivers fail to build with gcc-9 [error: ‘-mindirect-
  branch’ and ‘-fcf-protection’ are not compatible]

Status in gcc-9 package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in nvidia-graphics-drivers-430 package in Ubuntu:
  Fix Released
Status in virtualbox package in Ubuntu:
  Won't Fix
Status in xtables-addons package in Ubuntu:
  Won't Fix

Bug description:
  Compiling kernels & kernel modules fails due to these errors:

  ./include/linux/compiler.h:193:1: error: ‘-mindirect-branch’ and
  ‘-fcf-protection’ are not compatible

  (This happens with any kernel modules.)

  This appears to be due to the changes in 9.1.0-3ubuntu1 enabling -fcf-
  protection by default on 19.10's gcc-9.

  Switching to gcc-8 allows compilation to proceed.

  WORKAROUND:

  sudo ln -fs gcc-8 /usr/bin/gcc

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1830961/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1830961] Re: Kernels & kernel drivers fail to build with gcc-9 [error: ‘-mindirect-branch’ and ‘-fcf-protection’ are not compatible]

2019-07-20 Thread oscarbg
+1 for fixing mainline kernel builds.. been broken for almost two weeks!

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1830961

Title:
  Kernels & kernel drivers fail to build with gcc-9 [error: ‘-mindirect-
  branch’ and ‘-fcf-protection’ are not compatible]

Status in gcc-9 package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in nvidia-graphics-drivers-430 package in Ubuntu:
  Fix Released
Status in virtualbox package in Ubuntu:
  Won't Fix
Status in xtables-addons package in Ubuntu:
  Won't Fix

Bug description:
  Compiling kernels & kernel modules fails due to these errors:

  ./include/linux/compiler.h:193:1: error: ‘-mindirect-branch’ and
  ‘-fcf-protection’ are not compatible

  (This happens with any kernel modules.)

  This appears to be due to the changes in 9.1.0-3ubuntu1 enabling -fcf-
  protection by default on 19.10's gcc-9.

  Switching to gcc-8 allows compilation to proceed.

  WORKAROUND:

  sudo ln -fs gcc-8 /usr/bin/gcc

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1830961/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1837073] Re: linux 5.2.0-8.9 disabled backlight on s390x.

2019-07-20 Thread Gianfranco Costamagna
@Paolo Pisati, the fix didn't work...

** Changed in: ddcci-driver-linux (Ubuntu)
   Status: Confirmed => New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1837073

Title:
  linux 5.2.0-8.9 disabled backlight on s390x.

Status in ddcci-driver-linux package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Looks like ddcci-driver-linux started to fail on s390x with the switch
  from kernel 5.0.0-21-generic to 5.2.0-8-generic

  http://autopkgtest.ubuntu.com/packages/d/ddcci-driver-linux/eoan/s390x


  According to changelog and diff:
  - [Config] CONFIG_BACKLIGHT_CLASS_DEVICE=n on s390x

  from Seth Forshee.

  According to the build log of ddci backlight

  rm: cannot remove '.tmp_versions/ddcci-backlight.mod': No such file or 
directory
  Makefile:227: = WARNING 
  Makefile:228: 'SUBDIRS' will be removed after Linux 5.3
  Makefile:229: Please use 'M=' or 'KBUILD_EXTMOD' instead
  Makefile:230: ==
  Makefile:227: = WARNING 
  Makefile:228: 'SUBDIRS' will be removed after Linux 5.3
  Makefile:229: Please use 'M=' or 'KBUILD_EXTMOD' instead
  Makefile:230: ==
  ERROR: "devm_backlight_device_register" 
[/var/lib/dkms/ddcci/0.3.2/build/ddcci-backlight/ddcci-backlight.ko] undefined!
  make[3]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
  make[2]: *** [Makefile:1628: modules] Error 2
  make[1]: *** [Makefile:37: ddcci-backlight.ko] Error 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ddcci-driver-linux/+bug/1837073/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1818974] Re: Ubuntu 18.04 Kernel 4.18 - Standby wakeup user session crash

2019-07-20 Thread Martin Dünkelmann
Done.

I think I can reproduce it, if I hibernate in the Kodi application shutdown 
menu.
>From https://kodi.tv/
Using 18.3

** Attachment added: "BEFORE_AFTER_SUSPENDs.txt"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818974/+attachment/5278134/+files/BEFORE_AFTER_SUSPENDs.txt

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1818974

Title:
  Ubuntu 18.04 Kernel 4.18 - Standby wakeup user session crash

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I'm using Ubuntu 18.04 (Linux Mint 19.1 Tessa) with HWE.
  Since kernel 4.18 sometimes while waking up from standby my user session 
crash.
  I assume that my attached external USB to SATA HDD could be cause this kernel 
bug.
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  martin27966 F pulseaudio
  CurrentDesktop: X-Cinnamon
  DistroRelease: Linux Mint 19.1
  HibernationDevice: RESUME=UUID=4a747812-cab0-438b-ace1-a46b73f00d4a
  InstallationDate: Installed on 2018-07-21 (228 days ago)
  InstallationMedia: Linux Mint 19 "Tara" - Release amd64 20180626
  MachineType: LENOVO 20FXS05500
  NonfreeKernelModules: nvidia_modeset nvidia
  Package: linux (not installed)
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-16-generic 
root=UUID=8ffc268d-6911-42c4-9bc3-a290376cb41b ro quiet splash 
nvidia-drm.modeset=1 nopti spectre_v2=off spectre_v2_user=off nospec noibrs 
noibpb l1tf=off vt.handoff=1
  ProcVersionSignature: Ubuntu 4.18.0-16.17~18.04.1-generic 4.18.20
  RelatedPackageVersions:
   linux-restricted-modules-4.18.0-16-generic N/A
   linux-backports-modules-4.18.0-16-generic  N/A
   linux-firmware 1.173.3
  Tags:  tessa
  Uname: Linux 4.18.0-16-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom davfs2 dip lpadmin plugdev sambashare scanner sudo
  _MarkForUpload: True
  dmi.bios.date: 09/27/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: R07ET87W (2.27 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20FXS05500
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.modalias: 
dmi:bvnLENOVO:bvrR07ET87W(2.27):bd09/27/2018:svnLENOVO:pn20FXS05500:pvrThinkPadT460p:rvnLENOVO:rn20FXS05500:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
  dmi.product.family: ThinkPad T460p
  dmi.product.name: 20FXS05500
  dmi.product.sku: LENOVO_MT_20FX_BU_Think_FM_ThinkPad T460p
  dmi.product.version: ThinkPad T460p
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818974/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1773024] Re: Errors at boot

2019-07-20 Thread olivierm38
I have the same issue on my AMD PC after upgrading to 18.04. Before
there was no such message. It doesn't look harmful any way (Ubuntu seems
to work just fine for months now), just troubling.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1773024

Title:
  Errors at boot

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  LOGS DMESG:

  [0.048089] ACPI: Added _OSI(Module Device)
  [0.048090] ACPI: Added _OSI(Processor Device)
  [0.048091] ACPI: Added _OSI(3.0 _SCP Extensions)
  [0.048091] ACPI: Added _OSI(Processor Aggregator Device)
  [0.049587] ACPI Exception: Could not find/resolve named package element: 
LNKC (20170831/dspkginit-381)
  [0.049598] ACPI Exception: Could not find/resolve named package element: 
LNKD (20170831/dspkginit-381)
  [0.049607] ACPI Exception: Could not find/resolve named package element: 
LNKA (20170831/dspkginit-381)
  [0.049615] ACPI Exception: Could not find/resolve named package element: 
LNKB (20170831/dspkginit-381)
  [0.049676] ACPI Exception: Could not find/resolve named package element: 
LNKD (20170831/dspkginit-381)
  [0.049684] ACPI Exception: Could not find/resolve named package element: 
LNKA (20170831/dspkginit-381)
  [0.049692] ACPI Exception: Could not find/resolve named package element: 
LNKB (20170831/dspkginit-381)
  [0.049700] ACPI Exception: Could not find/resolve named package element: 
LNKC (20170831/dspkginit-381)
  [0.049760] ACPI Exception: Could not find/resolve named package element: 
LNKA (20170831/dspkginit-381)
  [0.049768] ACPI Exception: Could not find/resolve named package element: 
LNKB (20170831/dspkginit-381)
  [0.049776] ACPI Exception: Could not find/resolve named package element: 
LNKC (20170831/dspkginit-381)
  [0.049783] ACPI Exception: Could not find/resolve named package element: 
LNKD (20170831/dspkginit-381)
  [0.049843] ACPI Exception: Could not find/resolve named package element: 
LNKB (20170831/dspkginit-381)
  [0.049851] ACPI Exception: Could not find/resolve named package element: 
LNKC (20170831/dspkginit-381)
  [0.049859] ACPI Exception: Could not find/resolve named package element: 
LNKD (20170831/dspkginit-381)
  [0.049867] ACPI Exception: Could not find/resolve named package element: 
LNKA (20170831/dspkginit-381)
  [0.049925] ACPI Exception: Could not find/resolve named package element: 
LNKC (20170831/dspkginit-381)
  [0.049933] ACPI Exception: Could not find/resolve named package element: 
LNKD (20170831/dspkginit-381)
  [0.049941] ACPI Exception: Could not find/resolve named package element: 
LNKA (20170831/dspkginit-381)
  [0.049948] ACPI Exception: Could not find/resolve named package element: 
LNKB (20170831/dspkginit-381)
  [0.050008] ACPI Exception: Could not find/resolve named package element: 
LNKD (20170831/dspkginit-381)
  [0.050016] ACPI Exception: Could not find/resolve named package element: 
LNKA (20170831/dspkginit-381)
  [0.050024] ACPI Exception: Could not find/resolve named package element: 
LNKB (20170831/dspkginit-381)
  [0.050032] ACPI Exception: Could not find/resolve named package element: 
LNKC (20170831/dspkginit-381)
  [0.050091] ACPI Exception: Could not find/resolve named package element: 
LNKB (20170831/dspkginit-381)
  [0.050099] ACPI Exception: Could not find/resolve named package element: 
LNKC (20170831/dspkginit-381)
  [0.050107] ACPI Exception: Could not find/resolve named package element: 
LNKD (20170831/dspkginit-381)
  [0.050115] ACPI Exception: Could not find/resolve named package element: 
LNKA (20170831/dspkginit-381)
  [0.050173] ACPI Exception: Could not find/resolve named package element: 
LNKC (20170831/dspkginit-381)
  [0.050181] ACPI Exception: Could not find/resolve named package element: 
LNKD (20170831/dspkginit-381)
  [0.050190] ACPI Exception: Could not find/resolve named package element: 
LNKA (20170831/dspkginit-381)
  [0.050198] ACPI Exception: Could not find/resolve named package element: 
LNKB (20170831/dspkginit-381)
  [0.050258] ACPI Exception: Could not find/resolve named package element: 
LNKD (20170831/dspkginit-381)
  [0.050267] ACPI Exception: Could not find/resolve named package element: 
LNKA (20170831/dspkginit-381)
  [0.050274] ACPI Exception: Could not find/resolve named package element: 
LNKB (20170831/dspkginit-381)
  [0.050282] ACPI Exception: Could not find/resolve named package element: 
LNKC (20170831/dspkginit-381)
  [0.050342] ACPI Exception: Could not find/resolve named package element: 
LNKA (20170831/dspkginit-381)
  [0.050350] ACPI Exception: Could not find/resolve named package element: 
LNKB (20170831/dspkginit-381)
  [0.050357] ACPI Exception: Could not find/resolve named package element: 
LNKC (20170831/dspkginit-381)
  [0.050365] ACPI 

[Kernel-packages] [Bug 1814925] Re: [XPS 9370 / Qualcomm QCA6174] Bluetooth mouse stops responding after extended deep sleep

2019-07-20 Thread Alex Stanev
I can confirm this happens also with 19.04
DMI: Dell Inc. XPS 13 9370/0F6P3V, BIOS 1.10.0 04/18/2019
Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter 
(rev 32)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-firmware in Ubuntu.
https://bugs.launchpad.net/bugs/1814925

Title:
  [XPS 9370 / Qualcomm QCA6174] Bluetooth mouse stops responding after
  extended deep sleep

Status in linux-firmware package in Ubuntu:
  Confirmed

Bug description:
  Tested on Dell XPS 9370, Ubuntu 18.04 Dell OEM iso

  Bluetooth mouse tested with HP X4b BT Last mouse stops responding
  after long extended deep sleep (24-48 hours).

  Bluetooth settings window which  initially reported Bluetooth as
  connected now shows disconnected.  Pushing the button within the
  settings window to reconnect takes me back to off.  Switching back to
  on and off keeps bringing me back to off unless I reboot the device
  and or turn off the mouse via the underneath portion of the BT device.

  Demsg logs shows an extremely large number of "Bluetooth: hci:0 last
  event is not cmd complete (0x0f)"

  Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  Package: bluez 5.48-0ubuntu3.1
  XPS 13 9370 bios 1.6.3

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: bluez 5.48-0ubuntu3.1
  ProcVersionSignature: Ubuntu 4.15.0-45.48-generic 4.15.18
  Uname: Linux 4.15.0-45-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  Date: Wed Feb  6 10:16:07 2019
  InstallationDate: Installed on 2019-01-03 (33 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  InterestingModules: rfcomm bnep btusb bluetooth
  MachineType: Dell Inc. XPS 13 9370
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic 
root=UUID=9a57d978-48d7-4ef3-9f67-5e6b72107fcf ro mem_sleep_default=deep 
initrdefi /acpi_override quiet splash vt.handoff=1
  SourcePackage: bluez
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/04/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.6.3
  dmi.board.name: 0H0VG3
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.6.3:bd11/04/2018:svnDellInc.:pnXPS139370:pvr:rvnDellInc.:rn0H0VG3:rvrA00:cvnDellInc.:ct10:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9370
  dmi.sys.vendor: Dell Inc.
  hciconfig:
   hci0:Type: Primary  Bus: USB
    BD Address: 9C:B6:D0:90:A0:16  ACL MTU: 1024:8  SCO MTU: 50:8
    UP RUNNING PSCAN ISCAN
    RX bytes:748157 acl:263 sco:0 events:22281 errors:0
    TX bytes:15577 acl:124 sco:0 commands:1167 errors:0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1814925/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp