date:20210318

** Description changed:

  [Impact]
  While debugging bug 1910277, I found that the test compilation will print 
some warnings:
    memfd_test.c:64:7: warning: implicit declaration of function ‘open’;
    memfd_test.c:90:6: warning: implicit declaration of function ‘fcntl’
    memfd_test.c:397:6: warning: implicit declaration of function ‘fallocate’;
    fuse_test.c:67:6: warning: implicit declaration of function ‘fcntl’
    fuse_test.c:261:7: warning: implicit declaration of function ‘open’;
  
  And there is a fix in upstream for this.
  
  [Fix]
  * 1c49e3783f8899 ("selftests/memfd: Fix implicit declaration warnings")
  
- This fix can be cherry-picked into F/G and compiled without any issue.
+ This fix can be cherry-picked into F/G and compiled without any problem.
+ Older kernel does not have this issue.
  
  [Test Case]
  Build the memfd test in kselftests with:
    sudo make TARGETS=memfd
  
  With this fix, these warnings will be gone.
  
  [Where problems could occur]
  This fix is just for fixing the test case compilation, so it's not affecting 
real kernel functionality. If we need to fix it on older release X/B, this 
patch will cause compilation errors as they're missing some other vital 
commits, since we're not running this test on older releases I think it's fine 
to ignore them for now.

** Description changed:

  [Impact]
  While debugging bug 1910277, I found that the test compilation will print 
some warnings:
    memfd_test.c:64:7: warning: implicit declaration of function ‘open’;
    memfd_test.c:90:6: warning: implicit declaration of function ‘fcntl’
    memfd_test.c:397:6: warning: implicit declaration of function ‘fallocate’;
    fuse_test.c:67:6: warning: implicit declaration of function ‘fcntl’
    fuse_test.c:261:7: warning: implicit declaration of function ‘open’;
  
  And there is a fix in upstream for this.
  
  [Fix]
  * 1c49e3783f8899 ("selftests/memfd: Fix implicit declaration warnings")
  
  This fix can be cherry-picked into F/G and compiled without any problem.
  Older kernel does not have this issue.
  
  [Test Case]
  Build the memfd test in kselftests with:
    sudo make TARGETS=memfd
  
  With this fix, these warnings will be gone.
  
  [Where problems could occur]
- This fix is just for fixing the test case compilation, so it's not affecting 
real kernel functionality. If we need to fix it on older release X/B, this 
patch will cause compilation errors as they're missing some other vital 
commits, since we're not running this test on older releases I think it's fine 
to ignore them for now.
+ This fix is just for fixing the test case compilation, so it's not affecting 
real kernel functionality. If we need to fix it on older release X/B, this 
patch will cause compilation errors as they're missing some other vital 
commits, I think it's fine to ignore them for now.

-- 
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/1910323

Title:
  Fix implicit declaration warnings for kselftests/memfd test on newer
  releases

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  New
Status in linux source package in Groovy:
  New
Status in linux source package in Hirsute:
  Fix Released

Bug description:
  [Impact]
  While debugging bug 1910277, I found that the test compilation will print 
some warnings:
    memfd_test.c:64:7: warning: implicit declaration of function ‘open’;
    memfd_test.c:90:6: warning: implicit declaration of function ‘fcntl’
    memfd_test.c:397:6: warning: implicit declaration of function ‘fallocate’;
    fuse_test.c:67:6: warning: implicit declaration of function ‘fcntl’
    fuse_test.c:261:7: warning: implicit declaration of function ‘open’;

  And there is a fix in upstream for this.

  [Fix]
  * 1c49e3783f8899 ("selftests/memfd: Fix implicit declaration warnings")

  This fix can be cherry-picked into F/G and compiled without any problem.
  Older kernel does not have this issue.

  [Test Case]
  Build the memfd test in kselftests with:
    sudo make TARGETS=memfd

  With this fix, these warnings will be gone.

  [Where problems could occur]
  This fix is just for fixing the test case compilation, so it's not affecting 
real kernel functionality. If we need to fix it on older release X/B, this 
patch will cause compilation errors as they're missing some other vital 
commits, I think it's fine to ignore them for now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1910323/+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 1908286] Re: Asus G732LWS | ALC294 | Speakers don't work on 20.04 or 20.10

Marked as Incomplete as per request in comment #7

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

-- 
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/1908286

Title:
  Asus G732LWS | ALC294 | Speakers don't work on 20.04 or 20.10

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Asus G732LWS-DS76
  Realtek ALC294 (Intel HDA Audio)
  Xubuntu 20.04 with kernel 5.4.0-58-generic

  No sound from speakers even though it shows in pavucontrol.
  For some reason the sound gets redirected to the internal mic (when I play 
music there is no sound from speakers, but when I open Audacity and start 
recording it records a song playing).

  I tried:
  alc294-sound-patch.fw from https://bugzilla.kernel.org/show_bug.cgi?id=206589
No effect
  "options snd-hda-intel model=asus-zenbook" in /etc/modprobe.d/alsa-base.conf
Speakers start working, but it is impossible to control the volume, they're 
eithher ON (100%) or OFF (Muted)

  I tried different kernels and sidtributions to localize the problem:
  Doesn't work
Xubuntu 20.04 | 5.4.0-58-generic
Xubuntu 20.04 | 5.4.0-54-generic
Xubuntu 20.04 | 5.4.0-48-generic
Xubuntu 20.10 | 5.8.0-25-generic
Fedora 33 | 5.8.15-301.fc33.x86_64
Manjaro 20.2  | 5.9.11-3-MANJARO
  WORKS
Xubuntu 20.04 | 5.4.0-42-generic

  It appears that it is a kernel problem and something broke between
  5.4.0-42-generic and 5.4.0-48-generic.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-5.4.0-58-generic 5.4.0-58.64
  ProcVersionSignature: Ubuntu 5.4.0-58.64-generic 5.4.73
  Uname: Linux 5.4.0-58-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.14
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  kotek  5812 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: XFCE
  Date: Tue Dec 15 09:25:13 2020
  InstallationDate: Installed on 2020-10-01 (75 days ago)
  InstallationMedia: Xubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 
(20200731)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 0b05:1866 ASUSTek Computer, Inc. N-KEY Device
   Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
   Bus 001 Device 004: ID 8087:0026 Intel Corp. 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: ASUSTeK COMPUTER INC. ROG Strix G732LWS_G732LWS
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-58-generic 
root=UUID=8d8cfa7f-5e24-4952-b6ae-4ae35ca9563d ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-5.4.0-58-generic N/A
   linux-backports-modules-5.4.0-58-generic  N/A
   linux-firmware1.187.6
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/14/2020
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: G732LWS.310
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: G732LWS
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK COMPUTER INC.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrG732LWS.310:bd07/14/2020:svnASUSTeKCOMPUTERINC.:pnROGStrixG732LWS_G732LWS:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnG732LWS:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
  dmi.product.family: ROG Strix
  dmi.product.name: ROG Strix G732LWS_G732LWS
  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/1908286/+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 1920029] Re: Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

*** This bug is a duplicate of bug 1920030 ***
https://bugs.launchpad.net/bugs/1920030

** This bug has been marked a duplicate of bug 1920030
   Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

-- 
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/1920029

Title:
  Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  The Mute/Mic-mute LEDs are not work when muting audio-output/microphone on HP 
850/840/440 G8 laptops.

  [Fix]
  Add three realtek quirks for them.

  [Test]
  After applying the quirks, the LEDs are functioned on HP 850/840/440 G8 
laptops.

  [Where problems could occur]
  If HP ships the different system boards design with the same subsystem IDs of 
audio codec which are using different GPIO pins (different layout), then the 
quirks will not work (LEDs will not function when muting audio-output or 
microphone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1920029/+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 1480219] Re: [Dell OptiPlex 3030] No display after rotation

Trusty EOL.

** Changed in: linux (Ubuntu)
   Status: Incomplete => Won't Fix

-- 
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/1480219

Title:
  [Dell OptiPlex 3030] No display after rotation

Status in HWE Next:
  Won't Fix
Status in linux package in Ubuntu:
  Won't Fix

Bug description:
  CID: 201401-14498 Dell OptiPlex 3030

  The screen will goes black after rotate to any orientation.

  ubuntu@201401-14498:~$ lspci -nn | grep '\[03'
  00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 
v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)
  01:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Jet 
XT [Radeon R5 M240] [1002:6664]

  
  Steps:
  1. Install 14.04.2 + update (3.16.0-45) + proprietary AMD video driver
  2. Rotate the display in System Settings

  Expected result:
  * It should be fine with any orientation.

  Actual result:
  * No display after rotation, switch to VT and switch back does not help.

  Error message could be found in dmesg output:
  [   50.472710] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register 
before interrupt
  [   82.746407] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register 
before interrupt

  Also the Xorg log
  [   315.336] (II) AIGLX: Suspending AIGLX clients for VT switch
  [   315.337] (II) fglrx(0): Backup framebuffer data.
  [   315.404] (II) fglrx(0): Backup complete.
  [   315.404] (EE) fglrx(0): XMM: Fail to unregister UVDFWVIRQ! (EE) fglrx(0):

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: linux-image-3.16.0-45-generic 3.16.0-45.60~14.04.1
  ProcVersionSignature: Ubuntu 3.16.0-45.60~14.04.1-generic 3.16.7-ckt14
  Uname: Linux 3.16.0-45-generic x86_64
  NonfreeKernelModules: fglrx
  ApportVersion: 2.14.1-0ubuntu3.11
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Jul 31 05:33:29 2015
  InstallationDate: Installed on 2015-07-31 (0 days ago)
  InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 
(20150218.1)
  SourcePackage: linux-lts-utopic
  UpgradeStatus: No upgrade log present (probably fresh install)
  --- 
  ApportVersion: 2.14.1-0ubuntu3.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ubuntu 1572 F pulseaudio
  CRDA:
   country TW:
(2402 - 2472 @ 40), (3, 27)
(5270 - 5330 @ 40), (3, 17), DFS
(5735 - 5815 @ 40), (3, 30)
  CurrentDesktop: Unity
  DistroRelease: Ubuntu 14.04
  HibernationDevice: RESUME=UUID=bc451fa5-0e74-4fc8-8e17-2a5c47866983
  InstallationDate: Installed on 2015-07-31 (0 days ago)
  InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 
(20150218.1)
  MachineType: Dell Inc. OptiPlex 3030 AIO
  NonfreeKernelModules: fglrx
  Package: linux (not installed)
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-45-generic 
root=UUID=37e2ded9-0ccd-405e-a658-b5cce13f830e ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 3.16.0-45.60~14.04.1-generic 3.16.7-ckt14
  RelatedPackageVersions:
   linux-restricted-modules-3.16.0-45-generic N/A
   linux-backports-modules-3.16.0-45-generic  N/A
   linux-firmware 1.127.14
  Tags:  trusty
  Uname: Linux 3.16.0-45-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 01/21/2014
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A00
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 13
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA00:bd01/21/2014:svnDellInc.:pnOptiPlex3030AIO:pvr01:rvnDellInc.:rn:rvr:cvnDellInc.:ct13:cvr:
  dmi.product.name: OptiPlex 3030 AIO
  dmi.product.version: 01
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1480219/+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 1378744] Re: nVidia GK106GLM [Quadro K2100M] [10de:11fc] Connect to HDMI / DP port with open-source driver will cause Xorg crash

Trusty EOL, closing this.

** Changed in: linux (Ubuntu)
   Status: Confirmed => Won't Fix

** Changed in: xserver-xorg-video-nouveau (Ubuntu)
   Status: New => Won't Fix

-- 
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/1378744

Title:
  nVidia GK106GLM [Quadro K2100M] [10de:11fc] Connect to HDMI / DP port
  with open-source driver will cause Xorg crash

Status in Nouveau Xorg driver:
  Unknown
Status in linux package in Ubuntu:
  Won't Fix
Status in xserver-xorg-video-nouveau package in Ubuntu:
  Won't Fix

Bug description:
  CID: 201305-13527 Dell Precision M4800

  Xorg would crash and restart (you will see the login screen again and
  again) when the HDMI / DP cable is connected to the system.

  Steps:
  1. Install 14.04 + update (3.13.0-36), boot to desktop
  2. Connect a HDMI / DP cable

  Expected result:
  * The external monitor should work

  Actual result:
  * The external monitor screen is black, and the Xorg crashed -> black screen 
on this laptop -> login screen shows up -> black screen... repeat.

  WORKAROUND:
  * Install the proprietary nvidia driver

  I'm not sure if this should be consider as a blocker.
  But hey, we need to certified this I+N system with the proprietary driver, I 
think it's OK to not to call this a blocker.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: linux-image-3.13.0-36-generic 3.13.0-36.63
  ProcVersionSignature: Ubuntu 3.13.0-36.63-generic 3.13.11.6
  Uname: Linux 3.13.0-36-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ubuntu 7071 F pulseaudio
ubuntu 7529 F pulseaudio
   /dev/snd/controlC1:  ubuntu 7071 F pulseaudio
ubuntu 7529 F pulseaudio
  CRDA:
   country TW:
(2402 - 2472 @ 40), (3, 27)
(5270 - 5330 @ 40), (3, 17), DFS
(5735 - 5815 @ 40), (3, 30)
  CurrentDesktop: Unity
  Date: Wed Oct  8 06:20:44 2014
  HibernationDevice: RESUME=UUID=46ed949d-eff8-48e9-b337-6425f480cf12
  InstallationDate: Installed on 2014-10-08 (0 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  MachineType: Dell Inc. Precision M4800
  ProcFB:
   0 inteldrmfb
   1 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-36-generic.efi.signed 
root=UUID=e7f55d08-44a4-447e-8fc6-563864d60df4 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.13.0-36-generic N/A
   linux-backports-modules-3.13.0-36-generic  N/A
   linux-firmware 1.127.7
  RfKill:
   0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/02/2014
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A06
  dmi.board.name: 0FVDR2
  dmi.board.vendor: Dell Inc.
  dmi.board.version: X02
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA06:bd01/02/2014:svnDellInc.:pnPrecisionM4800:pvr01:rvnDellInc.:rn0FVDR2:rvrX02:cvnDellInc.:ct9:cvr:
  dmi.product.name: Precision M4800
  dmi.product.version: 01
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nouveau/+bug/1378744/+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 1917194] Re: [Dell G5 5590] lspci freezes computer on Ubuntu 20.04

2021-03-18 Thread koba

@Ariel, would you like try the oem kerenl!?
#sudo apt install linux-image-oem-20.04b

-- 
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/1917194

Title:
  [Dell G5 5590] lspci freezes computer on Ubuntu 20.04

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After upgrading from Ubuntu 18.04 to 20.04 my computer started to
  freeze when running lspci.

  I ended up noticing that it happened when trying to query device
  '1f:00.0' a USB port. After some kernel and bios updates the problem
  got worse. Now the computer freezes ~5 seconds after booting up.

  I tried:
  1) Running in recovery mode, also freezes
  2) Running an older kernel version (5.4.0-66-generic), also freezes
  3) Removing nvidia drivers (just in case), also freezes
  4) Running all combinations nodemodeset, acpi=off an nouveau blacklisting
  5) Updating all drivers

  The computer freezes for ever, I can't switch TTYs, move the mouse,
  anything, the only way to leave was to force shutdown. On the last
  cases after switching to a tty I could see this messages before the
  freeze ocurred:

  kernel: xhci_hcd :1f:00.0: PCI post-resume error -19!
  kernel: xhci_hcd :1f:00.0: HC died; cleaning up

  Running Ubuntu 20.04 from a USB sticks works fine, as well as doing a fresh 
install.
  All logs were obtained by chrooting to the faulty partition from a fresh 
install, if there are any more logs that would be helpful, let me know.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1917194/+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 1919408] Re: General protection fault, kernel panics on ASUS M5A99FX PRO R2.0

2021-03-18 Thread Daniel van Vugt

Thanks for the logs. I am seeing "general protection fault" in multiple
different processes so it sounds like a hardware problem, if not a
kernel bug. Please try testing your RAM per comment #7.

-- 
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/1919408

Title:
  General protection fault, kernel panics on ASUS M5A99FX PRO R2.0

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  After copied (dd copy) old disk /home to bigger one then  reboot xorg start 
to freeze it seems kernel crash rather than only Xorg, because all input 
devices (keyboard, mouse) turned off completely. only option is hard reboot.
  I upgrade distro from 20.04 to 20.10, the situation remain the same after 
every login to desktop the system freeze completely and need it to do hard 
reboot.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: xorg 1:7.7+19ubuntu15
  ProcVersionSignature: Ubuntu 5.8.0-45.51-lowlatency 5.8.18
  Uname: Linux 5.8.0-45-lowlatency x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.11-0ubuntu50.5
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompizPlugins: 
[core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,staticswitcher,workarounds,scale,expo,ezoom,dbus]
  CompositorRunning: None
  CurrentDesktop: MATE
  Date: Wed Mar 17 01:11:19 2021
  DistUpgraded: 2021-03-15 02:52:49,427 INFO cache.commit()
  DistroCodename: groovy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GconfCompiz:
   /apps/compiz-1/general:
 /apps/compiz-1/general/screen0:
  /apps/compiz-1/general/screen0/options:
   active_plugins = 
[core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,staticswitcher,workarounds,scale,expo,ezoom,dbus]
  GpuHangFrequency: Continuously
  GpuHangReproducibility: Occurs more often under certain circumstances
  GpuHangStarted: Within the last week or two
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 
470/480/570/570X/580/580X/590] [1002:67df] (rev ef) (prog-if 00 [VGA 
controller])
 Subsystem: XFX Pine Group Inc. Radeon RX 570 [1682:c570]
  InstallationDate: Installed on 2018-05-05 (1046 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  MachineType: To be filled by O.E.M. To be filled by O.E.M.
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-45-lowlatency 
root=UUID=17faa721-1006-4426-b460-57b94bfebefa ro threadirqs 
crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M 
crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M 
crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M 
crashkernel=512M-:192M
  SourcePackage: xorg
  Symptom: display
  Title: Xorg freeze
  UpgradeStatus: Upgraded to groovy on 2021-03-15 (1 days ago)
  dmi.bios.date: 04/10/2013
  dmi.bios.release: 4.6
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1708
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: M5A99FX PRO R2.0
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev 1.xx
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1708:bd04/10/2013:br4.6:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnASUSTeKCOMPUTERINC.:rnM5A99FXPROR2.0:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: To be filled by O.E.M.
  dmi.product.sku: SKU
  dmi.product.version: To be filled by O.E.M.
  dmi.sys.vendor: To be filled by O.E.M.
  version.compiz: compiz 1:0.9.14.1+20.10.20200813-0ubuntu1
  version.libdrm2: libdrm2 2.4.102-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.10.1
  version.libgl1-mesa-glx: libgl1-mesa-glx 20.2.6-0ubuntu0.20.10.1
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1ubuntu1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200714-1
  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/1919408/+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 1919408] Re: General protection fault, kernel panics on ASUS M5A99FX PRO R2.0

2021-03-18 Thread Daniel van Vugt

Please also check your RAM in case it's faulty using one of:

  https://www.memtest.org/
  https://www.memtest86.com/

-- 
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/1919408

Title:
  General protection fault, kernel panics on ASUS M5A99FX PRO R2.0

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  After copied (dd copy) old disk /home to bigger one then  reboot xorg start 
to freeze it seems kernel crash rather than only Xorg, because all input 
devices (keyboard, mouse) turned off completely. only option is hard reboot.
  I upgrade distro from 20.04 to 20.10, the situation remain the same after 
every login to desktop the system freeze completely and need it to do hard 
reboot.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: xorg 1:7.7+19ubuntu15
  ProcVersionSignature: Ubuntu 5.8.0-45.51-lowlatency 5.8.18
  Uname: Linux 5.8.0-45-lowlatency x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.11-0ubuntu50.5
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompizPlugins: 
[core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,staticswitcher,workarounds,scale,expo,ezoom,dbus]
  CompositorRunning: None
  CurrentDesktop: MATE
  Date: Wed Mar 17 01:11:19 2021
  DistUpgraded: 2021-03-15 02:52:49,427 INFO cache.commit()
  DistroCodename: groovy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GconfCompiz:
   /apps/compiz-1/general:
 /apps/compiz-1/general/screen0:
  /apps/compiz-1/general/screen0/options:
   active_plugins = 
[core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,staticswitcher,workarounds,scale,expo,ezoom,dbus]
  GpuHangFrequency: Continuously
  GpuHangReproducibility: Occurs more often under certain circumstances
  GpuHangStarted: Within the last week or two
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 
470/480/570/570X/580/580X/590] [1002:67df] (rev ef) (prog-if 00 [VGA 
controller])
 Subsystem: XFX Pine Group Inc. Radeon RX 570 [1682:c570]
  InstallationDate: Installed on 2018-05-05 (1046 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  MachineType: To be filled by O.E.M. To be filled by O.E.M.
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-45-lowlatency 
root=UUID=17faa721-1006-4426-b460-57b94bfebefa ro threadirqs 
crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M 
crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M 
crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M 
crashkernel=512M-:192M
  SourcePackage: xorg
  Symptom: display
  Title: Xorg freeze
  UpgradeStatus: Upgraded to groovy on 2021-03-15 (1 days ago)
  dmi.bios.date: 04/10/2013
  dmi.bios.release: 4.6
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1708
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: M5A99FX PRO R2.0
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev 1.xx
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1708:bd04/10/2013:br4.6:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnASUSTeKCOMPUTERINC.:rnM5A99FXPROR2.0:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: To be filled by O.E.M.
  dmi.product.sku: SKU
  dmi.product.version: To be filled by O.E.M.
  dmi.sys.vendor: To be filled by O.E.M.
  version.compiz: compiz 1:0.9.14.1+20.10.20200813-0ubuntu1
  version.libdrm2: libdrm2 2.4.102-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.10.1
  version.libgl1-mesa-glx: libgl1-mesa-glx 20.2.6-0ubuntu0.20.10.1
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1ubuntu1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200714-1
  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/1919408/+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 1908677] Re: Dell Latitude 9510 capture volume is too low

This bug was fixed in the package alsa-ucm-conf - 1.2.4-2ubuntu1

---
alsa-ucm-conf (1.2.4-2ubuntu1) hirsute; urgency=medium

  * d/p/0001-rt715-init-setup-ADC07-to-a-proper-volume.patch
Correct rt715 init volume setting. (LP: #1908677)

 -- Kai-Chuan Hsieh   Thu, 18 Mar 2021
11:10:27 +0100

** Changed in: alsa-ucm-conf (Ubuntu)
   Status: Fix Committed => Fix Released

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

Title:
  Dell Latitude 9510 capture volume is too low

Status in OEM Priority Project:
  New
Status in alsa-ucm-conf package in Ubuntu:
  Fix Released

Bug description:
  [Impact]

   * The internal mic default volume is too low
     A upstream commit correct the init configuration

  [Test Case]

   * Using gnome-sound-recoder to record audio without tweak capture volume
     The volume is very low
   * Try to update the init.conf mentioned by
     
https://github.com/alsa-project/alsa-ucm-conf/commit/263bd26b1216c933db3d216197a78678d0f8610e
     $ alsactl init
     $ amixer cget name='rt715 ADC 07 Capture Volume'
     numid=14,iface=MIXER,name='rt715 ADC 07 Capture Volume'
    ; type=INTEGER,access=rw---R--,values=2,min=0,max=63,step=0
    : values=58,58
    | dBscale-min=-17.25dB,step=0.75dB,mute=0

   * Using gnome-sound-recorder to record again
     The volume is significantly improved

  [Where problems could occur]

   * The change only apply to the hardware with rt715 codec.

   * The change adjust the volume only, but not change other control,
     the worst case is the change doesn't take effect.

  [Other Info]

   * The change has been verified on Latitude 9510.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1908677/+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 1917203] Re: AMD-Vi: Unable to read/write to IOMMU perf counter

2021-03-18 Thread David Coe

I've just tried Surajee's patch on Ubuntu's latest kernel 5.11.0-11 for
upcoming Hirsute and it consistently unlatches IOMMU after 6 x 20 msec
tries on my Ryzen 2400G. Mainline 5.12-rc2 gave identical results.

Paul Menzel too gets failure even after 10 x 20 msecs on a 2200G and
regards so long a delay as most unacceptable. Alexander Monakov's very
simple patch always works for me but I haven't seen data from other
people. Surajee has mentioned problems with it for some part of AMD's
product range and, as one of AMD's IOMMU experts down at Austen Texas,
he should know his onions :-).

I would be tempted to run with the patch (11 x 20 msecs), log the exit
count number and get some user feedback. Hopefully an improved patch
will emerge! AMD may have commercial as well as technical reasons not
leave it unaddressed.

Best regards

-- 
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/1917203

Title:
  AMD-Vi: Unable to read/write to IOMMU perf counter

Status in linux package in Ubuntu:
  In Progress

Bug description:
  This boot warning (concealed by grub not taking over the fbcon console
  on a solo installation but always present on a multi-boot) has been
  bothering Linux users of AMD Ryzen machines for some time.

  The problem is currently under discussion at kernel level
  .

  One solution proposed by Suravee Suthikulpanit

  works but inserts a boot-up delay of (at least) 100 msec. A second
  option by Alexander Monakov 
   also works but
  inserts no delay and more-or-less just moves one line of code.

  I've tried both solutions with kernel rebuilds for both Breezy kernel
  5.8.18 and Hirsute kernel 5.10.11 and both work on my AMD Ryzen 2400G.
  Could I encourage your kernel experts to evaluate the situation (I
  think SuSE folk already are).

  My suggestion (as a humble user :-) ) would be to fold Alex's simple
  patch into your own list of kernel tweeks and get the correction out
  with the upcoming Hirsute release.

  Best regards and all respect!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1917203/+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 1917194] Re: [Dell G5 5590] lspci freezes computer on Ubuntu 20.04

2021-03-18 Thread Ariel Torti

Tried 5.8.0-43 kernel and didn't work.
I also tried booting Manjaro which uses 5.6.15-1-MANJARO and the issue is 
present.

I ended up doing a workaround, compiling an ubuntu kernel with `pci-
stub` as builtin and `xhci-hcd` as a dynamic module. That way I can make
pci-stub bind to the culprit device and everything works fine.

-- 
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/1917194

Title:
  [Dell G5 5590] lspci freezes computer on Ubuntu 20.04

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After upgrading from Ubuntu 18.04 to 20.04 my computer started to
  freeze when running lspci.

  I ended up noticing that it happened when trying to query device
  '1f:00.0' a USB port. After some kernel and bios updates the problem
  got worse. Now the computer freezes ~5 seconds after booting up.

  I tried:
  1) Running in recovery mode, also freezes
  2) Running an older kernel version (5.4.0-66-generic), also freezes
  3) Removing nvidia drivers (just in case), also freezes
  4) Running all combinations nodemodeset, acpi=off an nouveau blacklisting
  5) Updating all drivers

  The computer freezes for ever, I can't switch TTYs, move the mouse,
  anything, the only way to leave was to force shutdown. On the last
  cases after switching to a tty I could see this messages before the
  freeze ocurred:

  kernel: xhci_hcd :1f:00.0: PCI post-resume error -19!
  kernel: xhci_hcd :1f:00.0: HC died; cleaning up

  Running Ubuntu 20.04 from a USB sticks works fine, as well as doing a fresh 
install.
  All logs were obtained by chrooting to the faulty partition from a fresh 
install, if there are any more logs that would be helpful, let me know.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1917194/+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

Re: [Kernel-packages] [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected

On Thu, Mar 18, 2021 at 12:25 PM Ryan Harper <1918...@bugs.launchpad.net> wrote:
>
> * dann frazier <1918...@bugs.launchpad.net> [2021-03-18 12:11]:
> > On Thu, Mar 18, 2021 at 10:25 AM Ryan Harper <1918...@bugs.launchpad.net> 
> > wrote:
> > >
> > > * dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:30]:
> > > > On Tue, Mar 16, 2021 at 10:05 AM Ryan Harper 
> > > > <1918...@bugs.launchpad.net> wrote:
> > > > >
> > > > > Hi Dan,
> > > > >
> > > >
> > > > 1) flash-kernel could get installed post-divert. In that case,
> > > > flash-kernel's own postinst will cause it to run and then fail. This
> > > > happens today if you start with a cloud image w/o flash-kernel
> > > > pre-baked because Ubuntu's kernel recommends flash-kernel, causing it
> > > > to be installed along with the kernel. Official cloud images happen to
> > >
> > > Hrm, so if we take a squashfs rootfs (with no flash-kernel present)
> > > chroot into it and install the linux-image-generic package pulling in
> > > flash-kernel this fails due to postinst of flash-kernel expecting
> > > initramfs to already be generated?  This doesn't seem like a curtin bug.
> >
> > If done so in a chroot that exposes the kernel interfaces (/proc &
> > /sys) that claim to be hardware that requires the initramfs to be
> > post-processed, yes.
>
> Maybe I'm missing something but if I install linux-image-generic
> it populates /boot with vmlinuz-$version (and a few more things)
> and /lib/modules/$version  and the kernels postinst will invoke
> update-initramfs.  The /boot/initrd.img-$version is *generated* at
> that time during the kernel's postinstall
>
> Now, in the arm case IIUC, the kernel package has a dep on flash-kernel
> being present as it's "needed" to generate the initramfs ... so how can
> flash-kernel's postinst *fail* if it is the tool that's generating said
> initramfs file?

What flash-kernel does is generate wrapped versions of *exisiting*
vmlinuz and initrd.img files. It doesn't generate those files, rather
post-processes them.
The kernel doesn't depend on flash-kernel, it just recommends it like
it does GRUB on x86.

  -dann

-- 
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/1918427

Title:
  curtin: install flash-kernel in arm64 UEFI unexpected

Status in cloud-images:
  Confirmed
Status in curtin package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  In Progress

Bug description:
  I used APM Mustang which flash-kernel supported in u-boot mode.
  But I used it with UEFI environment.
  It will cause fatal error when I used ARM64 ubuntu live server ISO to install 
system.

  In code[1], this will not install `flash-kernel` for APM Mustang because of 
UEFI.
  So that means code[2] will not disable `flash-kernel` in target system, only 
disable `update-initramfs`.

  When curtin execute to `install_kernel` stage, code[3,4] will not install 
`flash-kernel` either.
  But in code[5], it will install `linux-generic`.
  `linux-generic` has a long dependency tree and it will get `flash-kernel` in 
Recommended field.
  Apt by default will install Recommended package before kernel is installed.[6]
  So it will still execute `zz-flash-kernel` and `flash-kernel` when installing 
kernel.
  But system didn't create any `initrd.img` ever because curtin disable 
`update-initramfs` in code[2].
  This will cause that `flash-kernel` cannot find `initrd.img.` and fail 
when installing it.

  This issue didn't effect all ARM64 UEFI platform because `flash-kernel` 
didn't support them and skip.[7]
  I'm not sure which is best solution for this.
  But I think we should apply PR-27 in `flash-kernel`[8] for enhancement and 
fix curtin process with this patch both.

  If we only apply PR-27, it should work fine as well because it will be 
skipped when detecting UEFI
  and install `flash-kernel` before `disable_update_initranfs` in ARM platform 
without UEFI.[9]

  [Patch-1,2,3] might have side effect.
  Picking one patch for curtin should be enough.
  But I need your advice for this to determine which one is better for curtin.
  There are two categories
  1. avoid installing flash-kernel if no need, [Patch1,2]
  2. always install flash-kernel in arm/arm64 and make sure it be installed 
before code[2] [Patch3]
  (I will attach patch in reply.)

  Thanks a lot
  Regards,
  Date

  [1] 
https://github.com/canonical/curtin/blob/master/curtin/deps/__init__.py#L57-L58
  [2] 
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L1693-L1699
  [3] 
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L365-L370
  [4] 
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L311-L327
  [5] 
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L372-L374
  [6] https://github.com/Debian/apt/blob/master/apt-pkg/init.cc#L132
  [7]

[Kernel-packages] [Bug 1667146] Re: iwlwifi 0000:01:00.0: Error sending REPLY_SCAN_ABORT_CMD: time out after 2000ms.

2021-03-18 Thread ALinuxUser

I have just experienced this problem for the first time (on, admittedly,
Linux Mint) with kernel 5.8.0.

I note also that there is a report on the problem filed against the
Linux kernel itself, here:
https://bugzilla.kernel.org/show_bug.cgi?id=190281

Perhaps Ubuntu devs should engage with that report.

-- 
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/1667146

Title:
  iwlwifi :01:00.0: Error sending REPLY_SCAN_ABORT_CMD: time out
  after 2000ms.

Status in Linux:
  Unknown
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  dmesg:
  [15006.993941] iwlwifi :01:00.0: Error sending REPLY_SCAN_ABORT_CMD: time 
out after 2000ms.
  [15006.993950] iwlwifi :01:00.0: Current CMD queue read_ptr 32 write_ptr 
33
  [15006.993981] iwlwifi :01:00.0: Loaded firmware version: 18.168.6.1
  [15006.994122] iwlwifi :01:00.0: Start IWL Error Log Dump:
  [15006.994125] iwlwifi :01:00.0: Status: 0x03CC, count: 6
  [15006.994139] iwlwifi :01:00.0: 0x0084 | NMI_INTERRUPT_UNKNOWN   
  [15006.994144] iwlwifi :01:00.0: 0x00010564 | uPc
  [15006.994148] iwlwifi :01:00.0: 0x0001054E | branchlink1
  [15006.994152] iwlwifi :01:00.0: 0x00010580 | branchlink2
  [15006.994157] iwlwifi :01:00.0: 0xDBEA | interruptlink1
  [15006.994161] iwlwifi :01:00.0: 0x00012AF2 | interruptlink2
  [15006.994165] iwlwifi :01:00.0: 0x0081 | data1
  [15006.994169] iwlwifi :01:00.0: 0x0703 | data2
  [15006.994173] iwlwifi :01:00.0: 0x000260A4 | line
  [15006.994178] iwlwifi :01:00.0: 0x050018DC | beacon time
  [15006.994182] iwlwifi :01:00.0: 0x0020B724 | tsf low
  [15006.994186] iwlwifi :01:00.0: 0x | tsf hi
  [15006.994190] iwlwifi :01:00.0: 0x | time gp1
  [15006.994194] iwlwifi :01:00.0: 0x002A9515 | time gp2
  [15006.994198] iwlwifi :01:00.0: 0x | time gp3
  [15006.994202] iwlwifi :01:00.0: 0x754312A8 | uCode version
  [15006.994207] iwlwifi :01:00.0: 0x00B0 | hw version
  [15006.994211] iwlwifi :01:00.0: 0x00484B00 | board version
  [15006.994215] iwlwifi :01:00.0: 0x001C | hcmd
  [15006.994220] iwlwifi :01:00.0: 0x27863040 | isr0
  [15006.994228] iwlwifi :01:00.0: 0x1189E000 | isr1
  [15006.994241] iwlwifi :01:00.0: 0x0E02 | isr2
  [15006.994245] iwlwifi :01:00.0: 0x0143FCC3 | isr3
  [15006.994249] iwlwifi :01:00.0: 0x | isr4
  [15006.994252] iwlwifi :01:00.0: 0x0110 | isr_pref
  [15006.994256] iwlwifi :01:00.0: 0x000260A4 | wait_event
  [15006.994259] iwlwifi :01:00.0: 0x022B | l2p_control
  [15006.994273] iwlwifi :01:00.0: 0x07D8 | l2p_duration
  [15006.994280] iwlwifi :01:00.0: 0x0003 | l2p_mhvalid
  [15006.994286] iwlwifi :01:00.0: 0x | l2p_addr_match
  [15006.994292] iwlwifi :01:00.0: 0x0005 | lmpm_pmg_sel
  [15006.994299] iwlwifi :01:00.0: 0x13011136 | timestamp
  [15006.994305] iwlwifi :01:00.0: 0x90A0 | flow_handler
  [15006.994379] iwlwifi :01:00.0: Start IWL Event Log Dump: display last 1 
entries
  [15006.994408] iwlwifi :01:00.0: EVT_LOGT:0002790673:0x010c:0123
  [15006.994450] iwlwifi :01:00.0: Fw not loaded - dropping CMD: 10
  [15006.994459] iwlwifi :01:00.0: Error clearing ASSOC_MSK on BSS (-5)
  [15006.994485] iwlwifi :01:00.0: Microcode SW error detected.  Restarting 
0x200.
  [15006.994492] iwlwifi :01:00.0: CSR values:
  [15006.994507] iwlwifi :01:00.0: (2nd byte of CSR_INT_COALESCING is 
CSR_INT_PERIODIC_REG)
  [15006.994515] iwlwifi :01:00.0:CSR_HW_IF_CONFIG_REG: 0X00484b00
  [15006.994532] iwlwifi :01:00.0:  CSR_INT_COALESCING: 0X0040
  [15006.994540] iwlwifi :01:00.0: CSR_INT: 0X
  [15006.994550] iwlwifi :01:00.0:CSR_INT_MASK: 0X
  [15006.994561] iwlwifi :01:00.0:   CSR_FH_INT_STATUS: 0X
  [15006.994571] iwlwifi :01:00.0: CSR_GPIO_IN: 0X0030
  [15006.994581] iwlwifi :01:00.0:   CSR_RESET: 0X
  [15006.994594] iwlwifi :01:00.0:CSR_GP_CNTRL: 0X080403cd
  [15006.994602] iwlwifi :01:00.0:  CSR_HW_REV: 0X00b0
  [15006.994613] iwlwifi :01:00.0:  CSR_EEPROM_REG: 0Xd4540ffd
  [15006.994621] iwlwifi :01:00.0:   CSR_EEPROM_GP: 0X8801
  [15006.994630] iwlwifi :01:00.0:  CSR_OTP_GP_REG: 0X00030001
  [15006.994648] iwlwifi :01:00.0: CSR_GIO_REG: 0X00080046
  [15006.994660] iwlwifi :01:00.0:CSR_GP_UCODE_REG: 0X
  [15006.994671] iwlwifi :01:00.0:   CSR_GP_DRIVER_REG: 0X
  [15006.994684] iwlwifi :01:00.0:   CSR_UCODE_DRV_GP1: 0X
  [15006.994696] iwlwifi :01:00.0:   CSR_UCODE_DRV_GP2:

Re: [Kernel-packages] [Bug 1919408] Re: Xorg freeze

2021-03-18 Thread Solaris

due to larger file size than 10mb, launchpad rejected attached files,
therefore i compressed them in one file. see attached file.

Thanks

On Thu, Mar 18, 2021 at 7:32 AM K. M. Ravandi 
wrote:

> Here are files as you requested.
>
> On Wed, Mar 17, 2021 at 10:30 PM Daniel van Vugt <
> 1919...@bugs.launchpad.net> wrote:
>
>> Thanks. It seems like the main issue here is kernel panics. Are you able
>> to find a kernel log that includes the kernel panic?
>>
>>   journalctl -b-1 > prev1.txt
>>   journalctl -b-2 > prev2.txt
>>   journalctl -b-3 > prev3.txt
>>
>> Please also check your RAM in case it's faulty using one of:
>>
>>   https://www.memtest.org/
>>   https://www.memtest86.com/
>>
>> ** Summary changed:
>>
>> - Xorg freeze
>> + General protection fault, kernel panics
>>
>> ** Package changed: ubuntu => linux (Ubuntu)
>>
>> ** Summary changed:
>>
>> - General protection fault, kernel panics
>> + General protection fault, kernel panics on ASUS M5A99FX PRO R2.0
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1919408
>>
>> Title:
>>   General protection fault, kernel panics on ASUS M5A99FX PRO R2.0
>>
>> Status in linux package in Ubuntu:
>>   Incomplete
>>
>> Bug description:
>>   After copied (dd copy) old disk /home to bigger one then  reboot xorg
>> start to freeze it seems kernel crash rather than only Xorg, because all
>> input devices (keyboard, mouse) turned off completely. only option is hard
>> reboot.
>>   I upgrade distro from 20.04 to 20.10, the situation remain the same
>> after every login to desktop the system freeze completely and need it to do
>> hard reboot.
>>
>>   ProblemType: Bug
>>   DistroRelease: Ubuntu 20.10
>>   Package: xorg 1:7.7+19ubuntu15
>>   ProcVersionSignature: Ubuntu 5.8.0-45.51-lowlatency 5.8.18
>>   Uname: Linux 5.8.0-45-lowlatency x86_64
>>   NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
>>   .tmp.unity_support_test.0:
>>
>>   ApportVersion: 2.20.11-0ubuntu50.5
>>   Architecture: amd64
>>   BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
>>   CasperMD5CheckResult: skip
>>   CompizPlugins:
>> [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,staticswitcher,workarounds,scale,expo,ezoom,dbus]
>>   CompositorRunning: None
>>   CurrentDesktop: MATE
>>   Date: Wed Mar 17 01:11:19 2021
>>   DistUpgraded: 2021-03-15 02:52:49,427 INFO cache.commit()
>>   DistroCodename: groovy
>>   DistroVariant: ubuntu
>>   ExtraDebuggingInterest: Yes
>>   GconfCompiz:
>>/apps/compiz-1/general:
>>  /apps/compiz-1/general/screen0:
>>   /apps/compiz-1/general/screen0/options:
>>active_plugins =
>> [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,staticswitcher,workarounds,scale,expo,ezoom,dbus]
>>   GpuHangFrequency: Continuously
>>   GpuHangReproducibility: Occurs more often under certain circumstances
>>   GpuHangStarted: Within the last week or two
>>   GraphicsCard:
>>Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX
>> 470/480/570/570X/580/580X/590] [1002:67df] (rev ef) (prog-if 00 [VGA
>> controller])
>>  Subsystem: XFX Pine Group Inc. Radeon RX 570 [1682:c570]
>>   InstallationDate: Installed on 2018-05-05 (1046 days ago)
>>   InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64
>> (20180426)
>>   MachineType: To be filled by O.E.M. To be filled by O.E.M.
>>   ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-45-lowlatency
>> root=UUID=17faa721-1006-4426-b460-57b94bfebefa ro threadirqs
>> crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M
>> crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M
>> crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M
>> crashkernel=512M-:192M
>>   SourcePackage: xorg
>>   Symptom: display
>>   Title: Xorg freeze
>>   UpgradeStatus: Upgraded to groovy on 2021-03-15 (1 days ago)
>>   dmi.bios.date: 04/10/2013
>>   dmi.bios.release: 4.6
>>   dmi.bios.vendor: American Megatrends Inc.
>>   dmi.bios.version: 1708
>>   dmi.board.asset.tag: To be filled by O.E.M.
>>   dmi.board.name: M5A99FX PRO R2.0
>>   dmi.board.vendor: ASUSTeK COMPUTER INC.
>>   dmi.board.version: Rev 1.xx
>>   dmi.chassis.asset.tag: To Be Filled By O.E.M.
>>   dmi.chassis.type: 3
>>   dmi.chassis.vendor: To Be Filled By O.E.M.
>>   dmi.chassis.version: To Be Filled By O.E.M.
>>   dmi.modalias:
>> dmi:bvnAmericanMegatrendsInc.:bvr1708:bd04/10/2013:br4.6:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnASUSTeKCOMPUTERINC.:rnM5A99FXPROR2.0:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
>>   dmi.product.family: To be filled by O.E.M.
>>   dmi.product.name: To be filled by O.E.M.
>>   dmi.product.sku: SKU
>>   dmi.product.version: To be filled by O.E.M.
>>   dmi.sys.vendor:

[Kernel-packages] [Bug 1920030] Re: Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

** Also affects: linux-oem-5.10 (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: linux-oem-5.10 (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: linux-oem-5.10 (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: linux-oem-5.10 (Ubuntu Focal)
   Status: New => Fix Committed

** Changed in: linux-oem-5.10 (Ubuntu Groovy)
   Status: New => Invalid

-- 
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/1920030

Title:
  Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

Status in OEM Priority Project:
  Triaged
Status in linux package in Ubuntu:
  Incomplete
Status in linux-oem-5.10 package in Ubuntu:
  New
Status in linux source package in Focal:
  New
Status in linux-oem-5.10 source package in Focal:
  Fix Committed
Status in linux source package in Groovy:
  New
Status in linux-oem-5.10 source package in Groovy:
  Invalid

Bug description:
  [Impact]
  The Mute/Mic-mute LEDs are not work when muting audio-output/microphone on HP 
850/840/440 G8 laptops.

  [Fix]
  Add three realtek quirks for them.

  [Test]
  After applying the quirks, the LEDs are functioned on HP 850/840/440 G8 
laptops.

  [Where problems could occur]
  If HP ships the different system boards design with the same subsystem IDs of 
audio codec which are using different GPIO pins (different layout), then the 
quirks will not work (LEDs will not function when muting audio-output or 
microphone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1920030/+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 1919930] Re: power off stress test will hang on the TGL machines

** Changed in: linux-oem-5.10 (Ubuntu Focal)
   Status: In Progress => Fix Committed

-- 
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/1919930

Title:
  power off stress test will hang on the TGL machines

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem-5.10 package in Ubuntu:
  In Progress
Status in linux-oem-5.10 source package in Focal:
  Fix Committed
Status in linux source package in Groovy:
  In Progress
Status in linux source package in Hirsute:
  In Progress

Bug description:
  Intel suggested that we do 2 actions to fix this problem, the 1st is
  merging 5 kernel patches, this only applies to H and OEM-5.10 since
  there is no tgl.c in the groovy kernel yet. the 2nd is change a kernel
  config, this change applies to H, G and OEM-5.10.

  https://github.com/thesofproject/linux/issues/2781

  [Impact]
  When we run poweroff/on stress test on some lenovo TGL laptop, the
  system will randomly hang, and when this issue happens, the dmesg
  shows the sof audio driver fails.

  [Fix]
  Intel recommend that we backport 5 kernel patches and change a
  kernel config.

  [Test]
  After applying the changes, and test on TGL/cml/whl machines,
  the audio function works as good as before, and the poweroff stress
  test didn't hang anymore.

  
  [Where problems could occur]
  The kernel patches probably could introduce issues when system
  powre off or reboot on TGL machines, but this possibility is low
  since we have tested these patches on different TGL machines.

  the kernel option change could introduce power consumption
  regression, but it only affects power saving and package_cstate values
  when any capture stream is active, while no impact if all capture
  streams are inactive. that is to say, in theory it will not impact
  the power consumption in short idle or long idle. And I checked the
  system cound enter package_c10 after this change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1919930/+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 1919123] Re: Dell Precision 5550 takes up to 10 seconds to respond when coming out of sleep

** Changed in: linux-oem-5.10 (Ubuntu Focal)
   Status: In Progress => Fix Committed

-- 
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/1919123

Title:
  Dell Precision 5550 takes up to 10 seconds to respond when coming out
  of sleep

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem-5.10 package in Ubuntu:
  Invalid
Status in linux source package in Focal:
  In Progress
Status in linux-oem-5.10 source package in Focal:
  Fix Committed
Status in linux source package in Groovy:
  In Progress
Status in linux source package in Hirsute:
  In Progress

Bug description:
  [Impact]
  On some platforms, the EC doesn't support the register reading sequence
  for sentelic[1], and then make the EC can't respond commands for a while
  when probing. It leads to the keyboard is non-responsive for around 10
  seconds while waking up from s2idle.

  [   44.304488] i8042: [9804] d4 -> i8042 (command)
  [   44.304634] i8042: [9804] f3 -> i8042 (parameter)
  [   44.304787] i8042: [9804] fa <- i8042 (interrupt, 1, 12)
  [   44.304855] i8042: [9804] d4 -> i8042 (command)
  [   44.304938] i8042: [9804] 66 -> i8042 (parameter)
  [   44.337698] i8042: [9813] d4 -> i8042 (command)
  [   44.905695] i8042: [9942] 88 -> i8042 (parameter)
  [   45.497478] i8042: [10102] d4 -> i8042 (command)
  [   46.098041] i8042: [10253] f3 -> i8042 (parameter)
  [   46.098070] i8042: [10253] fe <- i8042 (interrupt, 1, 12)
  [   46.718154] i8042: [10386] d4 -> i8042 (command)
  [   47.309915] i8042: [10386] f4 -> i8042 (parameter)
  [   47.918961] i8042: [10556] d4 -> i8042 (command)
  [   48.402624] i8042: [10556] f6 -> i8042 (parameter)

  [Fix]
  A DMI quirk to mark this platform doesn't have aux device could avoid those 
commands to be sent. And the system could still using i2c
  interface to communicate with the touchpad.
  https://lkml.org/lkml/2021/3/15/126

  [Test]
  Verified on Dell Precision 5550

  [Where problem could occur]
  The quirk only affects the listed platform, there is no regression could 
occur.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1919123/+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 1918378] Re: Cirrus Audio Codec CS8409/CS42L42: Input Device does not switch to headset Mic when a headset is inserted

** Changed in: linux-oem-5.10 (Ubuntu Focal)
   Status: In Progress => Fix Committed

-- 
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/1918378

Title:
  Cirrus Audio Codec CS8409/CS42L42: Input Device does not switch to
  headset Mic when a headset is inserted

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem-5.10 package in Ubuntu:
  Invalid
Status in linux source package in Focal:
  Invalid
Status in linux-oem-5.10 source package in Focal:
  Fix Committed
Status in linux source package in Hirsute:
  In Progress
Status in linux-oem-5.10 source package in Hirsute:
  Invalid

Bug description:
  [SRU Justfication]

  BugLink: https://bugs.launchpad.net/bugs/1918378

  [Impact]

  With headset/mic injected, GNOME Settings does not update record volume
  control option to the headset one automatically.

  [Fix]

  https://github.com/CirrusLogic/product-
  support/blob/82915ae88a02781b173c83568426722789d74f37/dell/hda/5.10.7/0001
  -ALSA-hda-cirrus-Fix-Headset-Mic-volume-control-name.patch

  [Test Case]

  Tested on affected platform. With the patch, both playback and record
  volume control will be updated simultaneously.

  [Where problems could occur]

  Control object name string update only.

  [Other Info]

  This is a follow-up for patchset
  https://lists.ubuntu.com/archives/kernel-team/2021-March/117814.html
  titled "Cirrus CS8409 HDA bridge/CS42L42 codec support".

  == original bug description ==

  Steps:
  1. With the latest test kernel from Vicamo's PPA as of 3/8
  2. Plug in a headset

  Expected behavior:
  Input Device should switch to Headset Microphone - Built-in Audio

  Actual behavior:
  Input Device remains at Microphone - Built-in Audio and users need to 
manually switch to correct Input Device for the audio recording via headset to 
work

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1918378/+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 1916467] Re: [Intel Maple Ridge] system cannot enter S3 the first time while connecting to TBT4 storage

** Changed in: linux-oem-5.10 (Ubuntu Focal)
   Status: In Progress => Fix Committed

-- 
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/1916467

Title:
  [Intel Maple Ridge] system cannot enter S3 the first time while
  connecting to TBT4 storage

Status in HWE Next:
  In Progress
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem-5.10 package in Ubuntu:
  Invalid
Status in linux source package in Focal:
  Won't Fix
Status in linux-oem-5.10 source package in Focal:
  Fix Committed
Status in linux source package in Hirsute:
  In Progress
Status in linux-oem-5.10 source package in Hirsute:
  Invalid

Bug description:
  [SRU Justification]

  [Impact]

  Systems with Intel Maple Ridge addon card with tbt devices attached may
  fail to suspend/resume.

  [Fix]

  Commit 319696aa80 ("xhci: Fix repeated xhci wake after suspend due to
  uncleared internal wake state") currently landed in
  https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git branch
  for-usb-linus.

  [Test Case]

  When booted from unpatched kernel, starting from oem-5.10 that has
  received Intel Maple Ridge enablement fixes, XHCI port on Maple Ridge
  card may wake itself unsolicitedly when performing runtime/deep suspend:

kernel: [326] pci_pme_active:2422: xhci_hcd :37:00.0: PME# disabled
kernel: [326] __pci_set_master:4219: xhci_hcd :37:00.0: enabling bus 
mastering
kernel: [326] pci_save_state:1553: xhci_hcd :37:00.0: saving config 
space at offset 0x0 (reading 0x11388086)
...
kernel: [326] pci_pme_active:2422: xhci_hcd :37:00.0: PME# enabled

  The suspend resume process will stuck forever.

  [Where problems could occur]

  Tried on a few more platforms, didn't found possible regression.

  == original bug description ==

  [Reproduce Steps]
  1. install TBT4 card
  2. Boot into Ubuntu X68
  3. suspend and wake up to confirm S3 function
  3. Connect TBT storage
  4. suspend
  5. system cannot enter S3

  [Results]
  Expected Result: system enters suspend
  Actual Result: 1st attempt fails, screen will be turned off but power & fan 
won't. system can only enter s3 afterwards

  Upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=211377

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1916467/+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 1916554] Re: Cirrus Audio Codec CS8409/CS42L42 support

** Changed in: linux-oem-5.10 (Ubuntu Focal)
   Status: In Progress => Fix Committed

-- 
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/1916554

Title:
  Cirrus Audio Codec CS8409/CS42L42 support

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem-5.10 package in Ubuntu:
  Invalid
Status in linux source package in Focal:
  Invalid
Status in linux-oem-5.10 source package in Focal:
  Fix Committed
Status in linux source package in Hirsute:
  In Progress
Status in linux-oem-5.10 source package in Hirsute:
  Invalid

Bug description:
  [SRU Justification]

  [Impact]

  No driver for Cirrus CS8409 HDA bridge/CS42L42 codec, no
  playback/capture device available.

  [Fix]

  Patchset
  
https://lore.kernel.org/alsa-devel/20210306111934.4832-1-vita...@opensource.cirrus.com/
  currently in
  https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git branch
  for-next.

  [Test Case]

  On platform with Cirrus CS8409 HDA bridge:

/sys/class/sound/card0/device/$ cat hdaudioC0D0/vendor_*
0x10138409
Cirrus Logic
/sys/class/sound/card0/device/$ cat hdaudioC0D0/chip_name
Generic

  Its chip_name should be updated with correct model name and sound system
  should be working:

/sys/class/sound/card0/device/$ cat hdaudioC0D0/chip_name
CS8409/CS42L42

  APLAY and ARECORD should also list new audio devices:

 List of PLAYBACK Hardware Devices 
card 0: PCH [HDA Intel PCH], device 0: CS8409/CS42L42 Analog 
[CS8409/CS42L42 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

 List of CAPTURE Hardware Devices 
card 0: PCH [HDA Intel PCH], device 0: CS8409/CS42L42 Analog
[CS8409/CS42L42 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

  [Where problems could occur]

  New device driver landing, may bring in new issues bound to new
  driver/device configuration such as suspend/resume issues.

  == original bug description ==

  $ sudo dmesg|grep hda
  [   19.253994] snd_hda_intel :00:1f.3: enabling device ( -> 0002)
  [   19.254515] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
  [   19.317386] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: 
line_outs=1 (0x2c/0x0/0x0/0x0/0x0) type:speaker
  [   19.317390] snd_hda_codec_generic hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
  [   19.317392] snd_hda_codec_generic hdaudioC0D0:hp_outs=1 
(0x24/0x0/0x0/0x0/0x0)
  [   19.317393] snd_hda_codec_generic hdaudioC0D0:mono: mono_out=0x0
  [   19.317395] snd_hda_codec_generic hdaudioC0D0:inputs:
  [   19.317397] snd_hda_codec_generic hdaudioC0D0:  Internal Mic=0x44
  [   19.317399] snd_hda_codec_generic hdaudioC0D0:  Mic=0x34

  Vendor driver in progress: 
https://github.com/CirrusLogic/product-support/tree/cs8409_hda
  Upstream submission: 
https://patchwork.kernel.org/project/alsa-devel/list/?series=441331

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-5.10.0-1013-oem 5.10.0-1013.14
  ProcVersionSignature: Ubuntu 5.10.0-1013.14-oem 5.10.6
  Uname: Linux 5.10.0-1013-oem x86_64
  ApportVersion: 2.20.11-0ubuntu27.14
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Mon Feb 22 22:13:32 2021
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-focal-amd64-20200502-85+fossa-beric-icl+X44
  InstallationDate: Installed on 2021-02-04 (18 days ago)
  InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 
20200502-05:58
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: linux-signed-oem-5.10
  UpgradeStatus: No upgrade log present (probably fresh install)
  ---
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu27.14
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  1673 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-focal-amd64-20200502-85+fossa-beric-icl+X44
  DistroRelease: Ubuntu 20.04
  InstallationDate: Installed on 2021-02-04 (18 days ago)
  InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 
20200502-05:58
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 0c45:671e Microdia Integrated_Webcam_HD
   Bus 001 Device 003: ID 8087:0aaa Intel Corp.
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. Inspiron 3501
  Package:

[Kernel-packages] [Bug 1918847] Re: Using Wacom stylus on screen causes system lockup

2021-03-18 Thread Rahul

** Changed in: linux (Ubuntu)
   Status: Confirmed => Fix Released

-- 
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/1918847

Title:
  Using Wacom stylus on screen causes system lockup

Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Machine: Lenovo Thinkpad Yoga L13 model 20R5S02B00
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04

  On current hirsute, using 5.10.0-14-generic or 5.10.0-14-lowlatency,
  bringing the included Wacom pen to the screen causes an instant
  lockup.  There is no solution except hard power off.  It is 100%
  reproducible.

  The last message in syslog before this freeze / force reboot seems to
  be "rfkill: input handler enabled".

  This doesn't happen with upstream kernel 5.11.0-051100-generic or with
  the 5.8 kernel 5.8.0-44-generic from groovy.

  I am happy to give further information.

  UPDATE 2021-03-18: with the hirsute kernel update to 5.11.0.11 the bug
  has gone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1918847/+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

Re: [Kernel-packages] [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected

2021-03-18 Thread Ryan Harper

* dann frazier <1918...@bugs.launchpad.net> [2021-03-18 12:11]:
> On Thu, Mar 18, 2021 at 10:25 AM Ryan Harper <1918...@bugs.launchpad.net> 
> wrote:
> >
> > * dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:30]:
> > > On Tue, Mar 16, 2021 at 10:05 AM Ryan Harper <1918...@bugs.launchpad.net> 
> > > wrote:
> > > >
> > > > Hi Dan,
> > > >
> > >
> > > 1) flash-kernel could get installed post-divert. In that case,
> > > flash-kernel's own postinst will cause it to run and then fail. This
> > > happens today if you start with a cloud image w/o flash-kernel
> > > pre-baked because Ubuntu's kernel recommends flash-kernel, causing it
> > > to be installed along with the kernel. Official cloud images happen to
> >
> > Hrm, so if we take a squashfs rootfs (with no flash-kernel present)
> > chroot into it and install the linux-image-generic package pulling in
> > flash-kernel this fails due to postinst of flash-kernel expecting
> > initramfs to already be generated?  This doesn't seem like a curtin bug.
> 
> If done so in a chroot that exposes the kernel interfaces (/proc &
> /sys) that claim to be hardware that requires the initramfs to be
> post-processed, yes.

Maybe I'm missing something but if I install linux-image-generic
it populates /boot with vmlinuz-$version (and a few more things)
and /lib/modules/$version  and the kernels postinst will invoke
update-initramfs.  The /boot/initrd.img-$version is *generated* at
that time during the kernel's postinstall

Now, in the arm case IIUC, the kernel package has a dep on flash-kernel
being present as it's "needed" to generate the initramfs ... so how can
flash-kernel's postinst *fail* if it is the tool that's generating said
initramfs file?

> > In summary curtin will need:
> >
> > move ephemeral deps.py flash-kernel to arch-packages in
> > install-missing-packages with the same logic guarding when to add the
> > dep.
> >
> > It's not clear to me why curtin should work around the packaging bugs
> > around flash-kernel and I would suggest that flash-kernel be kept in the
> > cloud images until the packging deps/bugs around it are fixed.
> 
> I don't think it should - we should SRU Date's f-k change and the
> kernel Recommends change. Are there other packaging issues you've
> identified?

I don't think possibly something flash-kernel related to the above
discussion but that may just be my own misinformation.

-- 
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/1918427

Title:
  curtin: install flash-kernel in arm64 UEFI unexpected

Status in cloud-images:
  Confirmed
Status in curtin package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  In Progress

Bug description:
  I used APM Mustang which flash-kernel supported in u-boot mode.
  But I used it with UEFI environment.
  It will cause fatal error when I used ARM64 ubuntu live server ISO to install 
system.

  In code[1], this will not install `flash-kernel` for APM Mustang because of 
UEFI.
  So that means code[2] will not disable `flash-kernel` in target system, only 
disable `update-initramfs`.

  When curtin execute to `install_kernel` stage, code[3,4] will not install 
`flash-kernel` either.
  But in code[5], it will install `linux-generic`.
  `linux-generic` has a long dependency tree and it will get `flash-kernel` in 
Recommended field.
  Apt by default will install Recommended package before kernel is installed.[6]
  So it will still execute `zz-flash-kernel` and `flash-kernel` when installing 
kernel.
  But system didn't create any `initrd.img` ever because curtin disable 
`update-initramfs` in code[2].
  This will cause that `flash-kernel` cannot find `initrd.img.` and fail 
when installing it.

  This issue didn't effect all ARM64 UEFI platform because `flash-kernel` 
didn't support them and skip.[7]
  I'm not sure which is best solution for this.
  But I think we should apply PR-27 in `flash-kernel`[8] for enhancement and 
fix curtin process with this patch both.

  If we only apply PR-27, it should work fine as well because it will be 
skipped when detecting UEFI
  and install `flash-kernel` before `disable_update_initranfs` in ARM platform 
without UEFI.[9]

  [Patch-1,2,3] might have side effect.
  Picking one patch for curtin should be enough.
  But I need your advice for this to determine which one is better for curtin.
  There are two categories
  1. avoid installing flash-kernel if no need, [Patch1,2]
  2. always install flash-kernel in arm/arm64 and make sure it be installed 
before code[2] [Patch3]
  (I will attach patch in reply.)

  Thanks a lot
  Regards,
  Date

  [1] 
https://github.com/canonical/curtin/blob/master/curtin/deps/__init__.py#L57-L58
  [2] 
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L1693-L1699
  [3] 
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L365-L370
  [4]

[Kernel-packages] [Bug 1901089] Re: Ubuntu kernels 5.4.0-51 and 5.4.0-52 break ir-keytable loading

2021-03-18 Thread Wes Newell

Well, I run newer kernels from the ppa as my main kernel. Currently
running 5.11.3, so it's not a problem for me. As long as whomever does
the distribution kernels keep using old base kernels, the problem will
never be fixed. If you want to run a distribution kernel, then you
should go back to 5.4.0-48. It works.

-- 
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/1901089

Title:
  Ubuntu kernels 5.4.0-51 and 5.4.0-52 break ir-keytable loading

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I run mythtv on Ubuntu 20.04 and I used a custom remote control keymap
  in /etc/rc_keymaps to correctly map buttons on my IR remote.  The
  above kernel seems to break custom keymap loading for my remote
  (certain buttons no longer work in mythtv).  Reverting to kernel
  5.4.0-48 corrects the problem.

  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  linux-image-5.4.0-52-generic:
Installed: 5.4.0-52.57
Candidate: 5.4.0-52.57
Version table:
   *** 5.4.0-52.57 500
  500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu focal-security/main amd64 
Packages
  100 /var/lib/dpkg/status

  belongs to the linux source package

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-5.4.0-52-generic 5.4.0-52.57
  ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60
  Uname: Linux 5.4.0-48-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.10
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  pdaniel1552 F pulseaudio
   /dev/snd/controlC0:  pdaniel1552 F pulseaudio
  CasperMD5CheckResult: skip
  Date: Thu Oct 22 16:16:58 2020
  InstallationDate: Installed on 2017-04-17 (1284 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  MachineType: MSI MS-7792
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 radeondrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-48-generic 
root=UUID=38b7dfb0-9848-4919-890b-fdc027e936f1 ro radeon.dpm=0 quiet splash 
vt.handoff=7
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions:
   linux-restricted-modules-5.4.0-48-generic N/A
   linux-backports-modules-5.4.0-48-generic  N/A
   linux-firmware1.187.3
  SourcePackage: linux
  UpgradeStatus: Upgraded to focal on 2020-05-11 (164 days ago)
  dmi.bios.date: 02/12/2015
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: V2.4
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: FM2-A75IA-E53 (MS-7792)
  dmi.board.vendor: MSI
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrV2.4:bd02/12/2015:svnMSI:pnMS-7792:pvr1.0:rvnMSI:rnFM2-A75IA-E53(MS-7792):rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: MS-7792
  dmi.product.sku: To be filled by O.E.M.
  dmi.product.version: 1.0
  dmi.sys.vendor: MSI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1901089/+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 1900663] Re: Re-enable memory cgroups

This bug was fixed in the package linux-raspi - 5.11.0-1003.3

---
linux-raspi (5.11.0-1003.3) hirsute; urgency=medium

  * hirsute/linux-raspi: 5.11.0-1003.3 -proposed tracker (LP: #1917734)

  * Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf

  * Miscellaneous Ubuntu changes
- [Packaging] raspi: Initial version of linux-raspi for Hirsute
- [Config] raspi: updateconfigs after rebase to Ubuntu-5.11.0-11.12
- [Packaging] raspi: Set disable_d_i=true in hooks.mk
- [Packaging] raspi: Add dctrl-tools to Build-Depends
- [Packaging] raspi: Correctly implement noudeb build profiles
- [Packaging] raspi: remove Provides: aufs-dkms

  [ Ubuntu: 5.11.0-11.12 ]

  * hirsute/linux: 5.11.0-11.12 -proposed tracker (LP: #1917335)
  * Packaging resync (LP: #1786013)
- update dkms package versions
- [Packaging] update variants
  * Support no udeb profile (LP: #1916095)
- [Packaging] replace custom filter script with dctrl-tools
- [Packaging] correctly implement noudeb build profiles.
  * Miscellaneous Ubuntu changes
- [Packaging] dkms-versions -- remove nvidia-graphics-drivers-440-server
- [Debian] run ubuntu-regression-suite for linux-unstable
- [Packaging] remove Provides: aufs-dkms
- [Packaging] Change source package name to linux
- [Config] update gcc version in config due to toolchain update
  * Miscellaneous upstream changes
- Revert "UBUNTU: [Config] disable nvidia and nvidia_server builds"
- Xen/x86: don't bail early from clear_foreign_p2m_mapping()
- Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
- Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
- Xen/gntdev: correct error checking in gntdev_map_grant_pages()
- xen/arm: don't ignore return errors from set_phys_to_machine
- xen-blkback: don't "handle" error by BUG()
- xen-netback: don't "handle" error by BUG()
- xen-scsiback: don't "handle" error by BUG()
- xen-blkback: fix error handling in xen_blkbk_map()
- tty: protect tty_write from odd low-level tty disciplines
- Bluetooth: btusb: Always fallback to alt 1 for WBS
- media: pwc: Use correct device for DMA
- bpf: Fix truncation handling for mod32 dst reg wrt zero
- HID: make arrays usage and value to be the same
- USB: quirks: sort quirk entries
- usb: quirks: add quirk to start video capture on ELMO L-12F document 
camera
  reliable
- ntfs: check for valid standard information attribute
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
- arm64: tegra: Add power-domain for Tegra210 HDA
- hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist
- KVM: x86: Zap the oldest MMU pages, not the newest
- KVM: do not assume PTE is writable after follow_pfn
- mm: provide a saner PTE walking API for modules
- KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped()

 -- Juerg Haefliger   Thu, 04 Mar 2021 14:42:19
+0100

** Changed in: linux-raspi (Ubuntu Hirsute)
   Status: In Progress => Fix Released

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

Title:
  Re-enable memory cgroups

Status in linux-raspi package in Ubuntu:
  Fix Released
Status in linux-raspi source package in Focal:
  Confirmed
Status in linux-raspi source package in Groovy:
  Confirmed
Status in linux-raspi source package in Hirsute:
  Fix Released

Bug description:
  Currently, the 5.4 and 5.8 raspi kernels disable the memory cgroup by
  default to conserve memory [1]. This is a legacy custom modification,
  that is no longer needed, since the memory cgroup code has been
  rewritten to no longer requires large amounts of memory [2]. So the
  custom patch can be dropped. The patch is also the reason why the LXC
  ADT test fails.

  [1] 
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-raspi/+git/focal/commit/?id=64e543b88ea2a013e1d8e014e7c92c53df1322ed
  [2] 
https://github.com/torvalds/linux/commit/1306a85aed3ec3db98945aafb7dfbe5648a1203c

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1900663/+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 1907432] Re: Raspberry Pi 400 Kernel Panic

This bug was fixed in the package linux-raspi - 5.11.0-1003.3

---
linux-raspi (5.11.0-1003.3) hirsute; urgency=medium

  * hirsute/linux-raspi: 5.11.0-1003.3 -proposed tracker (LP: #1917734)

  * Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf

  * Miscellaneous Ubuntu changes
- [Packaging] raspi: Initial version of linux-raspi for Hirsute
- [Config] raspi: updateconfigs after rebase to Ubuntu-5.11.0-11.12
- [Packaging] raspi: Set disable_d_i=true in hooks.mk
- [Packaging] raspi: Add dctrl-tools to Build-Depends
- [Packaging] raspi: Correctly implement noudeb build profiles
- [Packaging] raspi: remove Provides: aufs-dkms

  [ Ubuntu: 5.11.0-11.12 ]

  * hirsute/linux: 5.11.0-11.12 -proposed tracker (LP: #1917335)
  * Packaging resync (LP: #1786013)
- update dkms package versions
- [Packaging] update variants
  * Support no udeb profile (LP: #1916095)
- [Packaging] replace custom filter script with dctrl-tools
- [Packaging] correctly implement noudeb build profiles.
  * Miscellaneous Ubuntu changes
- [Packaging] dkms-versions -- remove nvidia-graphics-drivers-440-server
- [Debian] run ubuntu-regression-suite for linux-unstable
- [Packaging] remove Provides: aufs-dkms
- [Packaging] Change source package name to linux
- [Config] update gcc version in config due to toolchain update
  * Miscellaneous upstream changes
- Revert "UBUNTU: [Config] disable nvidia and nvidia_server builds"
- Xen/x86: don't bail early from clear_foreign_p2m_mapping()
- Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
- Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
- Xen/gntdev: correct error checking in gntdev_map_grant_pages()
- xen/arm: don't ignore return errors from set_phys_to_machine
- xen-blkback: don't "handle" error by BUG()
- xen-netback: don't "handle" error by BUG()
- xen-scsiback: don't "handle" error by BUG()
- xen-blkback: fix error handling in xen_blkbk_map()
- tty: protect tty_write from odd low-level tty disciplines
- Bluetooth: btusb: Always fallback to alt 1 for WBS
- media: pwc: Use correct device for DMA
- bpf: Fix truncation handling for mod32 dst reg wrt zero
- HID: make arrays usage and value to be the same
- USB: quirks: sort quirk entries
- usb: quirks: add quirk to start video capture on ELMO L-12F document 
camera
  reliable
- ntfs: check for valid standard information attribute
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
- arm64: tegra: Add power-domain for Tegra210 HDA
- hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist
- KVM: x86: Zap the oldest MMU pages, not the newest
- KVM: do not assume PTE is writable after follow_pfn
- mm: provide a saner PTE walking API for modules
- KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped()

 -- Juerg Haefliger   Thu, 04 Mar 2021 14:42:19
+0100

** Changed in: linux-raspi (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  Raspberry Pi 400 Kernel Panic

Status in linux-raspi package in Ubuntu:
  Fix Released
Status in linux-raspi source package in Groovy:
  Fix Released

Bug description:
  When I power the Pi 400 down (with the key-combination on the pi 400
  or with the navigation from the top right), a line like this is on
  screen:

  [59095.049506] reboot: Power down

  or that:
  [25784.810857] reboot: Power down

  Under this line, the cursor is frozen.
  After a while, suddenly, the text scrolls and stops after a while. I can read 
something about "Kernel Panic" on screen.

  I cannot power the device off. I have to pull the power plug to shut
  it down, or to re-plug it to reset it. The power-button (2sec) does
  not work, 10 seconds reset signal, neither.

  Here you can find my initial question to this phenomenon:
  https://answers.launchpad.net/ubuntu/+question/694349

  This I should include:
  Linux version 5.8.0-1008-raspi (buildd@bos02-arm64-062) (gcc (Ubuntu 
10.2.0-13ubuntu1) 10.2.0, GNU ld (GNU Binutils for Ubuntu) 2.35.1) #11-Ubuntu 
SMP PREEMPT Thu Nov 12 15:49:32 UTC 2020

  I hope this report includes enough information. If not, please do not
  hesitate to contact me! Thanks so much for this project and thx for
  being a part of it! <3

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: linux-image-5.8.0-1008-raspi 5.8.0-1008.11
  ProcVersionSignature: Ubuntu 5.8.0-1008.11-raspi 5.8.17
  Uname: Linux 5.8.0-1008-raspi aarch64
  ApportVersion: 2.20.11-0ubuntu50.2
  Architecture: arm64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Dec  9 10:40:08 2020
  ImageMediaBuild: 20201022
  SourcePackage: linux-raspi
  UpgradeStatus: No

[Kernel-packages] [Bug 1865566] Re: Large Page support disabled on Raspberry Pi kernels

This bug was fixed in the package linux-raspi - 5.11.0-1003.3

---
linux-raspi (5.11.0-1003.3) hirsute; urgency=medium

  * hirsute/linux-raspi: 5.11.0-1003.3 -proposed tracker (LP: #1917734)

  * Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf

  * Miscellaneous Ubuntu changes
- [Packaging] raspi: Initial version of linux-raspi for Hirsute
- [Config] raspi: updateconfigs after rebase to Ubuntu-5.11.0-11.12
- [Packaging] raspi: Set disable_d_i=true in hooks.mk
- [Packaging] raspi: Add dctrl-tools to Build-Depends
- [Packaging] raspi: Correctly implement noudeb build profiles
- [Packaging] raspi: remove Provides: aufs-dkms

  [ Ubuntu: 5.11.0-11.12 ]

  * hirsute/linux: 5.11.0-11.12 -proposed tracker (LP: #1917335)
  * Packaging resync (LP: #1786013)
- update dkms package versions
- [Packaging] update variants
  * Support no udeb profile (LP: #1916095)
- [Packaging] replace custom filter script with dctrl-tools
- [Packaging] correctly implement noudeb build profiles.
  * Miscellaneous Ubuntu changes
- [Packaging] dkms-versions -- remove nvidia-graphics-drivers-440-server
- [Debian] run ubuntu-regression-suite for linux-unstable
- [Packaging] remove Provides: aufs-dkms
- [Packaging] Change source package name to linux
- [Config] update gcc version in config due to toolchain update
  * Miscellaneous upstream changes
- Revert "UBUNTU: [Config] disable nvidia and nvidia_server builds"
- Xen/x86: don't bail early from clear_foreign_p2m_mapping()
- Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
- Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
- Xen/gntdev: correct error checking in gntdev_map_grant_pages()
- xen/arm: don't ignore return errors from set_phys_to_machine
- xen-blkback: don't "handle" error by BUG()
- xen-netback: don't "handle" error by BUG()
- xen-scsiback: don't "handle" error by BUG()
- xen-blkback: fix error handling in xen_blkbk_map()
- tty: protect tty_write from odd low-level tty disciplines
- Bluetooth: btusb: Always fallback to alt 1 for WBS
- media: pwc: Use correct device for DMA
- bpf: Fix truncation handling for mod32 dst reg wrt zero
- HID: make arrays usage and value to be the same
- USB: quirks: sort quirk entries
- usb: quirks: add quirk to start video capture on ELMO L-12F document 
camera
  reliable
- ntfs: check for valid standard information attribute
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
- arm64: tegra: Add power-domain for Tegra210 HDA
- hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist
- KVM: x86: Zap the oldest MMU pages, not the newest
- KVM: do not assume PTE is writable after follow_pfn
- mm: provide a saner PTE walking API for modules
- KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped()

 -- Juerg Haefliger   Thu, 04 Mar 2021 14:42:19
+0100

** Changed in: linux-raspi (Ubuntu Hirsute)
   Status: Confirmed => Fix Released

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

Title:
  Large Page support disabled on Raspberry Pi kernels

Status in linux-raspi package in Ubuntu:
  Fix Released
Status in linux-raspi2 source package in Focal:
  Won't Fix
Status in linux-raspi source package in Groovy:
  Won't Fix
Status in linux-raspi source package in Hirsute:
  Fix Released

Bug description:
  It appears that large page support and transparent hugepages are
  disabled in config on the Raspberry Pi. It would be nice if they were
  enabled in the kernel configuration, even if they are disabled by
  default. Then they could be set in user-editable config via the
  "transparent_hugepage" boot option.

  With 4GB hardware in this family, there might be valid uses for large
  pages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1865566/+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 1890487] Re: rpi3b+ wifi doesn't get used if ethernet disconnected

This bug was fixed in the package linux-raspi - 5.11.0-1003.3

---
linux-raspi (5.11.0-1003.3) hirsute; urgency=medium

  * hirsute/linux-raspi: 5.11.0-1003.3 -proposed tracker (LP: #1917734)

  * Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf

  * Miscellaneous Ubuntu changes
- [Packaging] raspi: Initial version of linux-raspi for Hirsute
- [Config] raspi: updateconfigs after rebase to Ubuntu-5.11.0-11.12
- [Packaging] raspi: Set disable_d_i=true in hooks.mk
- [Packaging] raspi: Add dctrl-tools to Build-Depends
- [Packaging] raspi: Correctly implement noudeb build profiles
- [Packaging] raspi: remove Provides: aufs-dkms

  [ Ubuntu: 5.11.0-11.12 ]

  * hirsute/linux: 5.11.0-11.12 -proposed tracker (LP: #1917335)
  * Packaging resync (LP: #1786013)
- update dkms package versions
- [Packaging] update variants
  * Support no udeb profile (LP: #1916095)
- [Packaging] replace custom filter script with dctrl-tools
- [Packaging] correctly implement noudeb build profiles.
  * Miscellaneous Ubuntu changes
- [Packaging] dkms-versions -- remove nvidia-graphics-drivers-440-server
- [Debian] run ubuntu-regression-suite for linux-unstable
- [Packaging] remove Provides: aufs-dkms
- [Packaging] Change source package name to linux
- [Config] update gcc version in config due to toolchain update
  * Miscellaneous upstream changes
- Revert "UBUNTU: [Config] disable nvidia and nvidia_server builds"
- Xen/x86: don't bail early from clear_foreign_p2m_mapping()
- Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
- Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
- Xen/gntdev: correct error checking in gntdev_map_grant_pages()
- xen/arm: don't ignore return errors from set_phys_to_machine
- xen-blkback: don't "handle" error by BUG()
- xen-netback: don't "handle" error by BUG()
- xen-scsiback: don't "handle" error by BUG()
- xen-blkback: fix error handling in xen_blkbk_map()
- tty: protect tty_write from odd low-level tty disciplines
- Bluetooth: btusb: Always fallback to alt 1 for WBS
- media: pwc: Use correct device for DMA
- bpf: Fix truncation handling for mod32 dst reg wrt zero
- HID: make arrays usage and value to be the same
- USB: quirks: sort quirk entries
- usb: quirks: add quirk to start video capture on ELMO L-12F document 
camera
  reliable
- ntfs: check for valid standard information attribute
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
- arm64: tegra: Add power-domain for Tegra210 HDA
- hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist
- KVM: x86: Zap the oldest MMU pages, not the newest
- KVM: do not assume PTE is writable after follow_pfn
- mm: provide a saner PTE walking API for modules
- KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped()

 -- Juerg Haefliger   Thu, 04 Mar 2021 14:42:19
+0100

** Changed in: linux-raspi (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  rpi3b+ wifi doesn't get used if ethernet disconnected

Status in linux-raspi package in Ubuntu:
  Fix Released
Status in linux-raspi source package in Focal:
  Fix Released
Status in linux-raspi source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  When testing 20.04.1, I noticed some different behavior on rpi3b+ that
  I didn't see on rpi3b or rpi4.  I have configured the device with
  ethernet, added netplan yaml for my wifi network, and rebooted. So
  both eth0 and wlan0 have an ip address.

  On all other devices (rpi3b, rpi4, etc), if I unplug eth0 wile pinging
  something, I'll miss maybe 1 ping and then it will continue to work
  and just switch over to wlan0.  However, on rpi3b+ it just stops being
  able to access the network completely.  If I re-run netplan apply, it
  will start using wifi again, but if I plug eth0 back in, then unplug
  it, it stops just like before.

  I am seeing this with the current 20.04.1 release:
  Linux ubuntu 5.4.0-1015-raspi #15-Ubuntu SMP Fri Jul 10 05:34:24 UTC 2020 
aarch64 aarch64 aarch64 GNU/Linux

  I also went back and tested the original 20.04 release and it happens there 
too, so this is not a regression:
  Linux ubuntu 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 
aarch64 aarch64 aarch64 GNU/Linux

  I see this happen on both armhf and arm64. One difference I did note, is that 
I get a link down message in dmesg on rpi3b, but not rpi3b+.  When I disconnect 
eth0 on rpi3b I see this:
  [   82.203702] smsc95xx 1-1.1:1.0 eth0: link down

  ...but nothing on the 3b+.

  [Test Case]

  Disconnect and reconnect the eth0 cable. The link will not come back
  up. Or down eth0 and bring it

[Kernel-packages] [Bug 1914013] Re: linux-raspi: Build compressed arm64 kernel images

This bug was fixed in the package linux-raspi - 5.11.0-1003.3

---
linux-raspi (5.11.0-1003.3) hirsute; urgency=medium

  * hirsute/linux-raspi: 5.11.0-1003.3 -proposed tracker (LP: #1917734)

  * Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf

  * Miscellaneous Ubuntu changes
- [Packaging] raspi: Initial version of linux-raspi for Hirsute
- [Config] raspi: updateconfigs after rebase to Ubuntu-5.11.0-11.12
- [Packaging] raspi: Set disable_d_i=true in hooks.mk
- [Packaging] raspi: Add dctrl-tools to Build-Depends
- [Packaging] raspi: Correctly implement noudeb build profiles
- [Packaging] raspi: remove Provides: aufs-dkms

  [ Ubuntu: 5.11.0-11.12 ]

  * hirsute/linux: 5.11.0-11.12 -proposed tracker (LP: #1917335)
  * Packaging resync (LP: #1786013)
- update dkms package versions
- [Packaging] update variants
  * Support no udeb profile (LP: #1916095)
- [Packaging] replace custom filter script with dctrl-tools
- [Packaging] correctly implement noudeb build profiles.
  * Miscellaneous Ubuntu changes
- [Packaging] dkms-versions -- remove nvidia-graphics-drivers-440-server
- [Debian] run ubuntu-regression-suite for linux-unstable
- [Packaging] remove Provides: aufs-dkms
- [Packaging] Change source package name to linux
- [Config] update gcc version in config due to toolchain update
  * Miscellaneous upstream changes
- Revert "UBUNTU: [Config] disable nvidia and nvidia_server builds"
- Xen/x86: don't bail early from clear_foreign_p2m_mapping()
- Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
- Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
- Xen/gntdev: correct error checking in gntdev_map_grant_pages()
- xen/arm: don't ignore return errors from set_phys_to_machine
- xen-blkback: don't "handle" error by BUG()
- xen-netback: don't "handle" error by BUG()
- xen-scsiback: don't "handle" error by BUG()
- xen-blkback: fix error handling in xen_blkbk_map()
- tty: protect tty_write from odd low-level tty disciplines
- Bluetooth: btusb: Always fallback to alt 1 for WBS
- media: pwc: Use correct device for DMA
- bpf: Fix truncation handling for mod32 dst reg wrt zero
- HID: make arrays usage and value to be the same
- USB: quirks: sort quirk entries
- usb: quirks: add quirk to start video capture on ELMO L-12F document 
camera
  reliable
- ntfs: check for valid standard information attribute
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
- arm64: tegra: Add power-domain for Tegra210 HDA
- hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist
- KVM: x86: Zap the oldest MMU pages, not the newest
- KVM: do not assume PTE is writable after follow_pfn
- mm: provide a saner PTE walking API for modules
- KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped()

 -- Juerg Haefliger   Thu, 04 Mar 2021 14:42:19
+0100

** Changed in: linux-raspi (Ubuntu Hirsute)
   Status: In Progress => Fix Released

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

Title:
  linux-raspi: Build compressed arm64 kernel images

Status in linux-raspi package in Ubuntu:
  Fix Released
Status in linux-raspi source package in Hirsute:
  Fix Released

Bug description:
  The Raspberry Pi firmware can now handle compressed arm6 kernels, so
  build them as such to save some disk space.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1914013/+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 1903541] Re: groovy/linux-raspi: Upstream raspberrypi patchset 2020-11-05

This bug was fixed in the package linux-raspi - 5.11.0-1003.3

---
linux-raspi (5.11.0-1003.3) hirsute; urgency=medium

  * hirsute/linux-raspi: 5.11.0-1003.3 -proposed tracker (LP: #1917734)

  * Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf

  * Miscellaneous Ubuntu changes
- [Packaging] raspi: Initial version of linux-raspi for Hirsute
- [Config] raspi: updateconfigs after rebase to Ubuntu-5.11.0-11.12
- [Packaging] raspi: Set disable_d_i=true in hooks.mk
- [Packaging] raspi: Add dctrl-tools to Build-Depends
- [Packaging] raspi: Correctly implement noudeb build profiles
- [Packaging] raspi: remove Provides: aufs-dkms

  [ Ubuntu: 5.11.0-11.12 ]

  * hirsute/linux: 5.11.0-11.12 -proposed tracker (LP: #1917335)
  * Packaging resync (LP: #1786013)
- update dkms package versions
- [Packaging] update variants
  * Support no udeb profile (LP: #1916095)
- [Packaging] replace custom filter script with dctrl-tools
- [Packaging] correctly implement noudeb build profiles.
  * Miscellaneous Ubuntu changes
- [Packaging] dkms-versions -- remove nvidia-graphics-drivers-440-server
- [Debian] run ubuntu-regression-suite for linux-unstable
- [Packaging] remove Provides: aufs-dkms
- [Packaging] Change source package name to linux
- [Config] update gcc version in config due to toolchain update
  * Miscellaneous upstream changes
- Revert "UBUNTU: [Config] disable nvidia and nvidia_server builds"
- Xen/x86: don't bail early from clear_foreign_p2m_mapping()
- Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
- Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
- Xen/gntdev: correct error checking in gntdev_map_grant_pages()
- xen/arm: don't ignore return errors from set_phys_to_machine
- xen-blkback: don't "handle" error by BUG()
- xen-netback: don't "handle" error by BUG()
- xen-scsiback: don't "handle" error by BUG()
- xen-blkback: fix error handling in xen_blkbk_map()
- tty: protect tty_write from odd low-level tty disciplines
- Bluetooth: btusb: Always fallback to alt 1 for WBS
- media: pwc: Use correct device for DMA
- bpf: Fix truncation handling for mod32 dst reg wrt zero
- HID: make arrays usage and value to be the same
- USB: quirks: sort quirk entries
- usb: quirks: add quirk to start video capture on ELMO L-12F document 
camera
  reliable
- ntfs: check for valid standard information attribute
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
- arm64: tegra: Add power-domain for Tegra210 HDA
- hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist
- KVM: x86: Zap the oldest MMU pages, not the newest
- KVM: do not assume PTE is writable after follow_pfn
- mm: provide a saner PTE walking API for modules
- KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped()

 -- Juerg Haefliger   Thu, 04 Mar 2021 14:42:19
+0100

** Changed in: linux-raspi (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  groovy/linux-raspi: Upstream raspberrypi patchset 2020-11-05

Status in linux-raspi package in Ubuntu:
  Fix Released
Status in linux-raspi source package in Groovy:
  Fix Released

Bug description:
  Upstream raspberrypi patchset 2020-11-05

     Ported from the following raspberrypi branch:
    rpi-5.8.y

  from https://github.com/raspberrypi/linux.git

  ASoC: cros_ec_codec: fix kconfig dependency warning for SND_SOC_CROS_EC_CODEC
  mm/page_owner: change split_page_owner to take a count
  mm: khugepaged: recalculate min_free_kbytes after memory hotplug as expected 
by khugepaged
  mm/error_inject: Fix allow_error_inject function signatures.
  fbmem: add margin check to fb_check_caps()
  xhci: don't create endpoint debugfs entry before ring buffer is set.
  serial: pl011: Fix lockdep splat when handling magic-sysrq interrupt
  media: tc358743: cleanup tc358743_cec_isr
  media: tc358743: initialize variable
  gpiolib: Disable compat ->read() code in UML case
  clk: bcm2835: add missing release if devm_clk_hw_register fails
  Fixes a problem when module probes before i2c module is available
  overlays: Add ghost-amp overlay
  overlays: Add fsm-demo overlay
  configs: Add CONFIG_GPIO_FSM=m
  gpio: Add gpio-fsm driver
  ARM: bcm2711-rpi.dts: Unlock DMA channels 9 & 10
  staging: bcm2835-codec: Replace deprecated V4L2_PIX_FMT_BGR32
  staging: bcm2835-camera: Replace deprecated V4L2_PIX_FMT_BGR32
  arm64: configs: Enable V4L2 test module support
  arm64: configs: Enable Unicam support
  dwc_otg: initialise sched_frame for periodic QHs that were parked
  configs: Restore SND_PCM_OSS=m
  overlays: Add sd3078 to the i2c-rtc overlay
  configs: Add

[Kernel-packages] [Bug 1914015] Re: hirsute/linux-raspi: Upstream raspberrypi patchset 2021-01-23

This bug was fixed in the package linux-raspi - 5.11.0-1003.3

---
linux-raspi (5.11.0-1003.3) hirsute; urgency=medium

  * hirsute/linux-raspi: 5.11.0-1003.3 -proposed tracker (LP: #1917734)

  * Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf

  * Miscellaneous Ubuntu changes
- [Packaging] raspi: Initial version of linux-raspi for Hirsute
- [Config] raspi: updateconfigs after rebase to Ubuntu-5.11.0-11.12
- [Packaging] raspi: Set disable_d_i=true in hooks.mk
- [Packaging] raspi: Add dctrl-tools to Build-Depends
- [Packaging] raspi: Correctly implement noudeb build profiles
- [Packaging] raspi: remove Provides: aufs-dkms

  [ Ubuntu: 5.11.0-11.12 ]

  * hirsute/linux: 5.11.0-11.12 -proposed tracker (LP: #1917335)
  * Packaging resync (LP: #1786013)
- update dkms package versions
- [Packaging] update variants
  * Support no udeb profile (LP: #1916095)
- [Packaging] replace custom filter script with dctrl-tools
- [Packaging] correctly implement noudeb build profiles.
  * Miscellaneous Ubuntu changes
- [Packaging] dkms-versions -- remove nvidia-graphics-drivers-440-server
- [Debian] run ubuntu-regression-suite for linux-unstable
- [Packaging] remove Provides: aufs-dkms
- [Packaging] Change source package name to linux
- [Config] update gcc version in config due to toolchain update
  * Miscellaneous upstream changes
- Revert "UBUNTU: [Config] disable nvidia and nvidia_server builds"
- Xen/x86: don't bail early from clear_foreign_p2m_mapping()
- Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
- Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
- Xen/gntdev: correct error checking in gntdev_map_grant_pages()
- xen/arm: don't ignore return errors from set_phys_to_machine
- xen-blkback: don't "handle" error by BUG()
- xen-netback: don't "handle" error by BUG()
- xen-scsiback: don't "handle" error by BUG()
- xen-blkback: fix error handling in xen_blkbk_map()
- tty: protect tty_write from odd low-level tty disciplines
- Bluetooth: btusb: Always fallback to alt 1 for WBS
- media: pwc: Use correct device for DMA
- bpf: Fix truncation handling for mod32 dst reg wrt zero
- HID: make arrays usage and value to be the same
- USB: quirks: sort quirk entries
- usb: quirks: add quirk to start video capture on ELMO L-12F document 
camera
  reliable
- ntfs: check for valid standard information attribute
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
- arm64: tegra: Add power-domain for Tegra210 HDA
- hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist
- KVM: x86: Zap the oldest MMU pages, not the newest
- KVM: do not assume PTE is writable after follow_pfn
- mm: provide a saner PTE walking API for modules
- KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped()

 -- Juerg Haefliger   Thu, 04 Mar 2021 14:42:19
+0100

** Changed in: linux-raspi (Ubuntu Hirsute)
   Status: In Progress => Fix Released

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

Title:
  hirsute/linux-raspi: Upstream raspberrypi patchset 2021-01-23

Status in linux-raspi package in Ubuntu:
  Fix Released
Status in linux-raspi source package in Hirsute:
  Fix Released

Bug description:
  Upstream raspberrypi patchset 2021-01-23

     Ported from the following raspberrypi branch:
    rpi-5.11.y

  from https://github.com/raspberrypi/linux.git

  configs: Add CRYPTO_ADIANTUM=m
  configs: Regenerate defconfigs
  configs: Add NVMEM_RMEM=m for 2711
  ARM: multi_v7_defconfig: Enable nvmem's rmem driver
  arm64: defconfig: Enable nvmem's rmem driver
  ARM: dts: bcm2711: Add reserved memory template to hold firmware configuration
  nvmem: Add driver to expose reserved memory as nvmem
  dt-bindings: nvmem: Add bindings for rmem driver
  configs: Add CONFIG_USB_NET_AQC111=m
  configs: Add CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
  staging: vc04_services: ISP: Add colour denoise control
  uapi: bcm2835-isp: Add colour denoise configuration
  bcm2835-dma: Add bcm2835-dma: Add DMA_WIDE_SOURCE and DMA_WIDE_DEST flags
  dt: Enable DMA_WIDE_SOURCE and DMA_WIDE_DEST for hdmi audio
  configs: Enable BCM2835 thermal driver in kernel8
  vc4: Correct POS1_SCL for hvs5
  vc4: Correct lbm size and calculation
  overlays: seeed-can-fd-hat: clarify how to identify HAT version
  dtoverlays: Update sensor overlays to use cam1_reg where possible
  dt: Add a camera regulator node to all downstream Pi platforms
  arch/arm: Add __memset alias to memset_rpi.S
  overlays: add spi override to merus-amp overlay
  overlays: add wm8960-soundcard overlay
  overlays: Add overlay for Seeed Studio CAN BUS FD HAT v1 (based on mcp2517fd)
  overlays: give Seeed Studio CAN BUS FD

[Kernel-packages] [Bug 1914033] Re: linux-raspi: Bump max number of CPUs

This bug was fixed in the package linux-raspi - 5.11.0-1003.3

---
linux-raspi (5.11.0-1003.3) hirsute; urgency=medium

  * hirsute/linux-raspi: 5.11.0-1003.3 -proposed tracker (LP: #1917734)

  * Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf

  * Miscellaneous Ubuntu changes
- [Packaging] raspi: Initial version of linux-raspi for Hirsute
- [Config] raspi: updateconfigs after rebase to Ubuntu-5.11.0-11.12
- [Packaging] raspi: Set disable_d_i=true in hooks.mk
- [Packaging] raspi: Add dctrl-tools to Build-Depends
- [Packaging] raspi: Correctly implement noudeb build profiles
- [Packaging] raspi: remove Provides: aufs-dkms

  [ Ubuntu: 5.11.0-11.12 ]

  * hirsute/linux: 5.11.0-11.12 -proposed tracker (LP: #1917335)
  * Packaging resync (LP: #1786013)
- update dkms package versions
- [Packaging] update variants
  * Support no udeb profile (LP: #1916095)
- [Packaging] replace custom filter script with dctrl-tools
- [Packaging] correctly implement noudeb build profiles.
  * Miscellaneous Ubuntu changes
- [Packaging] dkms-versions -- remove nvidia-graphics-drivers-440-server
- [Debian] run ubuntu-regression-suite for linux-unstable
- [Packaging] remove Provides: aufs-dkms
- [Packaging] Change source package name to linux
- [Config] update gcc version in config due to toolchain update
  * Miscellaneous upstream changes
- Revert "UBUNTU: [Config] disable nvidia and nvidia_server builds"
- Xen/x86: don't bail early from clear_foreign_p2m_mapping()
- Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
- Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
- Xen/gntdev: correct error checking in gntdev_map_grant_pages()
- xen/arm: don't ignore return errors from set_phys_to_machine
- xen-blkback: don't "handle" error by BUG()
- xen-netback: don't "handle" error by BUG()
- xen-scsiback: don't "handle" error by BUG()
- xen-blkback: fix error handling in xen_blkbk_map()
- tty: protect tty_write from odd low-level tty disciplines
- Bluetooth: btusb: Always fallback to alt 1 for WBS
- media: pwc: Use correct device for DMA
- bpf: Fix truncation handling for mod32 dst reg wrt zero
- HID: make arrays usage and value to be the same
- USB: quirks: sort quirk entries
- usb: quirks: add quirk to start video capture on ELMO L-12F document 
camera
  reliable
- ntfs: check for valid standard information attribute
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
- arm64: tegra: Add power-domain for Tegra210 HDA
- hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist
- KVM: x86: Zap the oldest MMU pages, not the newest
- KVM: do not assume PTE is writable after follow_pfn
- mm: provide a saner PTE walking API for modules
- KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped()

 -- Juerg Haefliger   Thu, 04 Mar 2021 14:42:19
+0100

** Changed in: linux-raspi (Ubuntu Hirsute)
   Status: In Progress => Fix Released

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

Title:
  linux-raspi: Bump max number of CPUs

Status in linux-raspi package in Ubuntu:
  Fix Released
Status in linux-raspi source package in Hirsute:
  Fix Released

Bug description:
  NR_CPUS=4 is not very forward looking so bump it to match upstream
  raspberrypi and the Ubuntu generic kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1914033/+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 1914009] Re: Disable unsupported features

This bug was fixed in the package linux-raspi - 5.11.0-1003.3

---
linux-raspi (5.11.0-1003.3) hirsute; urgency=medium

  * hirsute/linux-raspi: 5.11.0-1003.3 -proposed tracker (LP: #1917734)

  * Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf

  * Miscellaneous Ubuntu changes
- [Packaging] raspi: Initial version of linux-raspi for Hirsute
- [Config] raspi: updateconfigs after rebase to Ubuntu-5.11.0-11.12
- [Packaging] raspi: Set disable_d_i=true in hooks.mk
- [Packaging] raspi: Add dctrl-tools to Build-Depends
- [Packaging] raspi: Correctly implement noudeb build profiles
- [Packaging] raspi: remove Provides: aufs-dkms

  [ Ubuntu: 5.11.0-11.12 ]

  * hirsute/linux: 5.11.0-11.12 -proposed tracker (LP: #1917335)
  * Packaging resync (LP: #1786013)
- update dkms package versions
- [Packaging] update variants
  * Support no udeb profile (LP: #1916095)
- [Packaging] replace custom filter script with dctrl-tools
- [Packaging] correctly implement noudeb build profiles.
  * Miscellaneous Ubuntu changes
- [Packaging] dkms-versions -- remove nvidia-graphics-drivers-440-server
- [Debian] run ubuntu-regression-suite for linux-unstable
- [Packaging] remove Provides: aufs-dkms
- [Packaging] Change source package name to linux
- [Config] update gcc version in config due to toolchain update
  * Miscellaneous upstream changes
- Revert "UBUNTU: [Config] disable nvidia and nvidia_server builds"
- Xen/x86: don't bail early from clear_foreign_p2m_mapping()
- Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
- Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
- Xen/gntdev: correct error checking in gntdev_map_grant_pages()
- xen/arm: don't ignore return errors from set_phys_to_machine
- xen-blkback: don't "handle" error by BUG()
- xen-netback: don't "handle" error by BUG()
- xen-scsiback: don't "handle" error by BUG()
- xen-blkback: fix error handling in xen_blkbk_map()
- tty: protect tty_write from odd low-level tty disciplines
- Bluetooth: btusb: Always fallback to alt 1 for WBS
- media: pwc: Use correct device for DMA
- bpf: Fix truncation handling for mod32 dst reg wrt zero
- HID: make arrays usage and value to be the same
- USB: quirks: sort quirk entries
- usb: quirks: add quirk to start video capture on ELMO L-12F document 
camera
  reliable
- ntfs: check for valid standard information attribute
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
- arm64: tegra: Add power-domain for Tegra210 HDA
- hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist
- KVM: x86: Zap the oldest MMU pages, not the newest
- KVM: do not assume PTE is writable after follow_pfn
- mm: provide a saner PTE walking API for modules
- KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped()

 -- Juerg Haefliger   Thu, 04 Mar 2021 14:42:19
+0100

** Changed in: linux-raspi (Ubuntu Hirsute)
   Status: In Progress => Fix Released

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

Title:
  Disable unsupported features

Status in linux-raspi package in Ubuntu:
  Fix Released
Status in linux-raspi source package in Groovy:
  Fix Released
Status in linux-raspi source package in Hirsute:
  Fix Released

Bug description:
  Disable features not supported by the Raspberry Pi firmware/hardware:
  - CPU hot plugging
  - Hibernation
  - Suspend to disk

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1914009/+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 1916721] Re: hirsute/linux-raspi: Upstream raspberrypi patchset 2021-02-18

This bug was fixed in the package linux-raspi - 5.11.0-1003.3

---
linux-raspi (5.11.0-1003.3) hirsute; urgency=medium

  * hirsute/linux-raspi: 5.11.0-1003.3 -proposed tracker (LP: #1917734)

  * Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf

  * Miscellaneous Ubuntu changes
- [Packaging] raspi: Initial version of linux-raspi for Hirsute
- [Config] raspi: updateconfigs after rebase to Ubuntu-5.11.0-11.12
- [Packaging] raspi: Set disable_d_i=true in hooks.mk
- [Packaging] raspi: Add dctrl-tools to Build-Depends
- [Packaging] raspi: Correctly implement noudeb build profiles
- [Packaging] raspi: remove Provides: aufs-dkms

  [ Ubuntu: 5.11.0-11.12 ]

  * hirsute/linux: 5.11.0-11.12 -proposed tracker (LP: #1917335)
  * Packaging resync (LP: #1786013)
- update dkms package versions
- [Packaging] update variants
  * Support no udeb profile (LP: #1916095)
- [Packaging] replace custom filter script with dctrl-tools
- [Packaging] correctly implement noudeb build profiles.
  * Miscellaneous Ubuntu changes
- [Packaging] dkms-versions -- remove nvidia-graphics-drivers-440-server
- [Debian] run ubuntu-regression-suite for linux-unstable
- [Packaging] remove Provides: aufs-dkms
- [Packaging] Change source package name to linux
- [Config] update gcc version in config due to toolchain update
  * Miscellaneous upstream changes
- Revert "UBUNTU: [Config] disable nvidia and nvidia_server builds"
- Xen/x86: don't bail early from clear_foreign_p2m_mapping()
- Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
- Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
- Xen/gntdev: correct error checking in gntdev_map_grant_pages()
- xen/arm: don't ignore return errors from set_phys_to_machine
- xen-blkback: don't "handle" error by BUG()
- xen-netback: don't "handle" error by BUG()
- xen-scsiback: don't "handle" error by BUG()
- xen-blkback: fix error handling in xen_blkbk_map()
- tty: protect tty_write from odd low-level tty disciplines
- Bluetooth: btusb: Always fallback to alt 1 for WBS
- media: pwc: Use correct device for DMA
- bpf: Fix truncation handling for mod32 dst reg wrt zero
- HID: make arrays usage and value to be the same
- USB: quirks: sort quirk entries
- usb: quirks: add quirk to start video capture on ELMO L-12F document 
camera
  reliable
- ntfs: check for valid standard information attribute
- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
- arm64: tegra: Add power-domain for Tegra210 HDA
- hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist
- KVM: x86: Zap the oldest MMU pages, not the newest
- KVM: do not assume PTE is writable after follow_pfn
- mm: provide a saner PTE walking API for modules
- KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped()

 -- Juerg Haefliger   Thu, 04 Mar 2021 14:42:19
+0100

** Changed in: linux-raspi (Ubuntu Hirsute)
   Status: Confirmed => Fix Released

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

Title:
  hirsute/linux-raspi: Upstream raspberrypi patchset 2021-02-18

Status in linux-raspi package in Ubuntu:
  Fix Released
Status in linux-raspi source package in Hirsute:
  Fix Released

Bug description:
  Upstream raspberrypi patchset 2021-02-18

     Ported from the following raspberrypi branch:
    rpi-5.11.y

  from https://github.com/raspberrypi/linux.git

  configs: Add various missing IPV6 modules
  overlays: fsm-demo: Ensure all LEDs are turned off
  gpio-fsm: Fix shutdown timeout handling
  gpio-fsm: Show state info in /sys/class/gpio-fsm
  drm/vc4: Change the default DPI format to being 18bpp, not 24.
  dtoverlays: Add an overlay for the VGA666 when used with vc4-kms-v3d
  defconfigs: Add DRM_DISPLAY_CONNECTOR and DRM_SIMPLE_BRIDGE for VGA666
  dt: Add option for dpi without DE and PCLK (for VGA666)
  staging: rpivid: Fix crash when CMA alloc fails
  drm/vc4: Add connector check to trigger mode_change when hdr metadata changes
  drm/vc4: Add HDR metadata property to the VC5 HDMI connectors
  drm: fix HDR static metadata type field numbering
  overlays: Rename gpio-fsm property num-soft-gpios
  gpio-fsm: Rename 'num-soft-gpios' to avoid warning
  Revert "ARM: dts: bcm2711: Add the BSC interrupt controller"
  Partial revert "bcm2711: Disable bsc_intr and aon_intr by default and enable 
in overlay"
  Added hflip and vflip controls to ov9281
  Fixed picture line bug in all ov9281 modes
  bcm2835-isp: Allow formats with different colour spaces.
  Hifiberry DAC+ADC Pro fix for the PLL when changing sample rates
  Added PiFi-Mini to rpi-simple-soundcard.c
  Overlays for PiFi-Mini amp
  staging:bcm2835-camera: Fix the cherry-pick of AWB Greyworld

Re: [Kernel-packages] [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected

On Thu, Mar 18, 2021 at 10:25 AM Ryan Harper <1918...@bugs.launchpad.net> wrote:
>
> * dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:30]:
> > On Tue, Mar 16, 2021 at 10:05 AM Ryan Harper <1918...@bugs.launchpad.net> 
> > wrote:
> > >
> > > Hi Dan,
> > >
> > > Could you summarize the problem with flash-kernel and this system?
> >
> > Sure. flash-kernel recognizes Mustang boards and will generate uImage
> > and uInitrd files for it, which are required for booting with u-boot
> > firmware. However, these boards can also run in UEFI mode, which
> > Date's board does. In UEFI mode, flash-kernel still knows it is on a
> > Mustang and generates uImage/uInitrd files - which won't be used for
> > anything in that case, they are just wasting space, but does not cause
> > it to fail. This does cause problems in a curtin install though.
> > Curtin has logic to divert away tools that get executed during
> > initramfs hooks, to avoid failures in packaging scripts before an
> > initramfs is generated. flash-kernel in particular will fail if an
> > initramfs is not found on this system. Curtin tries to be smart here
> > and only divert flash-kernel 1) if it is installed and 2) on systems
> > that are*not* in UEFI mode, and both of these scenarios have escapes:
> >
> > 1) flash-kernel could get installed post-divert. In that case,
> > flash-kernel's own postinst will cause it to run and then fail. This
> > happens today if you start with a cloud image w/o flash-kernel
> > pre-baked because Ubuntu's kernel recommends flash-kernel, causing it
> > to be installed along with the kernel. Official cloud images happen to
>
> Hrm, so if we take a squashfs rootfs (with no flash-kernel present)
> chroot into it and install the linux-image-generic package pulling in
> flash-kernel this fails due to postinst of flash-kernel expecting
> initramfs to already be generated?  This doesn't seem like a curtin bug.

If done so in a chroot that exposes the kernel interfaces (/proc &
/sys) that claim to be hardware that requires the initramfs to be
post-processed, yes.
I suppose f-k could be taught to detect it is in a chroot, but then
again - depending on what you are building the chroot for - you may
want that post-processing.

> > have flash-kernel pre-baked which avoids this issue. I think curtin
> > should work whether or not the kernel recommends flash-kernel and
> > whether or not curtin is pre-baked (in fact, I'd like for us to stop
> > pre-baking it - the vast majoriy of ARM servers do not need it).
>
> >
> > 2) If flash-kernel is installed, and curtin finds we're in UEFI mode,
> > it chooses not to divert flash-kernel. flash-kernel will therefore run
> > and fail on UEFI Mustangs.
>
> I don't think that's true. The logic for disabling initramfs tools
> always runs regardless of UEFI mode and arch.  See
> curtin/commands/curthooks.py:builtin_curthooks() lines 1692- 1699

oh, you're right. I mistakenly thought it was calling
get_flash_kernel_pkgs(), which returns nothing if EFI is detected.

> >
> > The way I've personally framed this issue is that Ubuntu should not be
> > trying to install flash-kernel on ARM systems that don't require it,
> > which is the reason I've added the various tasks here.
> >  - cloud images shouldn't prebake it
>
> OK
>
> >  - the kernel should allow non-flash-kernel bootloaders to satisfy its
> > recommends
>
> OK
>
> Thanks.  I replied to your later post without seeing this first.
> This helps a lot.

Great!

> >  - curtin shouldn't install flash-kernel on efi-based arm64 servers.
> > It does this today, but - in what seems like a bug, only in the
> > ephemeral and not the target.
>
> Yeah; I suspect flash-kernel being pre-baked into images hid this for
> some time.  As I mentioned in the other reply, I do think that lines
> 57-58 in curtin/deps/__init__.py which bring in flash-kerenl to the
> epheramal can be removed.  And it sounds like we'd move that logic
> instead to the install-missing-packages arch_packages where we ensure
> s390-tools/zipl are install for s390, there we'd add the same logic to
> append flash-kernel where needed for the target OS.

+1, as that appears to be where we install bootloadery things, and
that's how I categorize f-k.

>
> >
> > A separate issue is that flash-kernel should know to just exit if it's
> > running on an EFI system and not bother creating the unused
> > uImage/uInitrd - Date recently got a patched merged into Debian's f-k
> > to do that. That would seemingly also avoid the curtin issues here,
> > but only if we continue to install flash-kernel all the time.
>
> OK.
>
>
> In summary curtin will need:
>
> move ephemeral deps.py flash-kernel to arch-packages in
> install-missing-packages with the same logic guarding when to add the
> dep.
>
> It's not clear to me why curtin should work around the packaging bugs
> around flash-kernel and I would suggest that flash-kernel be kept in the
> cloud images until the packging deps/bugs around it are fixed.

I

Re: [Kernel-packages] [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected

On Thu, Mar 18, 2021 at 10:11 AM Ryan Harper <1918...@bugs.launchpad.net> wrote:
>
> * dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:40]:
> > On Wed, Mar 17, 2021 at 4:56 PM Ryan Harper <1918...@bugs.launchpad.net> 
> > wrote:
> > >
> > > I still don't understand:
> > >
> > > 1) why does which not find flash-kernel if it's present in the ephemeral 
> > > image (meaning it will also be present in the target filesystem
> > > 2) What is the problem with flash-kernel such that you need to 
> > > dpkg-divert it?
> > >
> > > Generally, we do not want to include paths to binaries; we install
> > > Ubuntu and Centos, and possibly other distros which may not have the
> > > same path to this tools so I would like to understand what's not working
> > > to understand why we're hardcoding paths to binaries for dpkg-divert.
> >
> > In my POC patch, it is because we need to divert flash-kernel before
> > it is installed, *just in case* it gets installed as a dependency of
>
> Is flash-kernel supposed to be in the cloud-image or not?

I see no reason for it to be, and I would like to see it removed. For
ARM virtual machines (which I consider, possibly incorrectly, the
primary consumer of cloud images), the only standard way to boot the
kernel-on-disk is booting in EFI mode w/ GRUB.

> Is flash-kernel supposed to be in the target OS or not?

GRUB should be installed on EFI systems. flash-kernel should be
installed on non-EFI systems.
It should be safe to install them both in either case, but one of them
is going to be useless.

> > some other package (in our case it happened due to a kernel Recommends
> > relationship). We therefore can't use `which` to look up the path...
> > unless we continue to always install f-k in the ephemeral for the sole
> > purpose of looking up its path... but that seems to making assumptions
> > as well - i.e. that the ephemeral OS has the same paths as the target
> > OS.
>
> flash-kernel runs in the target OS;  if it's installed in ephemeral
> environment thats a by-product of obtaining tools needed but not present
> in the ephemeral environment.
>
> curtin/deps.py runs to ensure the ephemeral environment has the needed
> tools to create whatever storage configuration curtin supports.
>
> In the squashfs images which do not have a kernel already installed
> curtin will install linux-image-generic to make *additional* kernel
> modules which may not be in the initrd that maas produces available.
> I'm not sure why the maas initrd doesn't yet have zfs kernel modules but
> that's typically the driver of the linux-image-generic install.
>
> w.r.t the dep on flash-kernel, if that is only supposed to run in the
> target image, then I agree we can remove lines 57-58 in
> curtin/dep/__init.py and not install the package (though it may still
> get pulled in via the kernel package install).

OK, agreed. Maybe we start by just ripping that out.

>
> Later durting curthooks stage, curtin will query the *target* os in
> install-missing-packages for expected packages needed in the target OS.
>
> Prior to installing packages in the target OS, curtin does attempt to
> divert initramfs triggering tools to prevent generating the initramfs
> more than once (this happens when we install a kernel package in the
> target OS and either updates or other packages trigger initramfs
> rebuilds).  This is designed around the assumption that the initramfs
> generation tool is present in the image but not tied to the kernel
> pacakge.  For Ubuntu this is initramfs-tools along with some arch
> specific tools.  flash-kernel is the tool used on arm for non-uefi boot.
>
> I see a couple of options but I think I'd like to understand:
>
> 1) when is flash-kernel required?  Curtin current expects flash-kernel
> to be needed when arch is arm and when booting non-uefi.  Is this still
> accurate?

Yes.

> 2) Is flash-kernel always installed in arm cloud images used by maas?

Today it is, but I would like that to stop.

> 3) Is flash-kernel installed by packages due to Recommends when it's not
> needed?  If so, are there packaging bugs that need fixing?

Yes - the kernel. I've fixed that in hirsute (see my previous reply),
and we should probably SRU back to earlier releases.

-- 
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/1918427

Title:
  curtin: install flash-kernel in arm64 UEFI unexpected

Status in cloud-images:
  Confirmed
Status in curtin package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  In Progress

Bug description:
  I used APM Mustang which flash-kernel supported in u-boot mode.
  But I used it with UEFI environment.
  It will cause fatal error when I used ARM64 ubuntu live server ISO to install 
system.

  In code[1], this will not install `flash-kernel` for APM Mustang because of 
UEFI.
  So that means code[2] will not disable `flash-kernel` in target system, only 
disable

[Kernel-packages] [Bug 1901089] Re: Ubuntu kernels 5.4.0-51 and 5.4.0-52 break ir-keytable loading

2021-03-18 Thread Chris

I appreciate that you keep trying to verify that the fix is in place. I
guess I'll continue to use the workaround until I see that you have
confirmed the fix.

-- 
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/1901089

Title:
  Ubuntu kernels 5.4.0-51 and 5.4.0-52 break ir-keytable loading

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I run mythtv on Ubuntu 20.04 and I used a custom remote control keymap
  in /etc/rc_keymaps to correctly map buttons on my IR remote.  The
  above kernel seems to break custom keymap loading for my remote
  (certain buttons no longer work in mythtv).  Reverting to kernel
  5.4.0-48 corrects the problem.

  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  linux-image-5.4.0-52-generic:
Installed: 5.4.0-52.57
Candidate: 5.4.0-52.57
Version table:
   *** 5.4.0-52.57 500
  500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu focal-security/main amd64 
Packages
  100 /var/lib/dpkg/status

  belongs to the linux source package

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-5.4.0-52-generic 5.4.0-52.57
  ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60
  Uname: Linux 5.4.0-48-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.10
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  pdaniel1552 F pulseaudio
   /dev/snd/controlC0:  pdaniel1552 F pulseaudio
  CasperMD5CheckResult: skip
  Date: Thu Oct 22 16:16:58 2020
  InstallationDate: Installed on 2017-04-17 (1284 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  MachineType: MSI MS-7792
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 radeondrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-48-generic 
root=UUID=38b7dfb0-9848-4919-890b-fdc027e936f1 ro radeon.dpm=0 quiet splash 
vt.handoff=7
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions:
   linux-restricted-modules-5.4.0-48-generic N/A
   linux-backports-modules-5.4.0-48-generic  N/A
   linux-firmware1.187.3
  SourcePackage: linux
  UpgradeStatus: Upgraded to focal on 2020-05-11 (164 days ago)
  dmi.bios.date: 02/12/2015
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: V2.4
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: FM2-A75IA-E53 (MS-7792)
  dmi.board.vendor: MSI
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrV2.4:bd02/12/2015:svnMSI:pnMS-7792:pvr1.0:rvnMSI:rnFM2-A75IA-E53(MS-7792):rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: MS-7792
  dmi.product.sku: To be filled by O.E.M.
  dmi.product.version: 1.0
  dmi.sys.vendor: MSI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1901089/+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

Re: [Kernel-packages] [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected

2021-03-18 Thread Ryan Harper

* dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:30]:
> On Tue, Mar 16, 2021 at 10:05 AM Ryan Harper <1918...@bugs.launchpad.net> 
> wrote:
> >
> > Hi Dan,
> >
> > Could you summarize the problem with flash-kernel and this system?
> 
> Sure. flash-kernel recognizes Mustang boards and will generate uImage
> and uInitrd files for it, which are required for booting with u-boot
> firmware. However, these boards can also run in UEFI mode, which
> Date's board does. In UEFI mode, flash-kernel still knows it is on a
> Mustang and generates uImage/uInitrd files - which won't be used for
> anything in that case, they are just wasting space, but does not cause
> it to fail. This does cause problems in a curtin install though.
> Curtin has logic to divert away tools that get executed during
> initramfs hooks, to avoid failures in packaging scripts before an
> initramfs is generated. flash-kernel in particular will fail if an
> initramfs is not found on this system. Curtin tries to be smart here
> and only divert flash-kernel 1) if it is installed and 2) on systems
> that are*not* in UEFI mode, and both of these scenarios have escapes:
> 
> 1) flash-kernel could get installed post-divert. In that case,
> flash-kernel's own postinst will cause it to run and then fail. This
> happens today if you start with a cloud image w/o flash-kernel
> pre-baked because Ubuntu's kernel recommends flash-kernel, causing it
> to be installed along with the kernel. Official cloud images happen to

Hrm, so if we take a squashfs rootfs (with no flash-kernel present)
chroot into it and install the linux-image-generic package pulling in
flash-kernel this fails due to postinst of flash-kernel expecting
initramfs to already be generated?  This doesn't seem like a curtin bug.

> have flash-kernel pre-baked which avoids this issue. I think curtin
> should work whether or not the kernel recommends flash-kernel and
> whether or not curtin is pre-baked (in fact, I'd like for us to stop
> pre-baking it - the vast majoriy of ARM servers do not need it).

> 
> 2) If flash-kernel is installed, and curtin finds we're in UEFI mode,
> it chooses not to divert flash-kernel. flash-kernel will therefore run
> and fail on UEFI Mustangs.

I don't think that's true. The logic for disabling initramfs tools
always runs regardless of UEFI mode and arch.  See
curtin/commands/curthooks.py:builtin_curthooks() lines 1692- 1699

> 
> The way I've personally framed this issue is that Ubuntu should not be
> trying to install flash-kernel on ARM systems that don't require it,
> which is the reason I've added the various tasks here.
>  - cloud images shouldn't prebake it

OK

>  - the kernel should allow non-flash-kernel bootloaders to satisfy its
> recommends

OK

Thanks.  I replied to your later post without seeing this first.
This helps a lot.

>  - curtin shouldn't install flash-kernel on efi-based arm64 servers.
> It does this today, but - in what seems like a bug, only in the
> ephemeral and not the target.

Yeah; I suspect flash-kernel being pre-baked into images hid this for
some time.  As I mentioned in the other reply, I do think that lines
57-58 in curtin/deps/__init__.py which bring in flash-kerenl to the
epheramal can be removed.  And it sounds like we'd move that logic
instead to the install-missing-packages arch_packages where we ensure
s390-tools/zipl are install for s390, there we'd add the same logic to
append flash-kernel where needed for the target OS.

> 
> A separate issue is that flash-kernel should know to just exit if it's
> running on an EFI system and not bother creating the unused
> uImage/uInitrd - Date recently got a patched merged into Debian's f-k
> to do that. That would seemingly also avoid the curtin issues here,
> but only if we continue to install flash-kernel all the time.

OK.

In summary curtin will need:

move ephemeral deps.py flash-kernel to arch-packages in
install-missing-packages with the same logic guarding when to add the
dep.

It's not clear to me why curtin should work around the packaging bugs
around flash-kernel and I would suggest that flash-kernel be kept in the
cloud images until the packging deps/bugs around it are fixed.  Does
that make sense?

Ryan

-- 
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/1918427

Title:
  curtin: install flash-kernel in arm64 UEFI unexpected

Status in cloud-images:
  Confirmed
Status in curtin package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  In Progress

Bug description:
  I used APM Mustang which flash-kernel supported in u-boot mode.
  But I used it with UEFI environment.
  It will cause fatal error when I used ARM64 ubuntu live server ISO to install 
system.

  In code[1], this will not install `flash-kernel` for APM Mustang because of 
UEFI.
  So that means code[2] will not disable `flash-kernel` in target system, only 
disable `update-initramfs`.

[Kernel-packages] [Bug 1918847] Re: Using Wacom stylus on screen causes system lockup

2021-03-18 Thread Rahul

After the kernel update to hirsute (5.11.0-11-generic) the bug has gone.

** Description changed:

  Machine: Lenovo Thinkpad Yoga L13 model 20R5S02B00
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04
  
  On current hirsute, using 5.10.0-14-generic or 5.10.0-14-lowlatency,
  bringing the included Wacom pen to the screen causes an instant lockup.
  There is no solution except hard power off.  It is 100% reproducible.
  
  The last message in syslog before this freeze / force reboot seems to be
  "rfkill: input handler enabled".
  
  This doesn't happen with upstream kernel 5.11.0-051100-generic or with
  the 5.8 kernel 5.8.0-44-generic from groovy.
  
  I am happy to give further information.
+ 
+ UPDATE 2021-03-18: with the hirsute kernel update to 5.11.0.11 the bug
+ has gone.

-- 
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/1918847

Title:
  Using Wacom stylus on screen causes system lockup

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Machine: Lenovo Thinkpad Yoga L13 model 20R5S02B00
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04

  On current hirsute, using 5.10.0-14-generic or 5.10.0-14-lowlatency,
  bringing the included Wacom pen to the screen causes an instant
  lockup.  There is no solution except hard power off.  It is 100%
  reproducible.

  The last message in syslog before this freeze / force reboot seems to
  be "rfkill: input handler enabled".

  This doesn't happen with upstream kernel 5.11.0-051100-generic or with
  the 5.8 kernel 5.8.0-44-generic from groovy.

  I am happy to give further information.

  UPDATE 2021-03-18: with the hirsute kernel update to 5.11.0.11 the bug
  has gone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1918847/+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 1901089] Re: Ubuntu kernels 5.4.0-51 and 5.4.0-52 break ir-keytable loading

2021-03-18 Thread Wes Newell

Kernel 5.4.0-67 is still broken.
Can anyone explain this to me.
A patch that fixed it was done in Dec. 2020. And it was implemented in ppa 
kernels compiled after 01/28/2021.
So why is it that this has not made it into any of the distribution kernels 
yet. Kernels 5.10 has shown up in the repos, yet it is still based on the 
broken kernel versions.
What the heck is going on with this.

-- 
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/1901089

Title:
  Ubuntu kernels 5.4.0-51 and 5.4.0-52 break ir-keytable loading

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I run mythtv on Ubuntu 20.04 and I used a custom remote control keymap
  in /etc/rc_keymaps to correctly map buttons on my IR remote.  The
  above kernel seems to break custom keymap loading for my remote
  (certain buttons no longer work in mythtv).  Reverting to kernel
  5.4.0-48 corrects the problem.

  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  linux-image-5.4.0-52-generic:
Installed: 5.4.0-52.57
Candidate: 5.4.0-52.57
Version table:
   *** 5.4.0-52.57 500
  500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu focal-security/main amd64 
Packages
  100 /var/lib/dpkg/status

  belongs to the linux source package

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-5.4.0-52-generic 5.4.0-52.57
  ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60
  Uname: Linux 5.4.0-48-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.10
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  pdaniel1552 F pulseaudio
   /dev/snd/controlC0:  pdaniel1552 F pulseaudio
  CasperMD5CheckResult: skip
  Date: Thu Oct 22 16:16:58 2020
  InstallationDate: Installed on 2017-04-17 (1284 days ago)
  InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412)
  MachineType: MSI MS-7792
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 radeondrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-48-generic 
root=UUID=38b7dfb0-9848-4919-890b-fdc027e936f1 ro radeon.dpm=0 quiet splash 
vt.handoff=7
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions:
   linux-restricted-modules-5.4.0-48-generic N/A
   linux-backports-modules-5.4.0-48-generic  N/A
   linux-firmware1.187.3
  SourcePackage: linux
  UpgradeStatus: Upgraded to focal on 2020-05-11 (164 days ago)
  dmi.bios.date: 02/12/2015
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: V2.4
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: FM2-A75IA-E53 (MS-7792)
  dmi.board.vendor: MSI
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrV2.4:bd02/12/2015:svnMSI:pnMS-7792:pvr1.0:rvnMSI:rnFM2-A75IA-E53(MS-7792):rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: MS-7792
  dmi.product.sku: To be filled by O.E.M.
  dmi.product.version: 1.0
  dmi.sys.vendor: MSI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1901089/+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 1908677] Re: Dell Latitude 9510 capture volume is too low

2021-03-18 Thread Kai-Chuan Hsieh

＠seb128

Got it, thanks a lot.

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

Title:
  Dell Latitude 9510 capture volume is too low

Status in OEM Priority Project:
  New
Status in alsa-ucm-conf package in Ubuntu:
  Fix Committed

Bug description:
  [Impact]

   * The internal mic default volume is too low
     A upstream commit correct the init configuration

  [Test Case]

   * Using gnome-sound-recoder to record audio without tweak capture volume
     The volume is very low
   * Try to update the init.conf mentioned by
     
https://github.com/alsa-project/alsa-ucm-conf/commit/263bd26b1216c933db3d216197a78678d0f8610e
     $ alsactl init
     $ amixer cget name='rt715 ADC 07 Capture Volume'
     numid=14,iface=MIXER,name='rt715 ADC 07 Capture Volume'
    ; type=INTEGER,access=rw---R--,values=2,min=0,max=63,step=0
    : values=58,58
    | dBscale-min=-17.25dB,step=0.75dB,mute=0

   * Using gnome-sound-recorder to record again
     The volume is significantly improved

  [Where problems could occur]

   * The change only apply to the hardware with rt715 codec.

   * The change adjust the volume only, but not change other control,
     the worst case is the change doesn't take effect.

  [Other Info]

   * The change has been verified on Latitude 9510.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1908677/+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

Re: [Kernel-packages] [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected

2021-03-18 Thread Ryan Harper

* dann frazier <1918...@bugs.launchpad.net> [2021-03-17 20:40]:
> On Wed, Mar 17, 2021 at 4:56 PM Ryan Harper <1918...@bugs.launchpad.net> 
> wrote:
> >
> > I still don't understand:
> >
> > 1) why does which not find flash-kernel if it's present in the ephemeral 
> > image (meaning it will also be present in the target filesystem
> > 2) What is the problem with flash-kernel such that you need to dpkg-divert 
> > it?
> >
> > Generally, we do not want to include paths to binaries; we install
> > Ubuntu and Centos, and possibly other distros which may not have the
> > same path to this tools so I would like to understand what's not working
> > to understand why we're hardcoding paths to binaries for dpkg-divert.
> 
> In my POC patch, it is because we need to divert flash-kernel before
> it is installed, *just in case* it gets installed as a dependency of

Is flash-kernel supposed to be in the cloud-image or not?
Is flash-kernel supposed to be in the target OS or not?

> some other package (in our case it happened due to a kernel Recommends
> relationship). We therefore can't use `which` to look up the path...
> unless we continue to always install f-k in the ephemeral for the sole
> purpose of looking up its path... but that seems to making assumptions
> as well - i.e. that the ephemeral OS has the same paths as the target
> OS.

flash-kernel runs in the target OS;  if it's installed in ephemeral
environment thats a by-product of obtaining tools needed but not present
in the ephemeral environment.

curtin/deps.py runs to ensure the ephemeral environment has the needed
tools to create whatever storage configuration curtin supports.

In the squashfs images which do not have a kernel already installed
curtin will install linux-image-generic to make *additional* kernel
modules which may not be in the initrd that maas produces available.
I'm not sure why the maas initrd doesn't yet have zfs kernel modules but
that's typically the driver of the linux-image-generic install.

w.r.t the dep on flash-kernel, if that is only supposed to run in the
target image, then I agree we can remove lines 57-58 in
curtin/dep/__init.py and not install the package (though it may still
get pulled in via the kernel package install).

Later durting curthooks stage, curtin will query the *target* os in
install-missing-packages for expected packages needed in the target OS.

Prior to installing packages in the target OS, curtin does attempt to
divert initramfs triggering tools to prevent generating the initramfs
more than once (this happens when we install a kernel package in the
target OS and either updates or other packages trigger initramfs
rebuilds).  This is designed around the assumption that the initramfs
generation tool is present in the image but not tied to the kernel
pacakge.  For Ubuntu this is initramfs-tools along with some arch
specific tools.  flash-kernel is the tool used on arm for non-uefi boot.

I see a couple of options but I think I'd like to understand:

1) when is flash-kernel required?  Curtin current expects flash-kernel
to be needed when arch is arm and when booting non-uefi.  Is this still
accurate?

2) Is flash-kernel always installed in arm cloud images used by maas?

3) Is flash-kernel installed by packages due to Recommends when it's not
needed?  If so, are there packaging bugs that need fixing?

Ryan

-- 
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/1918427

Title:
  curtin: install flash-kernel in arm64 UEFI unexpected

Status in cloud-images:
  Confirmed
Status in curtin package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  In Progress

Bug description:
  I used APM Mustang which flash-kernel supported in u-boot mode.
  But I used it with UEFI environment.
  It will cause fatal error when I used ARM64 ubuntu live server ISO to install 
system.

  In code[1], this will not install `flash-kernel` for APM Mustang because of 
UEFI.
  So that means code[2] will not disable `flash-kernel` in target system, only 
disable `update-initramfs`.

  When curtin execute to `install_kernel` stage, code[3,4] will not install 
`flash-kernel` either.
  But in code[5], it will install `linux-generic`.
  `linux-generic` has a long dependency tree and it will get `flash-kernel` in 
Recommended field.
  Apt by default will install Recommended package before kernel is installed.[6]
  So it will still execute `zz-flash-kernel` and `flash-kernel` when installing 
kernel.
  But system didn't create any `initrd.img` ever because curtin disable 
`update-initramfs` in code[2].
  This will cause that `flash-kernel` cannot find `initrd.img.` and fail 
when installing it.

  This issue didn't effect all ARM64 UEFI platform because `flash-kernel` 
didn't support them and skip.[7]
  I'm not sure which is best solution for this.
  But I think we should apply PR-27 in `flash-kernel`[8] for enhancement and 
fix curtin

[Kernel-packages] [Bug 1920030] Re: Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

2021-03-18 Thread jeremyszu

** Tags added: oem-priority originate-from-1918395 stella

** Tags added: originate-from-1918396

** Tags added: originate-from-1918596

** Tags added: originate-from-1918598

** Tags added: originate-from-1919112

** Tags added: originate-from-1919113

** Changed in: oem-priority
 Assignee: (unassigned) => jeremyszu (os369510)

** Changed in: oem-priority
   Importance: Undecided => Critical

** Changed in: oem-priority
   Status: New => Triaged

-- 
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/1920030

Title:
  Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

Status in OEM Priority Project:
  Triaged
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  The Mute/Mic-mute LEDs are not work when muting audio-output/microphone on HP 
850/840/440 G8 laptops.

  [Fix]
  Add three realtek quirks for them.

  [Test]
  After applying the quirks, the LEDs are functioned on HP 850/840/440 G8 
laptops.

  [Where problems could occur]
  If HP ships the different system boards design with the same subsystem IDs of 
audio codec which are using different GPIO pins (different layout), then the 
quirks will not work (LEDs will not function when muting audio-output or 
microphone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1920030/+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 1908677] Re: Dell Latitude 9510 capture volume is too low

2021-03-18 Thread Sebastien Bacher

Sorry for the delay, feel free to ping directly next time if a
sponsoring request isn't picked up. Anyway, uploaded to H,G,F now, with
the 20.10 change fixed to include the patch in the series.

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

Title:
  Dell Latitude 9510 capture volume is too low

Status in OEM Priority Project:
  New
Status in alsa-ucm-conf package in Ubuntu:
  Fix Committed

Bug description:
  [Impact]

   * The internal mic default volume is too low
     A upstream commit correct the init configuration

  [Test Case]

   * Using gnome-sound-recoder to record audio without tweak capture volume
     The volume is very low
   * Try to update the init.conf mentioned by
     
https://github.com/alsa-project/alsa-ucm-conf/commit/263bd26b1216c933db3d216197a78678d0f8610e
     $ alsactl init
     $ amixer cget name='rt715 ADC 07 Capture Volume'
     numid=14,iface=MIXER,name='rt715 ADC 07 Capture Volume'
    ; type=INTEGER,access=rw---R--,values=2,min=0,max=63,step=0
    : values=58,58
    | dBscale-min=-17.25dB,step=0.75dB,mute=0

   * Using gnome-sound-recorder to record again
     The volume is significantly improved

  [Where problems could occur]

   * The change only apply to the hardware with rt715 codec.

   * The change adjust the volume only, but not change other control,
     the worst case is the change doesn't take effect.

  [Other Info]

   * The change has been verified on Latitude 9510.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1908677/+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 1916486] Re: zfs_zrele_async can cause txg sync deadlocks

This bug was fixed in the package zfs-linux - 0.6.5.6-0ubuntu29

---
zfs-linux (0.6.5.6-0ubuntu29) xenial; urgency=medium

  * Fix race condition in zfs_iput_async (LP: #1916486)
- Upstream ZFS fix 43eaef6de817 ("Fix zrele race in zrele_async that can
  cause hang")

 -- Heitor Alves de Siqueira   Thu, 25 Feb 2021
18:21:48 +

** Changed in: zfs-linux (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

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

Title:
  zfs_zrele_async can cause txg sync deadlocks

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Fix Released
Status in zfs-linux source package in Bionic:
  Fix Released
Status in zfs-linux source package in Focal:
  Fix Released
Status in zfs-linux source package in Groovy:
  Fix Released
Status in zfs-linux source package in Hirsute:
  Fix Released
Status in zfs-linux package in Debian:
  New

Bug description:
  [Impact]
  TXG sync stalls, causing ZFS workloads to hang indefinitely

  [Description]
  For certain ZFS workloads, we can see hung task timeouts in the kernel logs 
due to a transaction group deadlock. Userspace process will hang and display 
stack traces similar to the one below:
  [49181.619711] clnt_server D0 21699  28868 0x0320
  [49181.619715] Call Trace:
  [49181.619725]  __schedule+0x24e/0x880
  [49181.619730]  schedule+0x2c/0x80
  [49181.619750]  cv_wait_common+0x11e/0x140 [spl]
  [49181.619763]  ? wait_woken+0x80/0x80
  [49181.619775]  __cv_wait+0x15/0x20 [spl]
  [49181.619872]  zil_commit.part.14+0x80/0x8c0 [zfs]
  [49181.619884]  ? _cond_resched+0x19/0x40
  [49181.619887]  ? mutex_lock+0x12/0x40
  [49181.619959]  zil_commit+0x17/0x20 [zfs]
  [49181.620026]  zfs_fsync+0x77/0xe0 [zfs]
  [49181.620093]  zpl_fsync+0x68/0xa0 [zfs]
  [49181.620100]  vfs_fsync_range+0x51/0xb0
  [49181.620105]  do_fsync+0x3d/0x70
  [49181.620109]  SyS_fsync+0x10/0x20
  [49181.620114]  do_syscall_64+0x73/0x130
  [49181.620119]  entry_SYSCALL_64_after_hwframe+0x41/0xa6

  We also might see a kworker thread blocking in the zfs writeback/evict path:
  [49181.881570] kworker/u17:3   D0  4915  2 0x8000
  [49181.881576] Workqueue: writeback wb_workfn (flush-zfs-10)
  [49181.881577] Call Trace:
  [49181.881580]  __schedule+0x24e/0x880
  [49181.881582]  ? atomic_t_wait+0x60/0x60
  [49181.881584]  schedule+0x2c/0x80
  [49181.881588]  bit_wait+0x11/0x60
  [49181.881592]  __wait_on_bit+0x4c/0x90
  [49181.881596]  ? atomic_t_wait+0x60/0x60
  [49181.881599]  __inode_wait_for_writeback+0xb9/0xf0
  [49181.881601]  ? bit_waitqueue+0x40/0x40
  [49181.881605]  inode_wait_for_writeback+0x26/0x40
  [49181.881609]  evict+0xb5/0x1a0
  [49181.881611]  iput+0x19c/0x230
  [49181.881648]  zfs_iput_async+0x1d/0x80 [zfs]
  [49181.881682]  zfs_get_data+0x1d4/0x2a0 [zfs]
  [49181.881718]  zil_commit.part.14+0x640/0x8c0 [zfs]
  [49181.881752]  zil_commit+0x17/0x20 [zfs]
  [49181.881784]  zpl_writepages+0xd5/0x160 [zfs]
  [49181.881787]  do_writepages+0x4b/0xe0
  [49181.881790]  __writeback_single_inode+0x45/0x350
  [49181.881792]  ? __writeback_single_inode+0x45/0x350
  [49181.881794]  writeback_sb_inodes+0x1d7/0x530
  [49181.881796]  wb_writeback+0xfb/0x300
  [49181.881799]  wb_workfn+0xad/0x400
  [49181.881800]  ? wb_workfn+0xad/0x400
  [49181.881803]  ? __switch_to_asm+0x35/0x70
  [49181.881809]  process_one_work+0x1de/0x420
  [49181.881811]  worker_thread+0x32/0x410
  [49181.881813]  kthread+0x121/0x140
  [49181.881815]  ? process_one_work+0x420/0x420
  [49181.881817]  ? kthread_create_worker_on_cpu+0x70/0x70
  [49181.881819]  ret_from_fork+0x35/0x40

  This is caused by a race between ZFS writeback and evict threads,
  usually during a transaction group sync operation. It's possible to
  have two iput() threads racing for the same inode: one of them
  scheduled async and the other executed synchronously as part of the
  writeback path. If the writeback thread tries to evict the inode while
  the async thread is running, it might re-enter the block layer for the
  same inode due to ZFS counters being in an inconsistent state. This
  then causes the kworker thread to stall the writeback, which in turn
  prevents the transaction group sync to complete and locks other ZFS
  threads.

  This is fixed by the upstream commit:
  - Fix zrele race in zrele_async that can cause hang (43eaef6de817) [0]

  [Test Case]
  Being a race condition, this issue has been hard to reproduce consistently. 
This has been reported on heavy I/O workloads, mixing file creation and 
deletion. We have some reports both from upstream and from Ubuntu users that 
this is usually reproducible on e.g. heavy SQL workloads or on complex 
ccache-enabled builds [1].

  [0] https://github.com/openzfs/zfs/pull/11530
  [1] https://github.com/openzfs/zfs/issues/11527

  [Regression Potential]

[Kernel-packages] [Bug 1920029] Missing required logs.

2021-03-18 Thread Ubuntu Kernel Bot

This bug is missing log files that will aid in diagnosing the problem.
While running an Ubuntu kernel (not a mainline or third-party kernel)
please enter the following command in a terminal window:

apport-collect 1920029

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable
to run this command, please add a comment stating that fact and change
the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.

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

-- 
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/1920029

Title:
  Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  The Mute/Mic-mute LEDs are not work when muting audio-output/microphone on HP 
850/840/440 G8 laptops.

  [Fix]
  Add three realtek quirks for them.

  [Test]
  After applying the quirks, the LEDs are functioned on HP 850/840/440 G8 
laptops.

  [Where problems could occur]
  If HP ships the different system boards design with the same subsystem IDs of 
audio codec which are using different GPIO pins (different layout), then the 
quirks will not work (LEDs will not function when muting audio-output or 
microphone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1920029/+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 1920030] Missing required logs.

2021-03-18 Thread Ubuntu Kernel Bot

This bug is missing log files that will aid in diagnosing the problem.
While running an Ubuntu kernel (not a mainline or third-party kernel)
please enter the following command in a terminal window:

apport-collect 1920030

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable
to run this command, please add a comment stating that fact and change
the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.

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

-- 
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/1920030

Title:
  Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  [Impact]
  The Mute/Mic-mute LEDs are not work when muting audio-output/microphone on HP 
850/840/440 G8 laptops.

  [Fix]
  Add three realtek quirks for them.

  [Test]
  After applying the quirks, the LEDs are functioned on HP 850/840/440 G8 
laptops.

  [Where problems could occur]
  If HP ships the different system boards design with the same subsystem IDs of 
audio codec which are using different GPIO pins (different layout), then the 
quirks will not work (LEDs will not function when muting audio-output or 
microphone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1920030/+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 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected

2021-03-18 Thread Date Huang

HI Dann

Thanks for your rapid reply!

> I'm happy to regression test a candidate patch on the xgene/u-boot
> and non-xgene/uefi platforms we have once Ryan or some other curtin
> maintainer is OK with the approach.

Sure thanks.

> I think the kernel recommending flash-kernel if GRUB is already
> installed is just a bug which is now fixed in hirsute:
>
> https://kernel.ubuntu.com/git/ubuntu/ubuntu-hirsute.git/commit/?id=95325fff0a339a2365a12417a39234e143cc284e

Wow, that is fast.
Thanks for this info.

Regards,
Date

--
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/1918427

Title:
curtin: install flash-kernel in arm64 UEFI unexpected

Status in cloud-images:
Confirmed
Status in curtin package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
In Progress

Bug description:
I used APM Mustang which flash-kernel supported in u-boot mode.
But I used it with UEFI environment.
It will cause fatal error when I used ARM64 ubuntu live server ISO to install
system.

In code[1], this will not install `flash-kernel` for APM Mustang because of
UEFI.
So that means code[2] will not disable `flash-kernel` in target system, only
disable `update-initramfs`.

When curtin execute to `install_kernel` stage, code[3,4] will not install
`flash-kernel` either.
But in code[5], it will install `linux-generic`.
`linux-generic` has a long dependency tree and it will get `flash-kernel` in
Recommended field.
Apt by default will install Recommended package before kernel is installed.[6]
So it will still execute `zz-flash-kernel` and `flash-kernel` when installing
kernel.
But system didn't create any `initrd.img` ever because curtin disable
`update-initramfs` in code[2].
This will cause that `flash-kernel` cannot find `initrd.img.` and fail
when installing it.

This issue didn't effect all ARM64 UEFI platform because `flash-kernel`
didn't support them and skip.[7]
I'm not sure which is best solution for this.
But I think we should apply PR-27 in `flash-kernel`[8] for enhancement and
fix curtin process with this patch both.

If we only apply PR-27, it should work fine as well because it will be
skipped when detecting UEFI
and install `flash-kernel` before `disable_update_initranfs` in ARM platform
without UEFI.[9]

[Patch-1,2,3] might have side effect.
Picking one patch for curtin should be enough.
But I need your advice for this to determine which one is better for curtin.
There are two categories
1. avoid installing flash-kernel if no need, [Patch1,2]
2. always install flash-kernel in arm/arm64 and make sure it be installed
before code[2] [Patch3]
(I will attach patch in reply.)

Thanks a lot
Regards,
Date

[1]
https://github.com/canonical/curtin/blob/master/curtin/deps/__init__.py#L57-L58
[2]
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L1693-L1699
[3]
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L365-L370
[4]
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L311-L327
[5]
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L372-L374
[6] https://github.com/Debian/apt/blob/master/apt-pkg/init.cc#L132
[7]
https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/functions#L787
[8] https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/27
[9] curtin will insert `flash-kernel` into `REQUIRED_EXECUTABLES` when system
is arm/arm64 without UEFI.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1918427/+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 1920029] [NEW] Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

2021-03-18 Thread jeremyszu

Public bug reported:

[Impact]
The Mute/Mic-mute LEDs are not work when muting audio-output/microphone on HP 
850/840/440 G8 laptops.

[Fix]
Add three realtek quirks for them.

[Test]
After applying the quirks, the LEDs are functioned on HP 850/840/440 G8 laptops.

[Where problems could occur]
If HP ships the different system boards design with the same subsystem IDs of 
audio codec which are using different GPIO pins (different layout), then the 
quirks will not work (LEDs will not function when muting audio-output or 
microphone.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: 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/1920029

Title:
  Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

Status in linux package in Ubuntu:
  New

Bug description:
  [Impact]
  The Mute/Mic-mute LEDs are not work when muting audio-output/microphone on HP 
850/840/440 G8 laptops.

  [Fix]
  Add three realtek quirks for them.

  [Test]
  After applying the quirks, the LEDs are functioned on HP 850/840/440 G8 
laptops.

  [Where problems could occur]
  If HP ships the different system boards design with the same subsystem IDs of 
audio codec which are using different GPIO pins (different layout), then the 
quirks will not work (LEDs will not function when muting audio-output or 
microphone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1920029/+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 1920030] [NEW] Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

2021-03-18 Thread jeremyszu

Public bug reported:

[Impact]
The Mute/Mic-mute LEDs are not work when muting audio-output/microphone on HP 
850/840/440 G8 laptops.

[Fix]
Add three realtek quirks for them.

[Test]
After applying the quirks, the LEDs are functioned on HP 850/840/440 G8 laptops.

[Where problems could occur]
If HP ships the different system boards design with the same subsystem IDs of 
audio codec which are using different GPIO pins (different layout), then the 
quirks will not work (LEDs will not function when muting audio-output or 
microphone.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: 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/1920030

Title:
  Mute/Mic-mute LEDs are not work on HP 850/840/440 G8 Laptops

Status in linux package in Ubuntu:
  New

Bug description:
  [Impact]
  The Mute/Mic-mute LEDs are not work when muting audio-output/microphone on HP 
850/840/440 G8 laptops.

  [Fix]
  Add three realtek quirks for them.

  [Test]
  After applying the quirks, the LEDs are functioned on HP 850/840/440 G8 
laptops.

  [Where problems could occur]
  If HP ships the different system boards design with the same subsystem IDs of 
audio codec which are using different GPIO pins (different layout), then the 
quirks will not work (LEDs will not function when muting audio-output or 
microphone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1920030/+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

Re: [Kernel-packages] [Bug 1918427] Re: curtin: install flash-kernel in arm64 UEFI unexpected

On Wed, Mar 17, 2021 at 9:10 PM Date Huang <1918...@bugs.launchpad.net> wrote:
>
> > In my POC patch, it is because we need to divert flash-kernel before
> > it is installed, *just in case* it gets installed as a dependency of
> > some other package (in our case it happened due to a kernel Recommends
> > relationship). We therefore can't use `which` to look up the path...
> > unless we continue to always install f-k in the ephemeral for the sole
> > purpose of looking up its path... but that seems to making assumptions
> > as well - i.e. that the ephemeral OS has the same paths as the target
> > OS.
>
> Hi Dann
> Maybe we can test my patch in #24

Date,
  I'm happy to regression test a candidate patch on the xgene/u-boot
and non-xgene/uefi platforms we have once Ryan or some other curtin
maintainer is OK with the approach.

> Or we can try to install_kernel with --no-recommends to avoid installing 
> flash-kernel
> and move install_missing_packages after install_kernel and 
> enable_update_initramfs?

I think the kernel recommending flash-kernel if GRUB is already
installed is just a bug which is now fixed in hirsute:

https://kernel.ubuntu.com/git/ubuntu/ubuntu-hirsute.git/commit/?id=95325fff0a339a2365a12417a39234e143cc284e

 -dann

-- 
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/1918427

Title:
  curtin: install flash-kernel in arm64 UEFI unexpected

Status in cloud-images:
  Confirmed
Status in curtin package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  In Progress

Bug description:
  I used APM Mustang which flash-kernel supported in u-boot mode.
  But I used it with UEFI environment.
  It will cause fatal error when I used ARM64 ubuntu live server ISO to install 
system.

  In code[1], this will not install `flash-kernel` for APM Mustang because of 
UEFI.
  So that means code[2] will not disable `flash-kernel` in target system, only 
disable `update-initramfs`.

  When curtin execute to `install_kernel` stage, code[3,4] will not install 
`flash-kernel` either.
  But in code[5], it will install `linux-generic`.
  `linux-generic` has a long dependency tree and it will get `flash-kernel` in 
Recommended field.
  Apt by default will install Recommended package before kernel is installed.[6]
  So it will still execute `zz-flash-kernel` and `flash-kernel` when installing 
kernel.
  But system didn't create any `initrd.img` ever because curtin disable 
`update-initramfs` in code[2].
  This will cause that `flash-kernel` cannot find `initrd.img.` and fail 
when installing it.

  This issue didn't effect all ARM64 UEFI platform because `flash-kernel` 
didn't support them and skip.[7]
  I'm not sure which is best solution for this.
  But I think we should apply PR-27 in `flash-kernel`[8] for enhancement and 
fix curtin process with this patch both.

  If we only apply PR-27, it should work fine as well because it will be 
skipped when detecting UEFI
  and install `flash-kernel` before `disable_update_initranfs` in ARM platform 
without UEFI.[9]

  [Patch-1,2,3] might have side effect.
  Picking one patch for curtin should be enough.
  But I need your advice for this to determine which one is better for curtin.
  There are two categories
  1. avoid installing flash-kernel if no need, [Patch1,2]
  2. always install flash-kernel in arm/arm64 and make sure it be installed 
before code[2] [Patch3]
  (I will attach patch in reply.)

  Thanks a lot
  Regards,
  Date

  [1] 
https://github.com/canonical/curtin/blob/master/curtin/deps/__init__.py#L57-L58
  [2] 
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L1693-L1699
  [3] 
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L365-L370
  [4] 
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L311-L327
  [5] 
https://github.com/canonical/curtin/blob/master/curtin/commands/curthooks.py#L372-L374
  [6] https://github.com/Debian/apt/blob/master/apt-pkg/init.cc#L132
  [7] 
https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/functions#L787
  [8] https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/27
  [9] curtin will insert `flash-kernel` into `REQUIRED_EXECUTABLES` when system 
is arm/arm64 without UEFI.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1918427/+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 1919398] Re: amdgpu error amdgpu_dm_commit_planes.constprop.0+0x9cf/0x9f0

2021-03-18 Thread satmandu

This is not a problem in the 5.10 kernels.

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

Title:
  amdgpu error amdgpu_dm_commit_planes.constprop.0+0x9cf/0x9f0

Status in linux-meta package in Ubuntu:
  New

Bug description:
  Running 5.11.0-11-lowlatency on radeon RX 5500 XT "[AMD/ATI] Navi 14
  [Radeon RX 5500/5500M / Pro 5500M] (rev c5)"

  Primary application is Kodi, which freezes on start, requiring the
  process to be restarted  (sometimes this requires a reboot of the
  entire machine.)

  dmesg shows this error:


  [ 1567.704562] [drm] amdgpu_dm_irq_schedule_work FAILED src 4
  [ 1567.974561] [drm] amdgpu_dm_irq_schedule_work FAILED src 4
  [ 1568.704568] [drm] amdgpu_dm_irq_schedule_work FAILED src 4
  [ 1570.025161] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] 
*ERROR* [CRTC:72:crtc-0] flip_done timed out
  [ 1571.049175] [drm:do_aquire_global_lock.isra.0 [amdgpu]] *ERROR* 
[CRTC:72:crtc-0] hw_done or flip_done timed out
  [ 1581.289438] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [CRTC:72:crtc-0] flip_done timed out
  [ 1591.529598] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [PLANE:60:plane-4] flip_done timed out
  [ 1591.594241] [ cut here ]
  [ 1591.594243] WARNING: CPU: 1 PID: 54905 at 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7754 
amdgpu_dm_commit_planes.constprop.0+0x9cf/0x9f0 [amdgpu]
  [ 1591.594436] Modules linked in: hidp xt_nat rfcomm veth 
nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype br_netfilter wireguard 
curve25519_x86_64 libchacha20poly1305 chacha_x86_64 poly1305_x86_64 libblake2s 
blake2s_x86_64 ip6_udp_tunnel udp_tunnel libcurve25519_generic libchacha 
libblake2s_generic xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT 
nf_reject_ipv4 xt_tcpudp nft_compat nft_chain_nat nf_nat nf_conntrack 
nf_defrag_ipv6 nf_defrag_ipv4 nft_counter nf_tables nfnetlink bridge stp llc 
overlay cmac algif_hash algif_skcipher af_alg bnep binfmt_misc nls_iso8859_1 
xfs intel_rapl_msr mei_hdcp btusb btrtl btbcm btintel bluetooth ecdh_generic 
ecc intel_rapl_common x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm rapl 
intel_cstate efi_pstore intel_wmi_thunderbolt snd_hda_codec_realtek 
snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi ee1004 snd_hda_intel 
snd_intel_dspcfg soundwire_intel soundwire_generic_allocation soundwire_cadence 
snd_hda_codec snd_hda_core soundwire_bus
  [ 1591.594476]  snd_soc_core snd_compress snd_usb_audio ac97_bus 
snd_pcm_dmaengine snd_usbmidi_lib snd_hwdep snd_seq_midi uvcvideo 
snd_seq_midi_event videobuf2_vmalloc videobuf2_memops snd_pcm videobuf2_v4l2 
snd_rawmidi videobuf2_common cdc_acm joydev input_leds snd_seq videodev mc 
snd_seq_device snd_timer mei_me mei intel_pch_thermal snd soundcore mac_hid 
acpi_pad sch_fq_codel nct6775 hwmon_vid coretemp msr parport_pc ppdev lp 
parport binder_linux nfsd ashmem_linux(CE) auth_rpcgss nfs_acl lockd grace 
sunrpc nfs_ssc ip_tables x_tables autofs4 zfs(POE) zunicode(POE) zzstd(O) 
zlua(OE) zavl(POE) icp(POE) zcommon(POE) znvpair(POE) spl(OE) raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c raid1 raid0 multipath linear hid_magicmouse mlx4_ib ib_uverbs ib_core 
mlx4_en hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid uas 
usb_storage amdgpu iommu_v2 gpu_sched i2c_algo_bit drm_ttm_helper ttm mxm_wmi 
drm_kms_helper crct10dif_pclmul crc32_pclmul
  [ 1591.594527]  syscopyarea sysfillrect sysimgblt fb_sys_fops 
ghash_clmulni_intel cec aesni_intel rc_core crypto_simd cryptd glue_helper 
mpt3sas nvme drm mlx4_core e1000e i2c_i801 i2c_smbus raid_class nvme_core 
scsi_transport_sas ahci libahci xhci_pci xhci_pci_renesas wmi video
  [ 1591.594544] CPU: 1 PID: 54905 Comm: kworker/1:2 Tainted: PWC OE
 5.11.0-11-lowlatency #12-Ubuntu
  [ 1591.594546] Hardware name: MSI MS-7998/C236A WORKSTATION (MS-7998), BIOS 
2.A0 06/15/2018
  [ 1591.594548] Workqueue: events dm_irq_work_func [amdgpu]
  [ 1591.594689] RIP: 0010:amdgpu_dm_commit_planes.constprop.0+0x9cf/0x9f0 
[amdgpu]
  [ 1591.594826] Code: ff 48 8b 45 a8 48 c7 c7 12 9f c1 c0 4c 89 55 80 8b b0 f0 
03 00 00 e8 e0 04 c9 ff 0f b6 55 a3 4c 8b 55 80 e9 24 fa ff ff 0f 0b <0f> 0b e9 
89 fe ff ff 0f 0b e9 a2 fe ff ff e8 9e f3 af f9 66 66 2e
  [ 1591.594828] RSP: 0018:a84784bf79f0 EFLAGS: 00010002
  [ 1591.594830] RAX: 0287 RBX: 0004 RCX: 
0461
  [ 1591.594831] RDX: 0001 RSI: 0293 RDI: 
908517ea0188
  [ 1591.594832] RBP: a84784bf7ab0 R08: 0002 R09: 
0001
  [ 1591.594833] R10:  R11: 90851a35b918 R12: 
0287
  [ 1591.594834] R13: 90851a35b800 R14: 9085eb9d9d00 R15: 
9087e43c7600
  [ 1591.594835] FS:  ()

[Kernel-packages] [Bug 1903288] Comment bridged from LTC Bugzilla

2021-03-18 Thread bugproxy

--- Comment From daniel.axte...@ibm.com 2021-03-18 09:39 EDT---
(In reply to comment #22)
> Kind of wish for a config option that would do add_to_platform_keyring a
> built-in set of keys, until we have something like the other platforms have
> (ipl on s390x, uefi db on EFI platforms).
>
> Similar to how the built-in trusted keys are initialized.

Yeah, I think that might be the least-awful option. I'll see if I can
bash out an "UBUNTU: SAUCE: (no-up)" patch for you :)

Kind regards,
Daniel

-- 
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/1903288

Title:
  Power guest secure boot with static keys: kernel portion

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #2 - Daniel John Axtens  - 2020-11-05 
20:15:10 ==
  This is the kernel side of changes needed for LPAR/guest secure boot.

  Because Ubuntu keeps its kernels so wonderfully up to date, I don't
  think there are any extra patches you need to pick up. (I'll double-
  check against the 21.04 tree once my git pulls finish!)

  However, we potentially need some configuration changes to make sure
  kexec-ing into a crashdump kernel still works.

  Because Lockdown requires that kexec kernels are signed by a key
  trusted by IMA, the public key for used for signing the kdump kernel
  needs to be in the IMA keyring or the platform keyring. For host
  secure boot (and in the UEFI case), it's loaded into the platform
  keyring. But in the case of guest secure boot with static keys, it's
  not loaded into the platform keyring so it needs to be loaded into the
  IMA keyring.

  This is easy enough to do. Firstly, load the Secure Boot CA into the
  .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS
  property. We assume the key used to sign the kernel is signed by this
  CA.

  Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the 
.primary_trusted_keys keyring to be loaded into the IMA keyring. Then set 
IMA_X509_PATH to provide a path to the signing key on installed file system. 
(It may also be possible to do this step in userspace, so long as the CA is 
trusted by the kernel.)
   
  Then that key will be loaded into the .ima keyring at boot and be used to 
appraise the kexec kernel for crashdumps.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1916486] Re: zfs_zrele_async can cause txg sync deadlocks

This bug was fixed in the package zfs-linux - 0.7.5-1ubuntu16.11

---
zfs-linux (0.7.5-1ubuntu16.11) bionic; urgency=medium

  * Fix race condition in zfs_iput_async (LP: #1916486)
- Upstream ZFS fix 43eaef6de817 ("Fix zrele race in zrele_async that can
  cause hang")

 -- Heitor Alves de Siqueira   Thu, 25 Feb 2021
17:20:20 +

** Changed in: zfs-linux (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

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

Title:
  zfs_zrele_async can cause txg sync deadlocks

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Fix Committed
Status in zfs-linux source package in Bionic:
  Fix Released
Status in zfs-linux source package in Focal:
  Fix Released
Status in zfs-linux source package in Groovy:
  Fix Released
Status in zfs-linux source package in Hirsute:
  Fix Released
Status in zfs-linux package in Debian:
  New

Bug description:
  [Impact]
  TXG sync stalls, causing ZFS workloads to hang indefinitely

  [Description]
  For certain ZFS workloads, we can see hung task timeouts in the kernel logs 
due to a transaction group deadlock. Userspace process will hang and display 
stack traces similar to the one below:
  [49181.619711] clnt_server D0 21699  28868 0x0320
  [49181.619715] Call Trace:
  [49181.619725]  __schedule+0x24e/0x880
  [49181.619730]  schedule+0x2c/0x80
  [49181.619750]  cv_wait_common+0x11e/0x140 [spl]
  [49181.619763]  ? wait_woken+0x80/0x80
  [49181.619775]  __cv_wait+0x15/0x20 [spl]
  [49181.619872]  zil_commit.part.14+0x80/0x8c0 [zfs]
  [49181.619884]  ? _cond_resched+0x19/0x40
  [49181.619887]  ? mutex_lock+0x12/0x40
  [49181.619959]  zil_commit+0x17/0x20 [zfs]
  [49181.620026]  zfs_fsync+0x77/0xe0 [zfs]
  [49181.620093]  zpl_fsync+0x68/0xa0 [zfs]
  [49181.620100]  vfs_fsync_range+0x51/0xb0
  [49181.620105]  do_fsync+0x3d/0x70
  [49181.620109]  SyS_fsync+0x10/0x20
  [49181.620114]  do_syscall_64+0x73/0x130
  [49181.620119]  entry_SYSCALL_64_after_hwframe+0x41/0xa6

  We also might see a kworker thread blocking in the zfs writeback/evict path:
  [49181.881570] kworker/u17:3   D0  4915  2 0x8000
  [49181.881576] Workqueue: writeback wb_workfn (flush-zfs-10)
  [49181.881577] Call Trace:
  [49181.881580]  __schedule+0x24e/0x880
  [49181.881582]  ? atomic_t_wait+0x60/0x60
  [49181.881584]  schedule+0x2c/0x80
  [49181.881588]  bit_wait+0x11/0x60
  [49181.881592]  __wait_on_bit+0x4c/0x90
  [49181.881596]  ? atomic_t_wait+0x60/0x60
  [49181.881599]  __inode_wait_for_writeback+0xb9/0xf0
  [49181.881601]  ? bit_waitqueue+0x40/0x40
  [49181.881605]  inode_wait_for_writeback+0x26/0x40
  [49181.881609]  evict+0xb5/0x1a0
  [49181.881611]  iput+0x19c/0x230
  [49181.881648]  zfs_iput_async+0x1d/0x80 [zfs]
  [49181.881682]  zfs_get_data+0x1d4/0x2a0 [zfs]
  [49181.881718]  zil_commit.part.14+0x640/0x8c0 [zfs]
  [49181.881752]  zil_commit+0x17/0x20 [zfs]
  [49181.881784]  zpl_writepages+0xd5/0x160 [zfs]
  [49181.881787]  do_writepages+0x4b/0xe0
  [49181.881790]  __writeback_single_inode+0x45/0x350
  [49181.881792]  ? __writeback_single_inode+0x45/0x350
  [49181.881794]  writeback_sb_inodes+0x1d7/0x530
  [49181.881796]  wb_writeback+0xfb/0x300
  [49181.881799]  wb_workfn+0xad/0x400
  [49181.881800]  ? wb_workfn+0xad/0x400
  [49181.881803]  ? __switch_to_asm+0x35/0x70
  [49181.881809]  process_one_work+0x1de/0x420
  [49181.881811]  worker_thread+0x32/0x410
  [49181.881813]  kthread+0x121/0x140
  [49181.881815]  ? process_one_work+0x420/0x420
  [49181.881817]  ? kthread_create_worker_on_cpu+0x70/0x70
  [49181.881819]  ret_from_fork+0x35/0x40

  This is caused by a race between ZFS writeback and evict threads,
  usually during a transaction group sync operation. It's possible to
  have two iput() threads racing for the same inode: one of them
  scheduled async and the other executed synchronously as part of the
  writeback path. If the writeback thread tries to evict the inode while
  the async thread is running, it might re-enter the block layer for the
  same inode due to ZFS counters being in an inconsistent state. This
  then causes the kworker thread to stall the writeback, which in turn
  prevents the transaction group sync to complete and locks other ZFS
  threads.

  This is fixed by the upstream commit:
  - Fix zrele race in zrele_async that can cause hang (43eaef6de817) [0]

  [Test Case]
  Being a race condition, this issue has been hard to reproduce consistently. 
This has been reported on heavy I/O workloads, mixing file creation and 
deletion. We have some reports both from upstream and from Ubuntu users that 
this is usually reproducible on e.g. heavy SQL workloads or on complex 
ccache-enabled builds [1].

  [0] https://github.com/openzfs/zfs/pull/11530
  [1] https://github.com/openzfs/zfs/issues/11527

  [Regression Potential]

[Kernel-packages] [Bug 1916486] Re: zfs_zrele_async can cause txg sync deadlocks

This bug was fixed in the package zfs-linux - 0.8.3-1ubuntu12.7

---
zfs-linux (0.8.3-1ubuntu12.7) focal; urgency=medium

  * Fix race condition in zfs_iput_async (LP: #1916486)
- Upstream ZFS fix 43eaef6de817 ("Fix zrele race in zrele_async that can
  cause hang")

 -- Heitor Alves de Siqueira   Thu, 25 Feb 2021
19:48:51 +

** Changed in: zfs-linux (Ubuntu Focal)
   Status: Fix Committed => Fix Released

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

Title:
  zfs_zrele_async can cause txg sync deadlocks

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Fix Committed
Status in zfs-linux source package in Bionic:
  Fix Committed
Status in zfs-linux source package in Focal:
  Fix Released
Status in zfs-linux source package in Groovy:
  Fix Released
Status in zfs-linux source package in Hirsute:
  Fix Released
Status in zfs-linux package in Debian:
  New

Bug description:
  [Impact]
  TXG sync stalls, causing ZFS workloads to hang indefinitely

  [Description]
  For certain ZFS workloads, we can see hung task timeouts in the kernel logs 
due to a transaction group deadlock. Userspace process will hang and display 
stack traces similar to the one below:
  [49181.619711] clnt_server D0 21699  28868 0x0320
  [49181.619715] Call Trace:
  [49181.619725]  __schedule+0x24e/0x880
  [49181.619730]  schedule+0x2c/0x80
  [49181.619750]  cv_wait_common+0x11e/0x140 [spl]
  [49181.619763]  ? wait_woken+0x80/0x80
  [49181.619775]  __cv_wait+0x15/0x20 [spl]
  [49181.619872]  zil_commit.part.14+0x80/0x8c0 [zfs]
  [49181.619884]  ? _cond_resched+0x19/0x40
  [49181.619887]  ? mutex_lock+0x12/0x40
  [49181.619959]  zil_commit+0x17/0x20 [zfs]
  [49181.620026]  zfs_fsync+0x77/0xe0 [zfs]
  [49181.620093]  zpl_fsync+0x68/0xa0 [zfs]
  [49181.620100]  vfs_fsync_range+0x51/0xb0
  [49181.620105]  do_fsync+0x3d/0x70
  [49181.620109]  SyS_fsync+0x10/0x20
  [49181.620114]  do_syscall_64+0x73/0x130
  [49181.620119]  entry_SYSCALL_64_after_hwframe+0x41/0xa6

  We also might see a kworker thread blocking in the zfs writeback/evict path:
  [49181.881570] kworker/u17:3   D0  4915  2 0x8000
  [49181.881576] Workqueue: writeback wb_workfn (flush-zfs-10)
  [49181.881577] Call Trace:
  [49181.881580]  __schedule+0x24e/0x880
  [49181.881582]  ? atomic_t_wait+0x60/0x60
  [49181.881584]  schedule+0x2c/0x80
  [49181.881588]  bit_wait+0x11/0x60
  [49181.881592]  __wait_on_bit+0x4c/0x90
  [49181.881596]  ? atomic_t_wait+0x60/0x60
  [49181.881599]  __inode_wait_for_writeback+0xb9/0xf0
  [49181.881601]  ? bit_waitqueue+0x40/0x40
  [49181.881605]  inode_wait_for_writeback+0x26/0x40
  [49181.881609]  evict+0xb5/0x1a0
  [49181.881611]  iput+0x19c/0x230
  [49181.881648]  zfs_iput_async+0x1d/0x80 [zfs]
  [49181.881682]  zfs_get_data+0x1d4/0x2a0 [zfs]
  [49181.881718]  zil_commit.part.14+0x640/0x8c0 [zfs]
  [49181.881752]  zil_commit+0x17/0x20 [zfs]
  [49181.881784]  zpl_writepages+0xd5/0x160 [zfs]
  [49181.881787]  do_writepages+0x4b/0xe0
  [49181.881790]  __writeback_single_inode+0x45/0x350
  [49181.881792]  ? __writeback_single_inode+0x45/0x350
  [49181.881794]  writeback_sb_inodes+0x1d7/0x530
  [49181.881796]  wb_writeback+0xfb/0x300
  [49181.881799]  wb_workfn+0xad/0x400
  [49181.881800]  ? wb_workfn+0xad/0x400
  [49181.881803]  ? __switch_to_asm+0x35/0x70
  [49181.881809]  process_one_work+0x1de/0x420
  [49181.881811]  worker_thread+0x32/0x410
  [49181.881813]  kthread+0x121/0x140
  [49181.881815]  ? process_one_work+0x420/0x420
  [49181.881817]  ? kthread_create_worker_on_cpu+0x70/0x70
  [49181.881819]  ret_from_fork+0x35/0x40

  This is caused by a race between ZFS writeback and evict threads,
  usually during a transaction group sync operation. It's possible to
  have two iput() threads racing for the same inode: one of them
  scheduled async and the other executed synchronously as part of the
  writeback path. If the writeback thread tries to evict the inode while
  the async thread is running, it might re-enter the block layer for the
  same inode due to ZFS counters being in an inconsistent state. This
  then causes the kworker thread to stall the writeback, which in turn
  prevents the transaction group sync to complete and locks other ZFS
  threads.

  This is fixed by the upstream commit:
  - Fix zrele race in zrele_async that can cause hang (43eaef6de817) [0]

  [Test Case]
  Being a race condition, this issue has been hard to reproduce consistently. 
This has been reported on heavy I/O workloads, mixing file creation and 
deletion. We have some reports both from upstream and from Ubuntu users that 
this is usually reproducible on e.g. heavy SQL workloads or on complex 
ccache-enabled builds [1].

  [0] https://github.com/openzfs/zfs/pull/11530
  [1] https://github.com/openzfs/zfs/issues/11527

  [Regression Potential]

[Kernel-packages] [Bug 1916486] Re: zfs_zrele_async can cause txg sync deadlocks

This bug was fixed in the package zfs-linux - 0.8.4-1ubuntu11.2

---
zfs-linux (0.8.4-1ubuntu11.2) groovy; urgency=medium

  * Fix race condition in zfs_iput_async (LP: #1916486)
- Upstream ZFS fix 43eaef6de817 ("Fix zrele race in zrele_async that can
  cause hang")

 -- Heitor Alves de Siqueira   Thu, 25 Feb 2021
19:53:32 +

** Changed in: zfs-linux (Ubuntu Groovy)
   Status: Fix Committed => Fix Released

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

Title:
  zfs_zrele_async can cause txg sync deadlocks

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Fix Committed
Status in zfs-linux source package in Bionic:
  Fix Committed
Status in zfs-linux source package in Focal:
  Fix Committed
Status in zfs-linux source package in Groovy:
  Fix Released
Status in zfs-linux source package in Hirsute:
  Fix Released
Status in zfs-linux package in Debian:
  New

Bug description:
  [Impact]
  TXG sync stalls, causing ZFS workloads to hang indefinitely

  [Description]
  For certain ZFS workloads, we can see hung task timeouts in the kernel logs 
due to a transaction group deadlock. Userspace process will hang and display 
stack traces similar to the one below:
  [49181.619711] clnt_server D0 21699  28868 0x0320
  [49181.619715] Call Trace:
  [49181.619725]  __schedule+0x24e/0x880
  [49181.619730]  schedule+0x2c/0x80
  [49181.619750]  cv_wait_common+0x11e/0x140 [spl]
  [49181.619763]  ? wait_woken+0x80/0x80
  [49181.619775]  __cv_wait+0x15/0x20 [spl]
  [49181.619872]  zil_commit.part.14+0x80/0x8c0 [zfs]
  [49181.619884]  ? _cond_resched+0x19/0x40
  [49181.619887]  ? mutex_lock+0x12/0x40
  [49181.619959]  zil_commit+0x17/0x20 [zfs]
  [49181.620026]  zfs_fsync+0x77/0xe0 [zfs]
  [49181.620093]  zpl_fsync+0x68/0xa0 [zfs]
  [49181.620100]  vfs_fsync_range+0x51/0xb0
  [49181.620105]  do_fsync+0x3d/0x70
  [49181.620109]  SyS_fsync+0x10/0x20
  [49181.620114]  do_syscall_64+0x73/0x130
  [49181.620119]  entry_SYSCALL_64_after_hwframe+0x41/0xa6

  We also might see a kworker thread blocking in the zfs writeback/evict path:
  [49181.881570] kworker/u17:3   D0  4915  2 0x8000
  [49181.881576] Workqueue: writeback wb_workfn (flush-zfs-10)
  [49181.881577] Call Trace:
  [49181.881580]  __schedule+0x24e/0x880
  [49181.881582]  ? atomic_t_wait+0x60/0x60
  [49181.881584]  schedule+0x2c/0x80
  [49181.881588]  bit_wait+0x11/0x60
  [49181.881592]  __wait_on_bit+0x4c/0x90
  [49181.881596]  ? atomic_t_wait+0x60/0x60
  [49181.881599]  __inode_wait_for_writeback+0xb9/0xf0
  [49181.881601]  ? bit_waitqueue+0x40/0x40
  [49181.881605]  inode_wait_for_writeback+0x26/0x40
  [49181.881609]  evict+0xb5/0x1a0
  [49181.881611]  iput+0x19c/0x230
  [49181.881648]  zfs_iput_async+0x1d/0x80 [zfs]
  [49181.881682]  zfs_get_data+0x1d4/0x2a0 [zfs]
  [49181.881718]  zil_commit.part.14+0x640/0x8c0 [zfs]
  [49181.881752]  zil_commit+0x17/0x20 [zfs]
  [49181.881784]  zpl_writepages+0xd5/0x160 [zfs]
  [49181.881787]  do_writepages+0x4b/0xe0
  [49181.881790]  __writeback_single_inode+0x45/0x350
  [49181.881792]  ? __writeback_single_inode+0x45/0x350
  [49181.881794]  writeback_sb_inodes+0x1d7/0x530
  [49181.881796]  wb_writeback+0xfb/0x300
  [49181.881799]  wb_workfn+0xad/0x400
  [49181.881800]  ? wb_workfn+0xad/0x400
  [49181.881803]  ? __switch_to_asm+0x35/0x70
  [49181.881809]  process_one_work+0x1de/0x420
  [49181.881811]  worker_thread+0x32/0x410
  [49181.881813]  kthread+0x121/0x140
  [49181.881815]  ? process_one_work+0x420/0x420
  [49181.881817]  ? kthread_create_worker_on_cpu+0x70/0x70
  [49181.881819]  ret_from_fork+0x35/0x40

  This is caused by a race between ZFS writeback and evict threads,
  usually during a transaction group sync operation. It's possible to
  have two iput() threads racing for the same inode: one of them
  scheduled async and the other executed synchronously as part of the
  writeback path. If the writeback thread tries to evict the inode while
  the async thread is running, it might re-enter the block layer for the
  same inode due to ZFS counters being in an inconsistent state. This
  then causes the kworker thread to stall the writeback, which in turn
  prevents the transaction group sync to complete and locks other ZFS
  threads.

  This is fixed by the upstream commit:
  - Fix zrele race in zrele_async that can cause hang (43eaef6de817) [0]

  [Test Case]
  Being a race condition, this issue has been hard to reproduce consistently. 
This has been reported on heavy I/O workloads, mixing file creation and 
deletion. We have some reports both from upstream and from Ubuntu users that 
this is usually reproducible on e.g. heavy SQL workloads or on complex 
ccache-enabled builds [1].

  [0] https://github.com/openzfs/zfs/pull/11530
  [1] https://github.com/openzfs/zfs/issues/11527

  [Regression Potential]

[Kernel-packages] [Bug 1916486] Update Released

2021-03-18 Thread Łukasz Zemczak

The verification of the Stable Release Update for zfs-linux has
completed successfully and the package is now being released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  zfs_zrele_async can cause txg sync deadlocks

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Fix Committed
Status in zfs-linux source package in Bionic:
  Fix Committed
Status in zfs-linux source package in Focal:
  Fix Committed
Status in zfs-linux source package in Groovy:
  Fix Released
Status in zfs-linux source package in Hirsute:
  Fix Released
Status in zfs-linux package in Debian:
  New

Bug description:
  [Impact]
  TXG sync stalls, causing ZFS workloads to hang indefinitely

  [Description]
  For certain ZFS workloads, we can see hung task timeouts in the kernel logs 
due to a transaction group deadlock. Userspace process will hang and display 
stack traces similar to the one below:
  [49181.619711] clnt_server D0 21699  28868 0x0320
  [49181.619715] Call Trace:
  [49181.619725]  __schedule+0x24e/0x880
  [49181.619730]  schedule+0x2c/0x80
  [49181.619750]  cv_wait_common+0x11e/0x140 [spl]
  [49181.619763]  ? wait_woken+0x80/0x80
  [49181.619775]  __cv_wait+0x15/0x20 [spl]
  [49181.619872]  zil_commit.part.14+0x80/0x8c0 [zfs]
  [49181.619884]  ? _cond_resched+0x19/0x40
  [49181.619887]  ? mutex_lock+0x12/0x40
  [49181.619959]  zil_commit+0x17/0x20 [zfs]
  [49181.620026]  zfs_fsync+0x77/0xe0 [zfs]
  [49181.620093]  zpl_fsync+0x68/0xa0 [zfs]
  [49181.620100]  vfs_fsync_range+0x51/0xb0
  [49181.620105]  do_fsync+0x3d/0x70
  [49181.620109]  SyS_fsync+0x10/0x20
  [49181.620114]  do_syscall_64+0x73/0x130
  [49181.620119]  entry_SYSCALL_64_after_hwframe+0x41/0xa6

  We also might see a kworker thread blocking in the zfs writeback/evict path:
  [49181.881570] kworker/u17:3   D0  4915  2 0x8000
  [49181.881576] Workqueue: writeback wb_workfn (flush-zfs-10)
  [49181.881577] Call Trace:
  [49181.881580]  __schedule+0x24e/0x880
  [49181.881582]  ? atomic_t_wait+0x60/0x60
  [49181.881584]  schedule+0x2c/0x80
  [49181.881588]  bit_wait+0x11/0x60
  [49181.881592]  __wait_on_bit+0x4c/0x90
  [49181.881596]  ? atomic_t_wait+0x60/0x60
  [49181.881599]  __inode_wait_for_writeback+0xb9/0xf0
  [49181.881601]  ? bit_waitqueue+0x40/0x40
  [49181.881605]  inode_wait_for_writeback+0x26/0x40
  [49181.881609]  evict+0xb5/0x1a0
  [49181.881611]  iput+0x19c/0x230
  [49181.881648]  zfs_iput_async+0x1d/0x80 [zfs]
  [49181.881682]  zfs_get_data+0x1d4/0x2a0 [zfs]
  [49181.881718]  zil_commit.part.14+0x640/0x8c0 [zfs]
  [49181.881752]  zil_commit+0x17/0x20 [zfs]
  [49181.881784]  zpl_writepages+0xd5/0x160 [zfs]
  [49181.881787]  do_writepages+0x4b/0xe0
  [49181.881790]  __writeback_single_inode+0x45/0x350
  [49181.881792]  ? __writeback_single_inode+0x45/0x350
  [49181.881794]  writeback_sb_inodes+0x1d7/0x530
  [49181.881796]  wb_writeback+0xfb/0x300
  [49181.881799]  wb_workfn+0xad/0x400
  [49181.881800]  ? wb_workfn+0xad/0x400
  [49181.881803]  ? __switch_to_asm+0x35/0x70
  [49181.881809]  process_one_work+0x1de/0x420
  [49181.881811]  worker_thread+0x32/0x410
  [49181.881813]  kthread+0x121/0x140
  [49181.881815]  ? process_one_work+0x420/0x420
  [49181.881817]  ? kthread_create_worker_on_cpu+0x70/0x70
  [49181.881819]  ret_from_fork+0x35/0x40

  This is caused by a race between ZFS writeback and evict threads,
  usually during a transaction group sync operation. It's possible to
  have two iput() threads racing for the same inode: one of them
  scheduled async and the other executed synchronously as part of the
  writeback path. If the writeback thread tries to evict the inode while
  the async thread is running, it might re-enter the block layer for the
  same inode due to ZFS counters being in an inconsistent state. This
  then causes the kworker thread to stall the writeback, which in turn
  prevents the transaction group sync to complete and locks other ZFS
  threads.

  This is fixed by the upstream commit:
  - Fix zrele race in zrele_async that can cause hang (43eaef6de817) [0]

  [Test Case]
  Being a race condition, this issue has been hard to reproduce consistently. 
This has been reported on heavy I/O workloads, mixing file creation and 
deletion. We have some reports both from upstream and from Ubuntu users that 
this is usually reproducible on e.g. heavy SQL workloads or on complex 
ccache-enabled builds [1].

  [0] https://github.com/openzfs/zfs/pull/11530
  [1]

[Kernel-packages] [Bug 1916486] Re: zfs_zrele_async can cause txg sync deadlocks

2021-03-18 Thread Heitor Alves de Siqueira

There's a build failure for zfs-linux on riscv64/focal, but that should
be safe to ignore for this patch. The riscv64 builds seem to have failed
since they were enabled in 0.8.3-1ubuntu11, and are related to an
"Unsupported ISA type" error in the libspl header files. It's likely
that we're missing some compatibility patches from upstream for this
specific architecture.

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

Title:
  zfs_zrele_async can cause txg sync deadlocks

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Fix Committed
Status in zfs-linux source package in Bionic:
  Fix Committed
Status in zfs-linux source package in Focal:
  Fix Committed
Status in zfs-linux source package in Groovy:
  Fix Committed
Status in zfs-linux source package in Hirsute:
  Fix Released
Status in zfs-linux package in Debian:
  New

Bug description:
  [Impact]
  TXG sync stalls, causing ZFS workloads to hang indefinitely

  [Description]
  For certain ZFS workloads, we can see hung task timeouts in the kernel logs 
due to a transaction group deadlock. Userspace process will hang and display 
stack traces similar to the one below:
  [49181.619711] clnt_server D0 21699  28868 0x0320
  [49181.619715] Call Trace:
  [49181.619725]  __schedule+0x24e/0x880
  [49181.619730]  schedule+0x2c/0x80
  [49181.619750]  cv_wait_common+0x11e/0x140 [spl]
  [49181.619763]  ? wait_woken+0x80/0x80
  [49181.619775]  __cv_wait+0x15/0x20 [spl]
  [49181.619872]  zil_commit.part.14+0x80/0x8c0 [zfs]
  [49181.619884]  ? _cond_resched+0x19/0x40
  [49181.619887]  ? mutex_lock+0x12/0x40
  [49181.619959]  zil_commit+0x17/0x20 [zfs]
  [49181.620026]  zfs_fsync+0x77/0xe0 [zfs]
  [49181.620093]  zpl_fsync+0x68/0xa0 [zfs]
  [49181.620100]  vfs_fsync_range+0x51/0xb0
  [49181.620105]  do_fsync+0x3d/0x70
  [49181.620109]  SyS_fsync+0x10/0x20
  [49181.620114]  do_syscall_64+0x73/0x130
  [49181.620119]  entry_SYSCALL_64_after_hwframe+0x41/0xa6

  We also might see a kworker thread blocking in the zfs writeback/evict path:
  [49181.881570] kworker/u17:3   D0  4915  2 0x8000
  [49181.881576] Workqueue: writeback wb_workfn (flush-zfs-10)
  [49181.881577] Call Trace:
  [49181.881580]  __schedule+0x24e/0x880
  [49181.881582]  ? atomic_t_wait+0x60/0x60
  [49181.881584]  schedule+0x2c/0x80
  [49181.881588]  bit_wait+0x11/0x60
  [49181.881592]  __wait_on_bit+0x4c/0x90
  [49181.881596]  ? atomic_t_wait+0x60/0x60
  [49181.881599]  __inode_wait_for_writeback+0xb9/0xf0
  [49181.881601]  ? bit_waitqueue+0x40/0x40
  [49181.881605]  inode_wait_for_writeback+0x26/0x40
  [49181.881609]  evict+0xb5/0x1a0
  [49181.881611]  iput+0x19c/0x230
  [49181.881648]  zfs_iput_async+0x1d/0x80 [zfs]
  [49181.881682]  zfs_get_data+0x1d4/0x2a0 [zfs]
  [49181.881718]  zil_commit.part.14+0x640/0x8c0 [zfs]
  [49181.881752]  zil_commit+0x17/0x20 [zfs]
  [49181.881784]  zpl_writepages+0xd5/0x160 [zfs]
  [49181.881787]  do_writepages+0x4b/0xe0
  [49181.881790]  __writeback_single_inode+0x45/0x350
  [49181.881792]  ? __writeback_single_inode+0x45/0x350
  [49181.881794]  writeback_sb_inodes+0x1d7/0x530
  [49181.881796]  wb_writeback+0xfb/0x300
  [49181.881799]  wb_workfn+0xad/0x400
  [49181.881800]  ? wb_workfn+0xad/0x400
  [49181.881803]  ? __switch_to_asm+0x35/0x70
  [49181.881809]  process_one_work+0x1de/0x420
  [49181.881811]  worker_thread+0x32/0x410
  [49181.881813]  kthread+0x121/0x140
  [49181.881815]  ? process_one_work+0x420/0x420
  [49181.881817]  ? kthread_create_worker_on_cpu+0x70/0x70
  [49181.881819]  ret_from_fork+0x35/0x40

  This is caused by a race between ZFS writeback and evict threads,
  usually during a transaction group sync operation. It's possible to
  have two iput() threads racing for the same inode: one of them
  scheduled async and the other executed synchronously as part of the
  writeback path. If the writeback thread tries to evict the inode while
  the async thread is running, it might re-enter the block layer for the
  same inode due to ZFS counters being in an inconsistent state. This
  then causes the kworker thread to stall the writeback, which in turn
  prevents the transaction group sync to complete and locks other ZFS
  threads.

  This is fixed by the upstream commit:
  - Fix zrele race in zrele_async that can cause hang (43eaef6de817) [0]

  [Test Case]
  Being a race condition, this issue has been hard to reproduce consistently. 
This has been reported on heavy I/O workloads, mixing file creation and 
deletion. We have some reports both from upstream and from Ubuntu users that 
this is usually reproducible on e.g. heavy SQL workloads or on complex 
ccache-enabled builds [1].

  [0] https://github.com/openzfs/zfs/pull/11530
  [1] https://github.com/openzfs/zfs/issues/11527

  [Regression Potential]
  The patch has been tested in the ZFS test suite and in

[Kernel-packages] [Bug 1903288] Re: Power guest secure boot with static keys: kernel portion

2021-03-18 Thread Dimitri John Ledkov

Kind of wish for a config option that would do add_to_platform_keyring a
built-in set of keys, until we have something like the other platforms
have (ipl on s390x, uefi db on EFI platforms).

Similar to how the built-in trusted keys are initialized.

-- 
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/1903288

Title:
  Power guest secure boot with static keys: kernel portion

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #2 - Daniel John Axtens  - 2020-11-05 
20:15:10 ==
  This is the kernel side of changes needed for LPAR/guest secure boot.

  Because Ubuntu keeps its kernels so wonderfully up to date, I don't
  think there are any extra patches you need to pick up. (I'll double-
  check against the 21.04 tree once my git pulls finish!)

  However, we potentially need some configuration changes to make sure
  kexec-ing into a crashdump kernel still works.

  Because Lockdown requires that kexec kernels are signed by a key
  trusted by IMA, the public key for used for signing the kdump kernel
  needs to be in the IMA keyring or the platform keyring. For host
  secure boot (and in the UEFI case), it's loaded into the platform
  keyring. But in the case of guest secure boot with static keys, it's
  not loaded into the platform keyring so it needs to be loaded into the
  IMA keyring.

  This is easy enough to do. Firstly, load the Secure Boot CA into the
  .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS
  property. We assume the key used to sign the kernel is signed by this
  CA.

  Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the 
.primary_trusted_keys keyring to be loaded into the IMA keyring. Then set 
IMA_X509_PATH to provide a path to the signing key on installed file system. 
(It may also be possible to do this step in userspace, so long as the CA is 
trusted by the kernel.)
   
  Then that key will be loaded into the .ima keyring at boot and be used to 
appraise the kexec kernel for crashdumps.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1903288] Re: Power guest secure boot with static keys: kernel portion

2021-03-18 Thread Dimitri John Ledkov

this is all very annoying! But I see what you mean now.

We probably should not add opal keys to the trusted_keyring then.

I would rather avoid introducing a new CA key whilst we cannot travel to
assemble and distribute CA shards offline.

I'd rather somehow enable platform_keyring or IMA keyring, and make
kernel have ability to specifies keys listed there at build time and
ship the OPAL key there.

Cause the keys we use to sign kernel image & grub-image, are not the
keys that are used to signed kernel modules, hence shouldn't be in the
trusted kerying.

Or we can end up with a userspace .service that exports trusted_keyrings
and imports them into ima keyring on everyboot. But that would be sad as
well.

Let me find power machines to play around with this.

-- 
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/1903288

Title:
  Power guest secure boot with static keys: kernel portion

Status in The Ubuntu-power-systems project:
  Triaged
Status in linux package in Ubuntu:
  New

Bug description:
  == Comment: #2 - Daniel John Axtens  - 2020-11-05 
20:15:10 ==
  This is the kernel side of changes needed for LPAR/guest secure boot.

  Because Ubuntu keeps its kernels so wonderfully up to date, I don't
  think there are any extra patches you need to pick up. (I'll double-
  check against the 21.04 tree once my git pulls finish!)

  However, we potentially need some configuration changes to make sure
  kexec-ing into a crashdump kernel still works.

  Because Lockdown requires that kexec kernels are signed by a key
  trusted by IMA, the public key for used for signing the kdump kernel
  needs to be in the IMA keyring or the platform keyring. For host
  secure boot (and in the UEFI case), it's loaded into the platform
  keyring. But in the case of guest secure boot with static keys, it's
  not loaded into the platform keyring so it needs to be loaded into the
  IMA keyring.

  This is easy enough to do. Firstly, load the Secure Boot CA into the
  .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS
  property. We assume the key used to sign the kernel is signed by this
  CA.

  Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the 
.primary_trusted_keys keyring to be loaded into the IMA keyring. Then set 
IMA_X509_PATH to provide a path to the signing key on installed file system. 
(It may also be possible to do this step in userspace, so long as the CA is 
trusted by the kernel.)
   
  Then that key will be loaded into the .ima keyring at boot and be used to 
appraise the kexec kernel for crashdumps.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1915003] Re: SRU: Always update the initramfs when changing power profile

2021-03-18 Thread Alberto Milone

All good on Bionic too:

:~$ apt-cache policy nvidia-prime
nvidia-prime:
  Installed: 0.8.16~0.18.04.1
  Candidate: 0.8.16~0.18.04.1
  Version table:
 *** 0.8.16~0.18.04.1 500
500 http://it.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
Packages
500 http://it.archive.ubuntu.com/ubuntu bionic-proposed/main i386 
Packages
100 /var/lib/dpkg/status
 0.8.8.2 500
500 http://it.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
500 http://it.archive.ubuntu.com/ubuntu bionic-updates/main i386 
Packages
 0.8.8 500
500 http://it.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
500 http://it.archive.ubuntu.com/ubuntu bionic/main i386 Packages

:~$ apt-cache policy nvidia-settings
nvidia-settings:
  Installed: 460.39-0ubuntu0.18.04.2
  Candidate: 460.39-0ubuntu0.18.04.2
  Version table:
 *** 460.39-0ubuntu0.18.04.2 500
500 http://it.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
Packages
100 /var/lib/dpkg/status
 440.82-0ubuntu0.18.04.1 500
500 http://it.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
 390.42-0ubuntu1 500
500 http://it.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic

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

Title:
  SRU: Always update the initramfs when changing power profile

Status in NVIDIA Drivers Ubuntu:
  New
Status in OEM Priority Project:
  Triaged
Status in nvidia-prime package in Ubuntu:
  Fix Released
Status in nvidia-settings package in Ubuntu:
  Fix Released
Status in nvidia-prime source package in Bionic:
  Fix Committed
Status in nvidia-settings source package in Bionic:
  Fix Committed
Status in nvidia-prime source package in Focal:
  Fix Released
Status in nvidia-settings source package in Focal:
  Fix Released
Status in nvidia-prime source package in Groovy:
  Fix Released
Status in nvidia-settings source package in Groovy:
  Fix Released

Bug description:
  Since we introduced support for dynamic power management, on systems
  with hybrid graphics (LP: #1904583), the need to load drivers with
  different options has become more evident.

  We need to make sure that the files in the initramfs are in sync with
  the current user selection.

  This is also a chance to update the old nvidia-settings release in the
  archive.

  
  [Impact]

  * If the modules list is not in sync with the selected power profile,
  users may experience a black screen or increased power consumption.

  * Updating the initramfs can take a few seconds, and we need to
  provide users with some form of visual feedback.

  [Fix]

  * The prime-select tool shoud update the initramfs when switching
  between power profiles, and provide visual feedback.

  * The nvidia-settings panel should provide a progress dialog, since
  profile switching would otherwise freeze the UI until update-initramfs
  completes.

  [Test Case]

  Make sure a supported nvidia driver is installed (450, 460), then
  install nvidia-prime and nvidia-settings from proposed, and check the
  following:

  1) prime-select query (to check your current profile)

  2) sudo prime-select on-demand (or "intel", or "nvidia", depending on
  your current power profile)

  3) Check that the operation completes successfully.

  4) Reboot your system

  5) Launch the nvidia-setting panel.

  6) Select a different profile from the PRIME tab, and check that a
  progress dialog is correctly displayed.

  7) Close the nvidia-settings panel, and reboot.

  
  [Regression Risk]
  Medium, while the changes in prime-select are trivial, nvidia-settings needs 
careful testing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nvidia-drivers-ubuntu/+bug/1915003/+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 1891773] Re: kcompactd0 and btrfs-transaction keep deadlocking with each other

2021-03-18 Thread Pierre-Olivier Vallès

Just happened for the second time in 46 hours (and it never happened
before):

kernel: [167836.884337] INFO: task kcompactd0:63 blocked for more than 120 
seconds.
kernel: [167836.887341]   Not tainted 4.15.0-128-generic #131-Ubuntu
kernel: [167836.889880] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
kernel: [167836.893754] kcompactd0  D063  2 0x8000  
kernel: [167836.893760] Call Trace:
kernel: [167836.894017]  __schedule+0x24e/0x880
kernel: [167836.894031]  schedule+0x2c/0x80
kernel: [167836.894034]  io_schedule+0x16/0x40
kernel: [167836.894160]  __lock_page+0xff/0x140
kernel: [167836.894197]  ? page_cache_tree_insert+0xe0/0xe0
kernel: [167836.894246]  migrate_pages+0x91f/0xb80
kernel: [167836.894269]  ? __ClearPageMovable+0x10/0x10  
kernel: [167836.894272]  ? isolate_freepages_block+0x3b0/0x3b0
kernel: [167836.894276]  compact_zone+0x681/0x950
kernel: [167836.894279]  kcompactd_do_work+0xfe/0x2a0
kernel: [167836.894282]  ? __switch_to_asm+0x35/0x70
kernel: [167836.894284]  ? __switch_to_asm+0x41/0x70
kernel: [167836.894288]  kcompactd+0x86/0x1c0
kernel: [167836.894292]  ? kcompactd+0x86/0x1c0
kernel: [167836.894395]  ? wait_woken+0x80/0x80
kernel: [167836.894445]  kthread+0x121/0x140
kernel: [167836.894449]  ? kcompactd_do_work+0x2a0/0x2a0 
kernel: [167836.894452]  ? kthread_create_worker_on_cpu+0x70/0x70
kernel: [167836.894454]  ret_from_fork+0x35/0x40

Message appears every 2 minutes for 18 minutes (then I guess it stops
reporting) ; after that the disk are blocked, then NFS fails, then the
whole service I'm running fails.

It happened twice with kernel 4.15.0-128-generic.

I updated to 4.15.0-137-generic while service was down, let's see how long it 
will work.
HWE kernel is the next step.

-- 
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/1891773

Title:
  kcompactd0 and btrfs-transaction keep deadlocking with each other

Status in linux package in Ubuntu:
  Confirmed
Status in postgresql-11 package in Ubuntu:
  Confirmed

Bug description:
  Example 1:
  [346911.187920] INFO: task kcompactd0:53 blocked for more than 120 seconds.
  [346911.187938]   Not tainted 4.15.0-112-generic #113-Ubuntu
  [346911.187951] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
  [346911.187968] kcompactd0  D053  2 0x8000
  [346911.187969] Call Trace:
  [346911.187973]  __schedule+0x24e/0x880
  [346911.187986]  ? btree_releasepage+0x42/0x50 [btrfs]
  [346911.187987]  schedule+0x2c/0x80
  [346911.187988]  io_schedule+0x16/0x40
  [346911.187989]  __lock_page+0xff/0x140
  [346911.187990]  ? page_cache_tree_insert+0xe0/0xe0
  [346911.187992]  migrate_pages+0x91f/0xb80
  [346911.187993]  ? __ClearPageMovable+0x10/0x10
  [346911.187994]  ? isolate_freepages_block+0x3b0/0x3b0
  [346911.187995]  compact_zone+0x681/0x950
  [346911.187995]  kcompactd_do_work+0xfe/0x2a0
  [346911.187996]  ? __switch_to_asm+0x35/0x70
  [346911.187997]  ? __switch_to_asm+0x41/0x70
  [346911.187998]  kcompactd+0x86/0x1c0
  [346911.187999]  ? kcompactd+0x86/0x1c0
  [346911.188001]  ? wait_woken+0x80/0x80
  [346911.188002]  kthread+0x121/0x140
  [346911.188003]  ? kcompactd_do_work+0x2a0/0x2a0
  [346911.188003]  ? kthread_create_worker_on_cpu+0x70/0x70
  [346911.188004]  ret_from_fork+0x35/0x40

  [346911.188015] INFO: task btrfs-transacti:858 blocked for more than 120 
seconds.
  [346911.188031]   Not tainted 4.15.0-112-generic #113-Ubuntu
  [346911.188043] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
  [346911.188060] btrfs-transacti D0   858  2 0x8000
  [346911.188061] Call Trace:
  [346911.188062]  __schedule+0x24e/0x880
  [346911.188063]  ? bit_wait+0x60/0x60
  [346911.188063]  schedule+0x2c/0x80
  [346911.188064]  io_schedule+0x16/0x40
  [346911.188065]  bit_wait_io+0x11/0x60
  [346911.188066]  __wait_on_bit+0x4c/0x90
  [346911.188066]  ? bit_wait+0x60/0x60
  [346911.188067]  out_of_line_wait_on_bit+0x90/0xb0
  [346911.188068]  ? bit_waitqueue+0x40/0x40
  [346911.188080]  lock_extent_buffer_for_io+0x100/0x2a0 [btrfs]
  [346911.188090]  btree_write_cache_pages+0x1b8/0x420 [btrfs]
  [346911.188092]  ? native_sched_clock_from_tsc+0x30/0x70
  [346911.188092]  ? update_load_avg+0x423/0x780
  [346911.188101]  btree_writepages+0x5d/0x70 [btrfs]
  [346911.188102]  do_writepages+0x4b/0xe0
  [346911.188102]  ? enqueue_task_fair+0xb6/0x300
  [346911.188111]  ? merge_state.part.47+0x44/0x130 [btrfs]
  [346911.188112]  __filemap_fdatawrite_range+0xcf/0x100
  [346911.188113]  ? __filemap_fdatawrite_range+0xcf/0x100
  [346911.188114]  filemap_fdatawrite_range+0x13/0x20
  [346911.188122]  btrfs_write_marked_extents+0x68/0x140 [btrfs]
  [346911.188129]  btrfs_write_and_wait_marked_extents.constprop.20+0x4f/0x90 
[btrfs]
  [346911.188136]  btrfs_commit_transaction+0x696/0x910 [btrfs]
  [346911.188143]  ?

[Kernel-packages] [Bug 1908677] Re: Dell Latitude 9510 capture volume is too low

2021-03-18 Thread Sebastien Bacher

** Changed in: alsa-ucm-conf (Ubuntu)
   Status: New => Fix Committed

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

Title:
  Dell Latitude 9510 capture volume is too low

Status in OEM Priority Project:
  New
Status in alsa-ucm-conf package in Ubuntu:
  Fix Committed

Bug description:
  [Impact]

   * The internal mic default volume is too low
     A upstream commit correct the init configuration

  [Test Case]

   * Using gnome-sound-recoder to record audio without tweak capture volume
     The volume is very low
   * Try to update the init.conf mentioned by
     
https://github.com/alsa-project/alsa-ucm-conf/commit/263bd26b1216c933db3d216197a78678d0f8610e
     $ alsactl init
     $ amixer cget name='rt715 ADC 07 Capture Volume'
     numid=14,iface=MIXER,name='rt715 ADC 07 Capture Volume'
    ; type=INTEGER,access=rw---R--,values=2,min=0,max=63,step=0
    : values=58,58
    | dBscale-min=-17.25dB,step=0.75dB,mute=0

   * Using gnome-sound-recorder to record again
     The volume is significantly improved

  [Where problems could occur]

   * The change only apply to the hardware with rt715 codec.

   * The change adjust the volume only, but not change other control,
     the worst case is the change doesn't take effect.

  [Other Info]

   * The change has been verified on Latitude 9510.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1908677/+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 1871794] Re: [Bluetooth] No audio output/input in HSP/HFP mode

2021-03-18 Thread Nazzareno Marziale

Same problem.
Linux 5.8.0-45-generic #51-Ubuntu SMP Fri Feb 19 13:24:51 UTC 2021 x86_64 
x86_64 x86_64 GNU/Linux
DELL XPS 15 9570

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

Title:
  [Bluetooth] No audio output/input in HSP/HFP mode

Status in bluez package in Ubuntu:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  I'm testing with Sony bluetooth headset SBH20, works fine in A2DP
  profile, but I can't get audio input and output work in HSP/HFP
  profile.

  [Reproduce steps]
  1. Scan and pair BT headset in Bluetooth setting
  2. Switch to HSP/HFP profile in Sound setting
  3. Test sound output/input

  [Machine information]
  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: pulseaudio 1:13.99.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
  Uname: Linux 5.4.0-21-generic x86_64
  ApportVersion: 2.20.11-0ubuntu25
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ubuntu 1359 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Apr  9 16:26:52 2020
  InstallationDate: Installed on 2020-04-09 (0 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200402)
  SourcePackage: pulseaudio
  Symptom: audio
  Symptom_Card: SBH20
  Symptom_DevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ubuntu 1359 F pulseaudio
  Symptom_Type: No sound at all
  Title: [SBH20, recording] No sound at all
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/17/2019
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.0.13
  dmi.board.name: 0188D1
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 31
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.0.13:bd09/17/2019:svnDellInc.:pnXPS1373902-in-1:pvr:rvnDellInc.:rn0188D1:rvrA00:cvnDellInc.:ct31:cvr:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 7390 2-in-1
  dmi.product.sku: 08B0
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1871794/+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 1901363] Re: Updating to 1.2.4-1 breaks pulseaudio on AMD Renoir devices

2021-03-18 Thread Sebastien Bacher

Thank you for your bug report. Is that still an issue? Ubuntu 20.10 has
1.2.2 which isn't the version described, where did you get the update?
Also the upstream bug you referenced state the issue was fixed in alsa-
lib 1.2.4?

** Changed in: alsa-ucm-conf (Ubuntu)
   Status: New => Incomplete

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

Title:
  Updating to 1.2.4-1 breaks pulseaudio on AMD Renoir devices

Status in alsa-ucm-conf package in Ubuntu:
  Incomplete

Bug description:
  same issue on groovy on my Lenovo T14 AMD.
  https://bugs.archlinux.org/task/68313
  already fixed upstream
  https://github.com/alsa-project/alsa-ucm-conf/issues/55

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1901363/+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 1857073] Re: Cavium ThunderX CN88XX Oops at smi_send.isra.4+0x80/0x158 [ipmi_msghandler]

2021-03-18 Thread Andrew Cloke

I understand that there are no further f/w updates planned for these
ThunderX boards. Marking as "won't fix".

** Changed in: linux (Ubuntu)
   Status: Confirmed => Invalid

** Changed in: linux (Ubuntu Bionic)
   Status: Confirmed => Invalid

-- 
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/1857073

Title:
  Cavium ThunderX CN88XX Oops at smi_send.isra.4+0x80/0x158
  [ipmi_msghandler]

Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  Invalid

Bug description:
  Series: Bionic 
  Kernel: 4.15.0-74.84  linux-generic

  The following crash was observed while testing the proposed kernel for the 
2019.12.02 SRU Cycle. 
  This kernel was built to include fixes for the following bugs:

* [Regression] Bionic kernel 4.15.0-71.80 can not boot on ThunderX
  (LP: #1853326)
  - Revert "arm64: Use firmware to detect CPUs that are not affected by
Spectre-v2"
  - Revert "arm64: Get rid of __smccc_workaround_1_hvc_*"

* [Regression] Bionic kernel 4.15.0-71.80 can not boot on ThunderX2 and
  Kunpeng920 (LP: #1852723)
  - SAUCE: arm64: capabilities: Move setup_boot_cpu_capabilities() call to
correct place
  The following crash appears to be a NEW bug. not related to the prior bugs 
listed above.

  system hostname: wright

  Possible Cause: wright's crash possibly is caused by faulty error
  handling in the ipmi driver (notice this in its dmesg: [ 52.150201]
  ipmi_ssif 0-0012: Unable to get the device id: -5)

  [  OK  ] Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch.
  [  OK  ] FounBYZ-011FA0 efi.
   Mounting /boot/[  OK  ] Mounted /boot/efi.
  [  OK  ] Reached target Local File Systems.
   Starting Set console font and keymap...
   Starting Create Volatile Files and Directories...
   Starting ebtables ruleset management...
   Starting AppArmor initialization...
   Starting Tell Plymouth To Write Out Runtime Data...
  [  OK  nsole font and keymap.
  [  OK  ] Started Tell Plymouth To Write Out Runtime Data.
  [  OK  ] Started Create Volatile Files and Directories.
   Starting Network Time Synchronization...
   Starting Update UTMP about Syst
  [  OK  ] Started Update UTMP utdown.
  [  OK  ] Started ebtables ruleset management.
  [  OK  ] Starnization.
  [  OK  ] Reached target System Time Synchronized.
  [  OK  ] Started AppArmor initialization.
  [   50.689136] cloud-init[1246]: Cloud-init v. 
19.3-41-gc4735dd3-0ubuntu1~18.04.1 running 'init-local' at Thu, 19 Dec 20 50.28 
seconds.
  [   50.712486] cloud-init[1246]: 2019-12-19 22:40:37,893 - 
handlers.py[WARNING]: failed posting event: start: init-local/check-cache: 
attempting to read from cache [trust]
  [   50.736307] cloud-init[1246]: 2019-12-19 22:40:37,941 - 
handlers.py[WARNING]: failed posting event: finish: init-local/check-cache: 
SUCCESS: restored from cache: DataSourceMAAS 
[http://10.229.32.21:5248/MAAS/metadata/]
  [   51.244224] cloud-init[1246]: 2019-12-19 22:40:38,450 - 
handlers.py[WARNING]: failed posting event: finish: init-local: SUCCESS: 
searching for local datasources
  [  OK  ] Started Initial cloud-init job (pre-networking).
  [  OK  ] Reached target Network (Pre).
   Starting Network Service...
  [  OK  ] Started Network Service.
   Starting Wait for Network to be Configured...
   Starting Network Name Resolution...
  [   52.150201] ipmi_ssif 0-0012: Unable to get the device id: -5
  [   52.300309] Unable to handle kernel read fromvirtual address 0018
  [   52.311284] Mem abort info:
  [   52.316895]  604
  [   52.322622]   Exception class = DABT (current EL), IL = 32 bits
  [   52.331061]   SET = 0, FnV = 0
  [   52.336639]   EA = 0, S1PTW = 0
  [   52.342311] Data abort info:
  [   52.347731]   ISV = 0, ISS = 0x0004
  [   52.354131]   CM = 0, WnR = 0
  [   52.359739] user pgtable: 4k pages, 48-bit VAs, pgd = 44052f71
  [   52.368909] [0018] *pgd=
  [   52.376522] Internal error: Oops: 9604 [#1] SMP
  [   52.384039] Modules linked in: nls_iso8859_1 thunderx_edac thunderx_zip 
cavium_rng_vf shpchp cavium_rng gpio_keys uio_pdrv_genirq uio ipmi_ssif(+) 
ipmi_devintf ipmi_msghandler sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core 
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 
btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq 
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear nicvf 
nicpf ast i2c_algo_bit aes_ce_blk ttm aes_ce_cipher crc32_ce drm_kms_helper 
crct10dif_ce ghash_ce syscopyarea sha2_ce sysfillrect sysimgblt sha256_arm64 
fb_sys_fops thunder_bgx sha1_ce drm ahci libahci thunder_xcv i2c_thunderx 
mdio_thunder thunderx_mmc mdio_cavium aes_neon_bs aes_neon_blk crypto_simd 
cryptd aes_arm64
  [   52.473094]

[Kernel-packages] [Bug 1919478] Re: Invalid /proc/cpuinfo on arm64

2021-03-18 Thread Juerg Haefliger

The behavior is actually as expected. The 'model name' is only displayed
in 32-bit mode (same behavior as upstream kernel.org). And the Hardware
is hard-coded to BCM2835 on arm64 by an upstream raspberrypi commit.


** Changed in: linux-raspi (Ubuntu Hirsute)
   Status: Confirmed => Won't Fix

** Changed in: linux-raspi (Ubuntu Hirsute)
   Status: Won't Fix => Invalid

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

Title:
  Invalid /proc/cpuinfo on arm64

Status in linux-raspi package in Ubuntu:
  Confirmed
Status in linux-raspi source package in Hirsute:
  Invalid

Bug description:
  Hardware BCM2835 is incorrect and model name is missing on arm64:

  $ uname -a
  Linux rpi-4b-rev1d2-2c1a 5.11.0-1003-raspi #3-Ubuntu SMP PREEMPT Thu Mar 4 
14:53:05 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

  $ cat /proc/cpuinfo | tail -15
  CPU revision  : 3

  processor : 3
  BogoMIPS  : 108.00
  Features  : fp asimd evtstrm crc32 cpuid
  CPU implementer   : 0x41
  CPU architecture: 8
  CPU variant   : 0x0
  CPU part  : 0xd08
  CPU revision  : 3

  Hardware  : BCM2835
  Revision  : c03112
  Serial: 1000519d2c1a
  Model : Raspberry Pi 4 Model B Rev 1.2

  Correct info on armhf:

  $ uname -a
  Linux rpi-4b-rev1d1-17cf 5.11.0-1003-raspi #3-Ubuntu SMP PREEMPT Thu Mar 4 
14:58:03 UTC 2021 armv7l armv7l armv7l GNU/Linux

  $ cat /proc/cpuinfo | tail -15

  processor : 3
  model name: ARMv7 Processor rev 3 (v7l)
  BogoMIPS  : 216.00
  Features  : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
vfpd32 lpae evtstrm crc32 
  CPU implementer   : 0x41
  CPU architecture: 7
  CPU variant   : 0x0
  CPU part  : 0xd08
  CPU revision  : 3

  Hardware  : BCM2711
  Revision  : c03111
  Serial: 10003c2d17cf
  Model : Raspberry Pi 4 Model B Rev 1.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1919478/+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 1553669] Re: Annoying "call from" message when connecting Bose devices

2021-03-18 Thread Daniel van Vugt

I suggest you should report it to the developers of PulseAudio since
that's the component that implements Bluetooth audio:

  https://gitlab.freedesktop.org/groups/pulseaudio/-/issues

Less likely, you might need to report it to the BlueZ Bluetooth
developers:

https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers=Bluetooth

When done, please tell us the new issue ID here.

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

Title:
  Annoying "call from" message when connecting Bose devices

Status in bluez package in Ubuntu:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  I have a bluetooth Bose OE SoundLink working on Kubuntu 15.10 but each
  time I initially connect to listen to an audio or video, I hear an
  annoying "Call from" on my headset. My headset seems to think a
  connection to a phone call is taking place. This is annoying because
  the audio will start to play and after a little while the "call from"
  voice talks over the audio.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1553669/+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 1919973] [NEW] Enable CONFIG_GPIO_CDEV_V1

2021-03-18 Thread Juerg Haefliger

Public bug reported:

A new gpio userspace package is being introduced in Hirsute:
https://bugs.launchpad.net/bugs/1916901

That library is still using the old v1 gpio uAPI, so let's enable it in
the 5.11 kernel.

** Affects: linux-raspi (Ubuntu)
 Importance: Undecided
 Status: Fix Committed

** Affects: linux-raspi (Ubuntu Hirsute)
 Importance: Undecided
 Status: Fix Committed

** Also affects: linux-raspi (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Changed in: linux-raspi (Ubuntu Hirsute)
   Status: New => Fix Committed

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

Title:
  Enable CONFIG_GPIO_CDEV_V1

Status in linux-raspi package in Ubuntu:
  Fix Committed
Status in linux-raspi source package in Hirsute:
  Fix Committed

Bug description:
  A new gpio userspace package is being introduced in Hirsute:
  https://bugs.launchpad.net/bugs/1916901

  That library is still using the old v1 gpio uAPI, so let's enable it
  in the 5.11 kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1919973/+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 1553669] Re: Annoying "call from" message when connecting Bose devices

2021-03-18 Thread Ninj

2021, Ubuntu 20.04.2 and this is still not fixed.

Some answers here don't seem acceptable. We keep getting advised to turn
voice notifications off. Well, that's a headset feature I needed, and
even made me buy this Bose. We probably like or need the voice
notification, you cannot just suggest to remove the safety belt in your
car if it's blocked.

Windows handles the bluetooth much better in my opinion, so what is the
difference? Can't the BT behaviour just be reproduced on Ubuntu? Why
does A2DP prevents the mic from being used? Or why does the HSP format
introduces the "Call from"..." message? How does Windows allows to both
use the mic and have no voice message?

Well, I believe Windows uses some kind of mode called "Communication",
which must be selected on both input and output. At least that's what I
do and it works smoothly. Would that be a hint?

This bug is very annoying however, and still not assigned to anyone. I
don't get that (QC35 is the most used headset at work in the world I
think)

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

Title:
  Annoying "call from" message when connecting Bose devices

Status in bluez package in Ubuntu:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  I have a bluetooth Bose OE SoundLink working on Kubuntu 15.10 but each
  time I initially connect to listen to an audio or video, I hear an
  annoying "Call from" on my headset. My headset seems to think a
  connection to a phone call is taking place. This is annoying because
  the audio will start to play and after a little while the "call from"
  voice talks over the audio.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1553669/+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 1919930] Re: power off stress test will hang on the TGL machines

2021-03-18 Thread Hui Wang

** Tags added: originate-from-1906747

-- 
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/1919930

Title:
  power off stress test will hang on the TGL machines

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem-5.10 package in Ubuntu:
  In Progress
Status in linux-oem-5.10 source package in Focal:
  In Progress
Status in linux source package in Groovy:
  In Progress
Status in linux source package in Hirsute:
  In Progress

Bug description:
  Intel suggested that we do 2 actions to fix this problem, the 1st is
  merging 5 kernel patches, this only applies to H and OEM-5.10 since
  there is no tgl.c in the groovy kernel yet. the 2nd is change a kernel
  config, this change applies to H, G and OEM-5.10.

  https://github.com/thesofproject/linux/issues/2781

  [Impact]
  When we run poweroff/on stress test on some lenovo TGL laptop, the
  system will randomly hang, and when this issue happens, the dmesg
  shows the sof audio driver fails.

  [Fix]
  Intel recommend that we backport 5 kernel patches and change a
  kernel config.

  [Test]
  After applying the changes, and test on TGL/cml/whl machines,
  the audio function works as good as before, and the poweroff stress
  test didn't hang anymore.

  
  [Where problems could occur]
  The kernel patches probably could introduce issues when system
  powre off or reboot on TGL machines, but this possibility is low
  since we have tested these patches on different TGL machines.

  the kernel option change could introduce power consumption
  regression, but it only affects power saving and package_cstate values
  when any capture stream is active, while no impact if all capture
  streams are inactive. that is to say, in theory it will not impact
  the power consumption in short idle or long idle. And I checked the
  system cound enter package_c10 after this change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1919930/+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 1916988] Re: Internal microphone not being recognized on Lenovo Yoga Slim 7 after kernel upgrade

2021-03-18 Thread Nu Pot

This https://github.com/jrandiny/yoga-slim7-ubuntu#Microphone got the
microphone to work again

-- 
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/1916988

Title:
  Internal microphone not being recognized on Lenovo Yoga Slim 7 after
  kernel upgrade

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After updating some packages which included a new version of kernel
  (5.8.0-44-generic) the internal microphone of my Lenovo Yoga Slim 7
  does not work anymore and it doesn't seem to be recognized in
  Settings->Sound (I attached a screenshot)

  1. ~$ lsb_release -rd
  Description:  Ubuntu 20.04.2 LTS
  Release:  20.04

  2. ~# apt-cache policy linux-image-5.8.0-44-generic
  linux-image-5.8.0-44-generic:
Installed: 5.8.0-44.50~20.04.1
Candidate: 5.8.0-44.50~20.04.1
Version table:
   *** 5.8.0-44.50~20.04.1 500
  500 http://at.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu focal-security/main amd64 
Packages
  100 /var/lib/dpkg/status

  3. Expected internal microphone to work
  4. Internal microphone not working
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  stefan 1690 F pulseaudio
   /dev/snd/controlC0:  stefan 1690 F pulseaudio
  CasperMD5CheckResult: skip
  DistroRelease: Ubuntu 20.04
  InstallationDate: Installed on 2021-02-15 (10 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  MachineType: LENOVO 82A2
  Package: linux (not installed)
  ProcFB: 0 amdgpudrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-44-generic 
root=UUID=06bbabdd-494d-48b9-b17e-31cb56c8ff0f ro quiet splash 
mem_sleep_default=deep vt.handoff=7
  ProcVersionSignature: Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions:
   linux-restricted-modules-5.8.0-44-generic N/A
   linux-backports-modules-5.8.0-44-generic  N/A
   linux-firmware1.187.9
  Tags:  focal
  Uname: Linux 5.8.0-44-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: N/A
  _MarkForUpload: False
  dmi.bios.date: 01/18/2020
  dmi.bios.release: 1.38
  dmi.bios.vendor: LENOVO
  dmi.bios.version: DMCN38WW
  dmi.board.asset.tag: ���
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40709 WIN
  dmi.chassis.asset.tag: ���
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Yoga Slim 7 14ARE05
  dmi.ec.firmware.release: 1.29
  dmi.modalias: 
dmi:bvnLENOVO:bvrDMCN38WW:bd01/18/2020:br1.38:efr1.29:svnLENOVO:pn82A2:pvrYogaSlim714ARE05:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrYogaSlim714ARE05:
  dmi.product.family: Yoga Slim 7 14ARE05
  dmi.product.name: 82A2
  dmi.product.sku: LENOVO_MT_82A2_BU_idea_FM_Yoga Slim 7 14ARE05
  dmi.product.version: Yoga Slim 7 14ARE05
  dmi.sys.vendor: LENOVO
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  stefan 1690 F pulseaudio
   /dev/snd/controlC0:  stefan 1690 F pulseaudio
  CasperMD5CheckResult: skip
  DistroRelease: Ubuntu 20.04
  InstallationDate: Installed on 2021-02-15 (10 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  PackageArchitecture: all
  ProcVersionSignature: Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  Tags: third-party-packages focal
  Uname: Linux 5.8.0-44-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: N/A
  _MarkForUpload: True
  dmi.bios.date: 01/18/2020
  dmi.bios.release: 1.38
  dmi.bios.vendor: LENOVO
  dmi.bios.version: DMCN38WW
  dmi.board.asset.tag: ���
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40709 WIN
  dmi.chassis.asset.tag: ���
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Yoga Slim 7 14ARE05
  dmi.ec.firmware.release: 1.29
  dmi.modalias: 
dmi:bvnLENOVO:bvrDMCN38WW:bd01/18/2020:br1.38:efr1.29:svnLENOVO:pn82A2:pvrYogaSlim714ARE05:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrYogaSlim714ARE05:
  dmi.product.family: Yoga Slim 7 14ARE05
  dmi.product.name: 82A2
  dmi.product.sku: LENOVO_MT_82A2_BU_idea_FM_Yoga Slim 7 14ARE05

[Kernel-packages] [Bug 1830151] Re: ebb: cycles_test in powerpc from ubuntu_kernel_selftests failed on B-hwe P9