from:"Ioanna Alifieraki"

#VERIFICATION BIONIC

$ uname -rv
4.15.0-92-generic #93-Ubuntu SMP Mon Mar 16 19:44:23 UTC 2020

Executing the reproducer found in [1] 100 times the bug does not
reproduce.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

** Bug watch added: Red Hat Bugzilla #1694779
   https://bugzilla.redhat.com/show_bug.cgi?id=1694779

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

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

Title:
  ipc/sem.c : process loops infinitely in exit_sem()

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Disco:
  Fix Committed
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Released

Bug description:
  [Description]

  Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage
  in exit_sem()") removes a lock that is needed. This leads to a process
  looping infinitely in exit_sem() and can also lead to a crash.

  [Test case]

  Using the reproducer found in [1] is fairly easy to reach a point where
  one of the child processes is looping infinitely in exit_sem between
  for(;;) and if (semid == -1) block, while it's trying to free its last
  sem_undo structure which has already been freed by freeary().

  Once commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock
  usage in exit_sem()") the issue is not reproducible any more.

  [Other]

  Patch submitted upstream :
  https://lkml.org/lkml/2019/12/11/1718

  
  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1858834/+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 1858834] Re: ipc/sem.c : process loops infinitely in exit_sem()

#VERIFICATION EOAN

$ uname -rv
5.3.0-43-generic #36-Ubuntu SMP Mon Mar 16 13:29:01 UTC 2020


Executing the reproducer found in [1] 1000 times the bug does not reproduce.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

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

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

Title:
  ipc/sem.c : process loops infinitely in exit_sem()

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Disco:
  Fix Committed
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Released

Bug description:
  [Description]

  Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage
  in exit_sem()") removes a lock that is needed. This leads to a process
  looping infinitely in exit_sem() and can also lead to a crash.

  [Test case]

  Using the reproducer found in [1] is fairly easy to reach a point where
  one of the child processes is looping infinitely in exit_sem between
  for(;;) and if (semid == -1) block, while it's trying to free its last
  sem_undo structure which has already been freed by freeary().

  Once commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock
  usage in exit_sem()") the issue is not reproducible any more.

  [Other]

  Patch submitted upstream :
  https://lkml.org/lkml/2019/12/11/1718

  
  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1858834/+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 1858834] Re: ipc/sem.c : process loops infinitely in exit_sem()

#VERIFICATION XENIAL

$ uname -rv
4.4.0-177-generic #207-Ubuntu SMP Mon Mar 16 01:16:10 UTC 2020

Executing the reproducer found in [1] 1000 times the bug does not
reproduce.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

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

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

Title:
  ipc/sem.c : process loops infinitely in exit_sem()

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Disco:
  Fix Committed
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Released

Bug description:
  [Description]

  Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage
  in exit_sem()") removes a lock that is needed. This leads to a process
  looping infinitely in exit_sem() and can also lead to a crash.

  [Test case]

  Using the reproducer found in [1] is fairly easy to reach a point where
  one of the child processes is looping infinitely in exit_sem between
  for(;;) and if (semid == -1) block, while it's trying to free its last
  sem_undo structure which has already been freed by freeary().

  Once commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock
  usage in exit_sem()") the issue is not reproducible any more.

  [Other]

  Patch submitted upstream :
  https://lkml.org/lkml/2019/12/11/1718

  
  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1858834/+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 1858834] Re: ipc/sem.c : process loops infinitely in exit_sem()

#VERIFICATION FOCAL

$ uname -rv
5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 2020

Executing the reproducer found in [1] 1000 times the bug does not
reproduce.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

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

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

Title:
  ipc/sem.c : process loops infinitely in exit_sem()

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Disco:
  Fix Committed
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Released

Bug description:
  [Description]

  Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage
  in exit_sem()") removes a lock that is needed. This leads to a process
  looping infinitely in exit_sem() and can also lead to a crash.

  [Test case]

  Using the reproducer found in [1] is fairly easy to reach a point where
  one of the child processes is looping infinitely in exit_sem between
  for(;;) and if (semid == -1) block, while it's trying to free its last
  sem_undo structure which has already been freed by freeary().

  Once commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock
  usage in exit_sem()") the issue is not reproducible any more.

  [Other]

  Patch submitted upstream :
  https://lkml.org/lkml/2019/12/11/1718

  
  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1858834/+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 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

** Description changed:

+ [Impact]
+ 
+ On some arm systems makedumpfile fails to translate virtual to physical 
addresses properly.
+ This may result in makedumpfile looping forever exhausting
+ all memory, or  translating a virtual address to an invalid physical address 
+ and then failing and falling back to cp.
+ The reason it cannot resolve some addresses is because the PMD mask is wrong. 
+ When physical address mask allows up to 48bits pmd mask should allow the
+ same, currently pmd mask is set to 40bits (see commit [1]).
+ 
+ Commit [1] fixes this bug.
+ 
+ [Test Case]
+ 
+ To hit this bug you need a system that needs physical addresses over 1TB.
+ This may be either because you have a lot
+ of memory or because the firmware mapped some memory above 1TB for some
+ reason [1].
+ 
+ A user hit this bug because firmware mapped memory above 1TB and provided a 
+ dump so I could reproduce the bug when running makedumpfile on the dump.
+ 
+ [Regression Potential]
+ 
+ This commit changes the PMD_SECTION_MASK for arm64. So any regression 
potential
+ would only affect arm64 systems. In addition PMD_SECTION_MASK is used in 
translation
+ from virtual to physical addresses and therefore any regression would happen 
during
+ this process.
+ 
+ [Other]
+ 
+ [1]
+ 
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b
+ 
+ 
  When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. 
The test steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The logs are as follows:
  
  kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 
/proc/vmcore /var/crash/202003251128/dump-incomplete
  kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0
  kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8
  kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud
  kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to 
physical address.
  kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032
  kdump-tools[646]: validate_mem_section: Can't read mem_section array.
  kdump-tools[646]: get_mem_section: Could not validate mem_section.
  kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section.
  kdump-tools[646]: makedumpfile Failed.
  kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp'
  
  But when I use the HWE kernel, I find that there is no such problem.
  The HEW kernel version: 5.3.0-42-generic

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

Title:
  Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

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

Bug description:
  [Impact]

  On some arm systems makedumpfile fails to translate virtual to physical 
addresses properly.
  This may result in makedumpfile looping forever exhausting
  all memory, or  translating a virtual address to an invalid physical address 
  and then failing and falling back to cp.
  The reason it cannot resolve some addresses is because the PMD mask is wrong. 
  When physical address mask allows up to 48bits pmd mask should allow the
  same, currently pmd mask is set to 40bits (see commit [1]).

  Commit [1] fixes this bug.

  [Test Case]

  To hit this bug you need a system that needs physical addresses over 1TB.
  This may be either because you have a lot
  of memory or because the firmware mapped some memory above 1TB for some
  reason [1].

  A user hit this bug because firmware mapped memory above 1TB and provided a 
  dump so I could reproduce the bug when running makedumpfile on the dump.

  [Regression Potential]

  This commit changes the PMD_SECTION_MASK for arm64. So any regression 
potential
  would only affect arm64 systems. In addition PMD_SECTION_MASK is used in 
translation
  from virtual to physical addresses and therefore any regression would happen 
during
  this process.

  [Other]

  [1]
  
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b

  
  When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. 
The test steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The logs are as follows:

  kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 
/proc/vmcore /var/crash/202003251128/dump-incomplete
  kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0
  kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8
  kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud
  kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to 
physical address.
  kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032
  kdump-tools[646]: validate_mem_section: Can't read mem_section arr

[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

** Bug watch added: Debian Bug tracker #96
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=96

** Also affects: linux (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=96
   Importance: Unknown
   Status: Unknown

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

Title:
  Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Bionic:
  Confirmed
Status in linux package in Debian:
  Unknown

Bug description:
  [Impact]

  On some arm systems makedumpfile fails to translate virtual to physical 
addresses properly.
  This may result in makedumpfile looping forever exhausting
  all memory, or  translating a virtual address to an invalid physical address 
  and then failing and falling back to cp.
  The reason it cannot resolve some addresses is because the PMD mask is wrong. 
  When physical address mask allows up to 48bits pmd mask should allow the
  same, currently pmd mask is set to 40bits (see commit [1]).

  Commit [1] fixes this bug.

  [Test Case]

  To hit this bug you need a system that needs physical addresses over 1TB.
  This may be either because you have a lot
  of memory or because the firmware mapped some memory above 1TB for some
  reason [1].

  A user hit this bug because firmware mapped memory above 1TB and provided a 
  dump so I could reproduce the bug when running makedumpfile on the dump.

  [Regression Potential]

  This commit changes the PMD_SECTION_MASK for arm64. So any regression 
potential
  would only affect arm64 systems. In addition PMD_SECTION_MASK is used in 
translation
  from virtual to physical addresses and therefore any regression would happen 
during
  this process.

  [Other]

  [1]
  
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b

  
  When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. 
The test steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The logs are as follows:

  kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 
/proc/vmcore /var/crash/202003251128/dump-incomplete
  kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0
  kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8
  kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud
  kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to 
physical address.
  kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032
  kdump-tools[646]: validate_mem_section: Can't read mem_section array.
  kdump-tools[646]: get_mem_section: Could not validate mem_section.
  kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section.
  kdump-tools[646]: makedumpfile Failed.
  kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp'

  But when I use the HWE kernel, I find that there is no such problem.
  The HEW kernel version: 5.3.0-42-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+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 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

Debdiff for Groovy

** Also affects: linux (Ubuntu Groovy)
   Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
   Status: Confirmed

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

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

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

** Patch added: "lp1869465_groovy.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380399/+files/lp1869465_groovy.debdiff

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

Title:
  Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Bionic:
  In Progress
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress
Status in linux source package in Groovy:
  In Progress
Status in linux package in Debian:
  Unknown

Bug description:
  [Impact]

  On some arm systems makedumpfile fails to translate virtual to physical 
addresses properly.
  This may result in makedumpfile looping forever exhausting
  all memory, or  translating a virtual address to an invalid physical address 
  and then failing and falling back to cp.
  The reason it cannot resolve some addresses is because the PMD mask is wrong. 
  When physical address mask allows up to 48bits pmd mask should allow the
  same, currently pmd mask is set to 40bits (see commit [1]).

  Commit [1] fixes this bug.

  [Test Case]

  To hit this bug you need a system that needs physical addresses over 1TB.
  This may be either because you have a lot
  of memory or because the firmware mapped some memory above 1TB for some
  reason [1].

  A user hit this bug because firmware mapped memory above 1TB and provided a 
  dump so I could reproduce the bug when running makedumpfile on the dump.

  [Regression Potential]

  This commit changes the PMD_SECTION_MASK for arm64. So any regression 
potential
  would only affect arm64 systems. In addition PMD_SECTION_MASK is used in 
translation
  from virtual to physical addresses and therefore any regression would happen 
during
  this process.

  [Other]

  [1]
  
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b

  
  When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. 
The test steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The logs are as follows:

  kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 
/proc/vmcore /var/crash/202003251128/dump-incomplete
  kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0
  kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8
  kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud
  kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to 
physical address.
  kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032
  kdump-tools[646]: validate_mem_section: Can't read mem_section array.
  kdump-tools[646]: get_mem_section: Could not validate mem_section.
  kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section.
  kdump-tools[646]: makedumpfile Failed.
  kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp'

  But when I use the HWE kernel, I find that there is no such problem.
  The HEW kernel version: 5.3.0-42-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+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 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

Debdiff for Focal

** Patch added: "lp1869465_focal.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380401/+files/lp1869465_focal.debdiff

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

Title:
  Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Bionic:
  In Progress
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress
Status in linux source package in Groovy:
  In Progress
Status in linux package in Debian:
  Unknown

Bug description:
  [Impact]

  On some arm systems makedumpfile fails to translate virtual to physical 
addresses properly.
  This may result in makedumpfile looping forever exhausting
  all memory, or  translating a virtual address to an invalid physical address 
  and then failing and falling back to cp.
  The reason it cannot resolve some addresses is because the PMD mask is wrong. 
  When physical address mask allows up to 48bits pmd mask should allow the
  same, currently pmd mask is set to 40bits (see commit [1]).

  Commit [1] fixes this bug.

  [Test Case]

  To hit this bug you need a system that needs physical addresses over 1TB.
  This may be either because you have a lot
  of memory or because the firmware mapped some memory above 1TB for some
  reason [1].

  A user hit this bug because firmware mapped memory above 1TB and provided a 
  dump so I could reproduce the bug when running makedumpfile on the dump.

  [Regression Potential]

  This commit changes the PMD_SECTION_MASK for arm64. So any regression 
potential
  would only affect arm64 systems. In addition PMD_SECTION_MASK is used in 
translation
  from virtual to physical addresses and therefore any regression would happen 
during
  this process.

  [Other]

  [1]
  
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b

  
  When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. 
The test steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The logs are as follows:

  kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 
/proc/vmcore /var/crash/202003251128/dump-incomplete
  kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0
  kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8
  kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud
  kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to 
physical address.
  kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032
  kdump-tools[646]: validate_mem_section: Can't read mem_section array.
  kdump-tools[646]: get_mem_section: Could not validate mem_section.
  kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section.
  kdump-tools[646]: makedumpfile Failed.
  kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp'

  But when I use the HWE kernel, I find that there is no such problem.
  The HEW kernel version: 5.3.0-42-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+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 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

Debdiff for Xenial

** Patch added: "lp1869465_xenial.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380404/+files/lp1869465_xenial.debdiff

** Tags added: sts

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

Title:
  Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Bionic:
  In Progress
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress
Status in linux source package in Groovy:
  In Progress
Status in linux package in Debian:
  Unknown

Bug description:
  [Impact]

  On some arm systems makedumpfile fails to translate virtual to physical 
addresses properly.
  This may result in makedumpfile looping forever exhausting
  all memory, or  translating a virtual address to an invalid physical address 
  and then failing and falling back to cp.
  The reason it cannot resolve some addresses is because the PMD mask is wrong. 
  When physical address mask allows up to 48bits pmd mask should allow the
  same, currently pmd mask is set to 40bits (see commit [1]).

  Commit [1] fixes this bug.

  [Test Case]

  To hit this bug you need a system that needs physical addresses over 1TB.
  This may be either because you have a lot
  of memory or because the firmware mapped some memory above 1TB for some
  reason [1].

  A user hit this bug because firmware mapped memory above 1TB and provided a 
  dump so I could reproduce the bug when running makedumpfile on the dump.

  [Regression Potential]

  This commit changes the PMD_SECTION_MASK for arm64. So any regression 
potential
  would only affect arm64 systems. In addition PMD_SECTION_MASK is used in 
translation
  from virtual to physical addresses and therefore any regression would happen 
during
  this process.

  [Other]

  [1]
  
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b

  
  When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. 
The test steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The logs are as follows:

  kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 
/proc/vmcore /var/crash/202003251128/dump-incomplete
  kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0
  kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8
  kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud
  kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to 
physical address.
  kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032
  kdump-tools[646]: validate_mem_section: Can't read mem_section array.
  kdump-tools[646]: get_mem_section: Could not validate mem_section.
  kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section.
  kdump-tools[646]: makedumpfile Failed.
  kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp'

  But when I use the HWE kernel, I find that there is no such problem.
  The HEW kernel version: 5.3.0-42-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+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 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

Debdiff for Bionic

** Patch added: "lp1869465_bionic.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380403/+files/lp1869465_bionic.debdiff

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

Title:
  Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Bionic:
  In Progress
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress
Status in linux source package in Groovy:
  In Progress
Status in linux package in Debian:
  Unknown

Bug description:
  [Impact]

  On some arm systems makedumpfile fails to translate virtual to physical 
addresses properly.
  This may result in makedumpfile looping forever exhausting
  all memory, or  translating a virtual address to an invalid physical address 
  and then failing and falling back to cp.
  The reason it cannot resolve some addresses is because the PMD mask is wrong. 
  When physical address mask allows up to 48bits pmd mask should allow the
  same, currently pmd mask is set to 40bits (see commit [1]).

  Commit [1] fixes this bug.

  [Test Case]

  To hit this bug you need a system that needs physical addresses over 1TB.
  This may be either because you have a lot
  of memory or because the firmware mapped some memory above 1TB for some
  reason [1].

  A user hit this bug because firmware mapped memory above 1TB and provided a 
  dump so I could reproduce the bug when running makedumpfile on the dump.

  [Regression Potential]

  This commit changes the PMD_SECTION_MASK for arm64. So any regression 
potential
  would only affect arm64 systems. In addition PMD_SECTION_MASK is used in 
translation
  from virtual to physical addresses and therefore any regression would happen 
during
  this process.

  [Other]

  [1]
  
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b

  
  When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. 
The test steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The logs are as follows:

  kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 
/proc/vmcore /var/crash/202003251128/dump-incomplete
  kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0
  kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8
  kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud
  kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to 
physical address.
  kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032
  kdump-tools[646]: validate_mem_section: Can't read mem_section array.
  kdump-tools[646]: get_mem_section: Could not validate mem_section.
  kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section.
  kdump-tools[646]: makedumpfile Failed.
  kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp'

  But when I use the HWE kernel, I find that there is no such problem.
  The HEW kernel version: 5.3.0-42-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+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 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

Debdiff for Eoan

** Patch added: "lp1869465_eoan.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380402/+files/lp1869465_eoan.debdiff

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

Title:
  Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Bionic:
  In Progress
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress
Status in linux source package in Groovy:
  In Progress
Status in linux package in Debian:
  Unknown

Bug description:
  [Impact]

  On some arm systems makedumpfile fails to translate virtual to physical 
addresses properly.
  This may result in makedumpfile looping forever exhausting
  all memory, or  translating a virtual address to an invalid physical address 
  and then failing and falling back to cp.
  The reason it cannot resolve some addresses is because the PMD mask is wrong. 
  When physical address mask allows up to 48bits pmd mask should allow the
  same, currently pmd mask is set to 40bits (see commit [1]).

  Commit [1] fixes this bug.

  [Test Case]

  To hit this bug you need a system that needs physical addresses over 1TB.
  This may be either because you have a lot
  of memory or because the firmware mapped some memory above 1TB for some
  reason [1].

  A user hit this bug because firmware mapped memory above 1TB and provided a 
  dump so I could reproduce the bug when running makedumpfile on the dump.

  [Regression Potential]

  This commit changes the PMD_SECTION_MASK for arm64. So any regression 
potential
  would only affect arm64 systems. In addition PMD_SECTION_MASK is used in 
translation
  from virtual to physical addresses and therefore any regression would happen 
during
  this process.

  [Other]

  [1]
  
https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b

  
  When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. 
The test steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The logs are as follows:

  kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 
/proc/vmcore /var/crash/202003251128/dump-incomplete
  kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0
  kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8
  kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud
  kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to 
physical address.
  kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032
  kdump-tools[646]: validate_mem_section: Can't read mem_section array.
  kdump-tools[646]: get_mem_section: Could not validate mem_section.
  kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section.
  kdump-tools[646]: makedumpfile Failed.
  kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp'

  But when I use the HWE kernel, I find that there is no such problem.
  The HEW kernel version: 5.3.0-42-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+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 1850950] [NEW] autofs module missing from linux-modules in 5+ kernels

2019-11-01 Thread Ioanna Alifieraki

Public bug reported:

Commit a2225d931f75ddd3c39f4d0d195fad99dfd68671 removes fs/autofs4 path
and replaces it with fs/autofs. This results in the autfs module ending
up in linux-modules-extra package. Update the aws.inclusion-list with
the correct path.

This issue has been addressed for the generic kernels (see lp 1824333).
This fixes it for the aws kernels.

** Affects: linux-aws (Ubuntu)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

** Affects: linux-aws (Ubuntu Disco)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

** Affects: linux-aws (Ubuntu Eoan)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

** Affects: linux-aws (Ubuntu Focal)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

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

** Also affects: linux-aws (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: linux-aws (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Changed in: linux-aws (Ubuntu Disco)
   Status: New => Confirmed

** Changed in: linux-aws (Ubuntu Eoan)
   Status: New => Confirmed

** Changed in: linux-aws (Ubuntu Focal)
   Status: New => Confirmed

** Changed in: linux-aws (Ubuntu Disco)
   Importance: Undecided => Medium

** Changed in: linux-aws (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: linux-aws (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: linux-aws (Ubuntu Disco)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux-aws (Ubuntu Eoan)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux-aws (Ubuntu Focal)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

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

Title:
  autofs module missing from linux-modules in 5+ kernels

Status in linux-aws package in Ubuntu:
  Confirmed
Status in linux-aws source package in Disco:
  Confirmed
Status in linux-aws source package in Eoan:
  Confirmed
Status in linux-aws source package in Focal:
  Confirmed

Bug description:
  Commit a2225d931f75ddd3c39f4d0d195fad99dfd68671 removes fs/autofs4 path
  and replaces it with fs/autofs. This results in the autfs module ending
  up in linux-modules-extra package. Update the aws.inclusion-list with
  the correct path.

  This issue has been addressed for the generic kernels (see lp 1824333).
  This fixes it for the aws kernels.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-aws/+bug/1850950/+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 1851243] [NEW] overlayfs : broken access to r/w files

2019-11-04 Thread Ioanna Alifieraki

Public bug reported:

[Description]
TBD

[Test Case]
TBD

[Regression Potential]
TBD

[Other]
TBD

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Xenial)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

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

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

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: linux (Ubuntu Xenial)
   Importance: High => Medium

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

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

Title:
  overlayfs : broken access to r/w files

Status in linux package in Ubuntu:
  New
Status in linux source package in Xenial:
  Confirmed

Bug description:
  [Description]
  TBD

  [Test Case]
  TBD

  [Regression Potential]
  TBD

  [Other]
  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851243/+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 1851243] Re: overlayfs : broken access to r/w files

2020-01-31 Thread Ioanna Alifieraki

VERIFY BUG ON XENIAL

#Test with latest kernel in -updates

$ uname -a
Linux xenial-kernel 4.4.0-173-generic #203-Ubuntu SMP Wed Jan 15 02:55:01 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

$./make-overlay.sh
$ ./test.sh
st_mode is 100644
open failed: -1
cat: /tmp/overlay/animal: Permission denied
-rw-r--r-- 1 jo jo 0 Jan 31 16:54 /tmp/overlay/animal

Issue is reproducible.


#Test with kernel in -proposed

$ uname -a
Linux xenial-kernel 4.4.0-174-generic #204-Ubuntu SMP Wed Jan 29 06:41:01 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

$./make-overlay.sh
$ ./test.sh 
st_mode is 100644
-rw-r--r-- 1 jo jo 0 Jan 31 16:59 /tmp/overlay/animal

Issue has been resolved.

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

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

Title:
  overlayfs : broken access to r/w files

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  [Description]
  Commit c0ca3d70e8d3(ovl: modify ovl_permission() to do checks on two inodes) 
(upstream id) breaks r/w access in overlayfs in 4.4 ubuntu kernels, later 
ubuntu kernels are not affected.

  There are two options to fix this either (a) backport ce31513a9114(ovl: 
copyattr after setting POSIX ACL) to 4.4 or (b) revert offending commit 
c0ca3d70e8d3(ovl: modify ovl_permission() to do checks on two inodes).
  Option (a) has high risk of regression since ce31513a9114(ovl: copyattr after 
setting POSIX ACL) has many dependencies on other commits that need to be 
backported too.

  We'll proceed with reverting c0ca3d70e8d3(ovl: modify ovl_permission() to do 
checks on two inodes).
  This commit is associated with CVE-2018-16597, however 4.4 kernels (both 
ubuntu and upstream) are NOT affected by this cve so it's safe to revert it.
  The offending commit was introduced upstream in v4.8-rc1. At this point had 
nothing to do with any CVE.
  It was related with CVE-2018-16597 as it was the fix for bug [1].
  Then it was backported to stable 4.4 and this way it ended up in Ubuntu 4.4 
kernels.

  [Test Case]
  > Offending commit breaks r/w access in overlayfs

  Reproducer available in [2].

  To run the reproducer :
  $./make-overlay.sh
  $./test.sh

  # With the offending commit in place :

  $ ./test.sh
  st_mode is 100644
  open failed: -1
  cat: /tmp/overlay/animal: Permission denied < Breaks access
  -rw-r--r-- 1 jo jo 0 Oct 11 09:57 /tmp/overlay/animal

  # With the offending commit reverted :

  $ ./test.sh
  st_mode is 100644
  -rw-r--r-- 1 jo jo 0 Oct 11 16:01 /tmp/overlay/animal

  
  [Other]

  > Test whether 4.4 kernels are affected by CVE-2018-16597

  Since offending commit c0ca3d70e8d3(ovl: modify ovl_permission() to do
  checks on two inodes) is related with CVE-2018-16597 a test script is
  provided to confirm that 4.4 kernel are not affected by this cve and
  therefore is safe to revert the commit.

  Kernels tested :

  4.4 ESM kernels :
  - 4.4.0-1057-aws (offending reverted) PASS
  - 4.4.0-167-generic (offending reverted) PASS

  4.4 AWS Kenrels (not esm) :
  - 4.4.0-1097-aws as is PASS
  - 4.4.0-1097-aws offending reverted PASS

  4.4 Generic kernels (not esm) :
  - 4.4.0-165-generic as is PASS
  - 4.4.0-165-generic (offending reverted) PASS

  Upstream kernels :
  - latest upstream PASS
  - upstream at offending PASS
  - upstream before offending PASS
  - 4.4 stable before offending PASS

  
  ### DETAILS 

  A simple script is attached (test_overlay_permission.sh) to test whether 
ubuntu 4.4 kernels are affected by CVE-2018-16597.
  They are not. Neither is the stable 4.4.y upstream kernel.

  The script tests for the reproducer found in [1] and a modified version
  of it that doesn't breaks the following (quoting from [3] ):
  "Changes to the underlying filesystems while part of a mounted overlay
  filesystem are not allowed. If the underlying filesystem is changed,
  the behavior of the overlay is undefined, though it will not result in
  a crash or deadlock."

  These two test cases should fail. So, expect to see
  "cp: cannot create regular file : Permission denied".

  Then there are a few other test cases (files placed in lower/upper dirs and 
owned
  by root/user).
  The script checks the contents of the files at the end and reports anything 
wrong by printing :
  Problem with file 
  and then cat-ing the file and listing the permissions.

  An example (correct) output is the following :

  --

  $ ./test_overlay_permission.sh
  Testing reproducer
  This should fail
  cp: cannot create regular file '/home/jo/test_cve/overlay/bash': Permission 
denied
  Testing reproducer modified
  This should fail
  cp: cannot create regular file '/home/jo/test_cve/overlay/bash': Permission 
denied

  Testing other cases
  ./test_overlay_

[Kernel-packages] [Bug 1849848] [NEW] autofs module missing from linux-modules in 5+ kernels

2019-10-25 Thread Ioanna Alifieraki

Public bug reported:

Commit a2225d931f75ddd3c39f4d0d195fad99dfd68671 removes fs/autofs4 path
and replaces it with fs/autofs. This results in the autfs module ending
up in linux-modules-extra package. Update the gcp.inclusion-list with
the correct path.

This issue has been addressed for the generic kernels (see lp 1824333). 
This fixes it for the gcp kernels.

** Affects: linux-gcp (Ubuntu)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

** Affects: linux-gcp (Ubuntu Disco)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

** Affects: linux-gcp (Ubuntu Eoan)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

** Affects: linux-gcp (Ubuntu Focal)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed


** Tags: sts

** Changed in: linux-gcp (Ubuntu)
   Importance: Undecided => Medium

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

** Changed in: linux-gcp (Ubuntu)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Also affects: linux-gcp (Ubuntu Focal)
   Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
   Status: Confirmed

** Also affects: linux-gcp (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: linux-gcp (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Changed in: linux-gcp (Ubuntu Eoan)
   Status: New => Confirmed

** Changed in: linux-gcp (Ubuntu Disco)
   Status: New => Confirmed

** Changed in: linux-gcp (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: linux-gcp (Ubuntu Disco)
   Importance: Undecided => Medium

** Changed in: linux-gcp (Ubuntu Eoan)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux-gcp (Ubuntu Disco)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Tags added: sts

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

Title:
  autofs module missing from linux-modules in 5+ kernels

Status in linux-gcp package in Ubuntu:
  Confirmed
Status in linux-gcp source package in Disco:
  Confirmed
Status in linux-gcp source package in Eoan:
  Confirmed
Status in linux-gcp source package in Focal:
  Confirmed

Bug description:
  Commit a2225d931f75ddd3c39f4d0d195fad99dfd68671 removes fs/autofs4 path
  and replaces it with fs/autofs. This results in the autfs module ending
  up in linux-modules-extra package. Update the gcp.inclusion-list with
  the correct path.
  
  This issue has been addressed for the generic kernels (see lp 1824333). 
  This fixes it for the gcp kernels.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-gcp/+bug/1849848/+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 1820031] Re: My Ubuntu 18.04 GUI seems frozen (kernel crash in 0010:gen8_ppgtt_set_pde.isra.43+0x45/0x60 [i915])

2019-10-29 Thread Ioanna Alifieraki

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

** Changed in: linux (Ubuntu)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

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

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

** Changed in: linux (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Bionic)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

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

Title:
  My Ubuntu 18.04 GUI seems frozen (kernel crash in
  0010:gen8_ppgtt_set_pde.isra.43+0x45/0x60 [i915])

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

Bug description:
  This will possibly be a duplicate of Bug #1820028 or Bug #1820029 or
  Bug #1820030

  I was trying to report a frozen GUI over SSH. This is the second
  report that apport-cli generated when I ran it with xorg as the target
  package.  I made three four reports to see if different diagnostics
  were geneereated as Ihave no way of knowing what is causing the lock
  up at present.

  The symptoms I see are that I started running a go test last night and
  my GUI on Ubuntu 18.04 seems to have frozen. I cannot get the wireless
  mouse or keyboard to move anything on the display and the time shown
  on the clock matches when things froze last night.

  Before I made the report I looked for any process using high amounts
  of CUP with top and htop but spotted none. I tried to local a SIGTERM
  the go test process but that made no difference.

  

  I shall attempt to restart my desktop service

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1
  ProcVersionSignature: Ubuntu 4.15.0-45.48-generic 4.15.18
  Uname: Linux 4.15.0-45-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Thu Mar 14 09:12:51 2019
  DistUpgraded: 2018-07-27 11:19:59,510 DEBUG failed to SystemUnLock() (E:Not 
locked)
  DistroCodename: bionic
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, including running git bisection searches
  GraphicsCard:
   Intel Corporation HD Graphics 630 [8086:5912] (rev 04) (prog-if 00 [VGA 
controller])
 Subsystem: ASUSTeK Computer Inc. HD Graphics 630 [1043:8694]
  InstallationDate: Installed on 2017-11-16 (482 days ago)
  InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 
(20170801)
  MachineType: System manufacturer System Product Name
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-45-generic 
root=UUID=473dc1b9-3a5c-4f95-8cc0-e3b0f628ca41 ro quiet splash vt.handoff=1
  SourcePackage: xorg
  UnitySupportTest:
   Error: command ['/usr/lib/nux/unity_support_test', '-p', '-f'] failed with 
exit code 5: PuTTY X11 proxy: unable to connect to forwarded X server: Network 
error: Connection refused
   Error: unable to open display
  UpgradeStatus: Upgraded to bionic on 2018-07-27 (229 days ago)
  dmi.bios.date: 09/27/2017
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 0811
  dmi.board.asset.tag: Default string
  dmi.board.name: STRIX H270F GAMING
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev X.0x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr0811:bd09/27/2017:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnSTRIXH270FGAMING:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: System Product Name
  dmi.product.version: System Version
  dmi.sys.vendor: System manufacturer
  version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1
  version.libdrm2: libdrm2 2.4.95-1~18.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 18.2.2-0ubuntu1~18.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx 18.2.2-0ubuntu1~18.04.1
  version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20171229-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
  xserver.bootTime: Tue Mar 12 13:46:44 2019
  xserver.configfile: default
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.version: 2:1.19.6-1ubuntu4.2
  xserver.video_driver: modeset

To manage notifications about this bug go to:
https://bugs.launchpad.ne

[Kernel-packages] [Bug 1851243] Re: overlayfs : broken access to r/w files

** Description changed:

  [Description]
- TBD
+ Commit c0ca3d70e8d3(ovl: modify ovl_permission() to do checks on two inodes) 
(upstream id) breaks r/w access in overlayfs in 4.4 ubuntu kernels, later 
ubuntu kernels are not affected.
+ 
+ There are two options to fix this either (a) backport ce31513a9114(ovl: 
copyattr after setting POSIX ACL) to 4.4 or (b) revert offending commit 
c0ca3d70e8d3(ovl: modify ovl_permission() to do checks on two inodes).
+ Option (a) has high risk of regression since ce31513a9114(ovl: copyattr after 
setting POSIX ACL) has many dependencies on other commits that need to be 
backported too.
+ 
+ We'll proceed with reverting c0ca3d70e8d3(ovl: modify ovl_permission() to do 
checks on two inodes).
+ This commit is associated with CVE-2018-16597, however 4.4 kernels (both 
ubuntu and upstream) are NOT affected by this cve so it's safe to revert it.
+ The offending commit was introduced upstream in v4.8-rc1. At this point had 
nothing to do with any CVE.
+ It was related with CVE-2018-16597 as it was the fix for bug [1].
+ Then it was backported to stable 4.4 and this way it ended up in Ubuntu 4.4 
kernels.
  
  [Test Case]
- TBD
+ > Offending commit breaks r/w access in overlayfs
  
- [Regression Potential]
- TBD
+ Reproducer available in [2].
+ 
+ To run the reproducer :
+ $./make-overlay.sh
+ $./test.sh
+ 
+ # With the offending commit in place :
+ 
+ $ ./test.sh
+ st_mode is 100644
+ open failed: -1
+ cat: /tmp/overlay/animal: Permission denied < Breaks access
+ -rw-r--r-- 1 jo jo 0 Oct 11 09:57 /tmp/overlay/animal
+ 
+ # With the offending commit reverted :
+ 
+ $ ./test.sh
+ st_mode is 100644
+ -rw-r--r-- 1 jo jo 0 Oct 11 16:01 /tmp/overlay/animal
+ 
  
  [Other]
- TBD
+ 
+ > Test whether 4.4 kernels are affected by CVE-2018-16597
+ 
+ Since offending commit c0ca3d70e8d3(ovl: modify ovl_permission() to do
+ checks on two inodes) is related with CVE-2018-16597 a test script is
+ provided to confirm that 4.4 kernel are not affected by this cve and
+ therefore is safe to revert the commit.
+ 
+ Kernels tested :
+ 
+ 4.4 ESM kernels :
+ - 4.4.0-1057-aws (offending reverted) PASS
+ - 4.4.0-167-generic (offending reverted) PASS
+ 
+ 4.4 AWS Kenrels (not esm) :
+ - 4.4.0-1097-aws as is PASS
+ - 4.4.0-1097-aws offending reverted PASS
+ 
+ 4.4 Generic kernels (not esm) :
+ - 4.4.0-165-generic as is PASS
+ - 4.4.0-165-generic (offending reverted) PASS
+ 
+ Upstream kernels :
+ - latest upstream PASS
+ - upstream at offending PASS
+ - upstream before offending PASS
+ - 4.4 stable before offending PASS
+ 
+ 
+ ### DETAILS 
+ 
+ A simple script is attached (test_overlay_permission.sh) to test whether 
ubuntu 4.4 kernels are affected by CVE-2018-16597.
+ They are not. Neither is the stable 4.4.y upstream kernel.
+ 
+ The script tests for the reproducer found in [1] and a modified version
+ of it that doesn't breaks the following (quoting from [3] ):
+ "Changes to the underlying filesystems while part of a mounted overlay
+ filesystem are not allowed. If the underlying filesystem is changed,
+ the behavior of the overlay is undefined, though it will not result in
+ a crash or deadlock."
+ 
+ These two test cases should fail. So, expect to see
+ "cp: cannot create regular file : Permission denied".
+ 
+ Then there are a few other test cases (files placed in lower/upper dirs and 
owned
+ by root/user).
+ The script checks the contents of the files at the end and reports anything 
wrong by printing :
+ Problem with file 
+ and then cat-ing the file and listing the permissions.
+ 
+ An example (correct) output is the following :
+ 
+ --
+ 
+ $ ./test_overlay_permission.sh
+ Testing reproducer
+ This should fail
+ cp: cannot create regular file '/home/jo/test_cve/overlay/bash': Permission 
denied
+ Testing reproducer modified
+ This should fail
+ cp: cannot create regular file '/home/jo/test_cve/overlay/bash': Permission 
denied
+ 
+ Testing other cases
+ ./test_overlay_permission.sh: line 100: 
/home/jo/test_cve/overlay/after_mount_root: Permission denied
+ ./test_overlay_permission.sh: line 100: /home/jo/test_cve/overlay/both_root: 
Permission denied
+ ./test_overlay_permission.sh: line 100: 
/home/jo/test_cve/overlay/lower_only_root: Permission denied
+ ./test_overlay_permission.sh: line 100: 
/home/jo/test_cve/overlay/upper_only_root: Permission denied
+ ##
+ CHECK LOWER
+ ##
+ CHECK UPPER
+ ##
+ CHECK OVERLAY
+ 
+ --
+ 
+ We see that when "Testing reproducer" it fails so we are OK.
+ In addition, when "Testing other cases" we get 4 "Permission denied", which is
+ also the desired behaviour as a user is trying to write root-owned files.
+ In case, there's output after CHECK LOWER/

[Kernel-packages] [Bug 1841058] Re: kernel version 4.4.0-1090-aws docker file system issue

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

** This bug has been marked a duplicate of bug 1851243
   overlayfs : broken access to r/w files

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

Title:
  kernel version 4.4.0-1090-aws docker file system issue

Status in linux-aws package in Ubuntu:
  New
Status in sed package in Ubuntu:
  New

Bug description:
  When using kernel version 4.4.0-1090-aws 
  if you have running container and you do sed on some files then you cannot 
access them inside the container any more

  we use the nginx image and we can reproduce it everytime

  in the container we have chown and then sed commands on some nginx.conf files 
  after the sed we are getting persmission denied inside the container even 
that we use root.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-aws/+bug/1841058/+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 1858834] [NEW] ipc/sem.c : process loops infinitely in exit_sem()

Public bug reported:

[Description]

Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage
in exit_sem()") removes a lock that is needed. This leads to a process
looping infinitely in exit_sem() and can also lead to a crash.

[Test case]

Using the reproducer found in [1] is fairly easy to reach a point where
one of the child processes is looping infinitely in exit_sem between
for(;;) and if (semid == -1) block, while it's trying to free its last
sem_undo structure which has already been freed by freeary().

Once commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock
usage in exit_sem()") the issue is not reproducible any more.

[Other]

Patch submitted upstream :
https://lkml.org/lkml/2019/12/11/1718


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

** Affects: linux (Ubuntu)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: In Progress

** Affects: linux (Ubuntu Xenial)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: In Progress

** Affects: linux (Ubuntu Bionic)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: In Progress

** Affects: linux (Ubuntu Disco)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: In Progress

** Affects: linux (Ubuntu Eoan)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: In Progress

** Affects: linux (Ubuntu Focal)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: In Progress

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

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

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

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

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

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Disco)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Focal)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux (Ubuntu Eoan)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux (Ubuntu Disco)
     Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux (Ubuntu Bionic)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

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

Title:
  ipc/sem.c : process loops infinitely in exit_sem()

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Bionic:
  In Progress
Status in linux source package in Disco:
  In Progress
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress

Bug description:
  [Description]

  Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage
  in exit_sem()") removes a lock that is needed. This leads to a process
  looping infinitely in exit_sem() and can also lead to a crash.

  [Test case]

  Using the reproducer found in [1] is fairly easy to reach a point where
  one of the child processes is looping infinitely in exit_sem between
  for(;;) and if (semid == -1) block, while it's trying to free its last
  sem_undo structure which has already been freed by freeary().

  Once commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock
  usage in exit_sem()") the issue is not reproducible any more.

  [Other]

  Patch submitted upstream :
  https://lkml.org/lkml/2019/12/11/1718

  
  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1858834/+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 1858834] Re: ipc/sem.c : process loops infinitely in exit_sem()

** Description changed:

  [Description]
  
  Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage
  in exit_sem()") removes a lock that is needed. This leads to a process
  looping infinitely in exit_sem() and can also lead to a crash.
+ 
+ [Test case]
+ 
+ Using the reproducer found in [1] is fairly easy to reach a point where
+ one of the child processes is looping infinitely in exit_sem between
+ for(;;) and if (semid == -1) block, while it's trying to free its last
+ sem_undo structure which has already been freed by freeary().
+ 
+ Once commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock
+ usage in exit_sem()") the issue is not reproducible any more.
+ 
+ [Other]
+ 
+ Patch submitted upstream :
+ https://lkml.org/lkml/2019/12/11/1718
+ 
+ 
+ [1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

** Changed in: linux (Ubuntu Xenial)
   Status: Incomplete => In Progress

** Changed in: linux (Ubuntu Bionic)
   Status: Incomplete => In Progress

** Changed in: linux (Ubuntu Disco)
   Status: Incomplete => In Progress

** Changed in: linux (Ubuntu Eoan)
   Status: Incomplete => In Progress

** Changed in: linux (Ubuntu Focal)
   Status: Incomplete => In Progress

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

Title:
  ipc/sem.c : process loops infinitely in exit_sem()

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Bionic:
  In Progress
Status in linux source package in Disco:
  In Progress
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress

Bug description:
  [Description]

  Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage
  in exit_sem()") removes a lock that is needed. This leads to a process
  looping infinitely in exit_sem() and can also lead to a crash.

  [Test case]

  Using the reproducer found in [1] is fairly easy to reach a point where
  one of the child processes is looping infinitely in exit_sem between
  for(;;) and if (semid == -1) block, while it's trying to free its last
  sem_undo structure which has already been freed by freeary().

  Once commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock
  usage in exit_sem()") the issue is not reproducible any more.

  [Other]

  Patch submitted upstream :
  https://lkml.org/lkml/2019/12/11/1718

  
  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1858834/+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 1835509] [NEW] False warning "The kernel version is not supported." on xenial with -hwe kernels

2019-07-05 Thread Ioanna Alifieraki

Public bug reported:

[Impact]

The message appears as when running -hwe kernels (4.15) on Xenial.
This happens because makedumpfile defines a LATEST_VERSION kernel that 
"officially" 
supports. 
Currently, makedumpfile package for xenial has this version set to 4.14.8 and 
this is 
why it shows this message with 4.15 kernels.

[Test Case]
TBD

[Regression Potential]
TBD

[Other]

** Affects: makedumpfile (Ubuntu)
 Importance: Undecided
 Assignee: Ioanna Alifieraki (joalif)
 Status: New

** Affects: makedumpfile (Ubuntu Xenial)
 Importance: Undecided
 Assignee: Ioanna Alifieraki (joalif)
 Status: New

** Changed in: makedumpfile (Ubuntu)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Also affects: makedumpfile (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: makedumpfile (Ubuntu Xenial)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

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

Title:
  False warning "The kernel version is not supported."  on xenial with
  -hwe kernels

Status in makedumpfile package in Ubuntu:
  New
Status in makedumpfile source package in Xenial:
  New

Bug description:
  [Impact]

  The message appears as when running -hwe kernels (4.15) on Xenial.
  This happens because makedumpfile defines a LATEST_VERSION kernel that 
"officially" 
  supports. 
  Currently, makedumpfile package for xenial has this version set to 4.14.8 and 
this is 
  why it shows this message with 4.15 kernels.

  [Test Case]
  TBD

  [Regression Potential]
  TBD

  [Other]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1835509/+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 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

2020-07-14 Thread Ioanna Alifieraki

** Changed in: makedumpfile (Ubuntu)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Tags added: sts

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Confirmed

Bug description:
  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  
  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1879214/+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 1908428] [NEW] 4.4 kernel panics in kvm wake_up() handler

2020-12-16 Thread Ioanna Alifieraki

Public bug reported:

User reported that 4.4 kernels are affected by the bug in [1].

The bug presents itself with the following trace :

[219901.424329] CPU: 19 PID: 0 Comm: swapper/19 Tainted: G   OE   
4.4.0-133-generic #159~14.04.1-Ubuntu
[219901.441800] task: 885f62e63fc0 ti: 885f62e7c000 task.ti: 
885f62e7c000
[219901.449408] RIP: 0010:[]  [] 
wakeup_handler+0x6d/0xa0 [kvm_intel]
[219901.458791] RSP: 0018:885f7c043f70  EFLAGS: 00010083
[219901.464217] RAX: 885f7c04 RBX: dead00b8 RCX: 
885f7c0586c0
[219901.471480] RDX: dead0100 RSI:  RDI: 
885f7c0586b0
[219901.478741] RBP: 885f7c043f90 R08:  R09: 
c7ffc2ec9069
[219901.486003] R10: 0494 R11: 885f7c057370 R12: 
000186b0
[219901.493267] R13: 0013 R14: 000186c0 R15: 
885f62e7c000
[219901.500528] FS:  () GS:885f7c04() 
knlGS:
[219901.511738] CS:  0010 DS:  ES:  CR0: 80050033
[219901.517597] CR2: 7f6d57098000 CR3: 003183dfe000 CR4: 
00362670
[219901.524860] DR0:  DR1:  DR2: 

[219901.532121] DR3:  DR6: fffe0ff0 DR7: 
0400
[219901.539384] Stack:
[219901.541509]   0013  

[219901.549120]  885f7c043fa8 8102fa99 81f40200 
885f62e7fe98
[219901.556747]  8182131f 885f62e7fde8   885f62e7c000 

[219901.565006] Call Trace:
[219901.567567]   
[219901.569592]  [] smp_kvm_posted_intr_wakeup_ipi+0x59/0x70
[219901.576795]  [] kvm_posted_intr_wakeup_ipi+0xbf/0xd0
[219901.583431]   
[219901.585456]  [] ? hard_disable_TSC+0x30/0x30
[219901.591621]  [] ? native_safe_halt+0x6/0x10
[219901.597479]  [] default_idle+0x1e/0xe0
[219901.602900]  [] arch_cpu_idle+0x15/0x20
[219901.608416]  [] default_idle_call+0x2a/0x40
[219901.614270]  [] cpu_startup_entry+0x2e0/0x350
[219901.620305]  [] start_secondary+0x16c/0x190


The root cause is blocked_vcpu_on_cpu list is corrupted.
This bug is fixed  with the patchset found in [2].
Only the first 3 (out of 4) of them have made their way in upstream kernel and 
are the ones needed to fix the bug.

A test kernel with the fixing patches have been provided to the user and they
confirmed that it resolves the issue.

[1] https://marc.info/?l=kvm&m=149559827906211&w=2
[2] https://lore.kernel.org/lkml/20170606105707.23207-1-pbonz...@redhat.com/

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Also affects: linux (Ubuntu Xenial)
   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/1908428

Title:
  4.4 kernel panics in kvm wake_up() handler

Status in linux package in Ubuntu:
  New
Status in linux source package in Xenial:
  New

Bug description:
  User reported that 4.4 kernels are affected by the bug in [1].

  The bug presents itself with the following trace :

  [219901.424329] CPU: 19 PID: 0 Comm: swapper/19 Tainted: G   OE   
4.4.0-133-generic #159~14.04.1-Ubuntu
  [219901.441800] task: 885f62e63fc0 ti: 885f62e7c000 task.ti: 
885f62e7c000
  [219901.449408] RIP: 0010:[]  [] 
wakeup_handler+0x6d/0xa0 [kvm_intel]
  [219901.458791] RSP: 0018:885f7c043f70  EFLAGS: 00010083
  [219901.464217] RAX: 885f7c04 RBX: dead00b8 RCX: 
885f7c0586c0
  [219901.471480] RDX: dead0100 RSI:  RDI: 
885f7c0586b0
  [219901.478741] RBP: 885f7c043f90 R08:  R09: 
c7ffc2ec9069
  [219901.486003] R10: 0494 R11: 885f7c057370 R12: 
000186b0
  [219901.493267] R13: 0013 R14: 000186c0 R15: 
885f62e7c000
  [219901.500528] FS:  () GS:885f7c04() 
knlGS:
  [219901.511738] CS:  0010 DS:  ES:  CR0: 80050033
  [219901.517597] CR2: 7f6d57098000 CR3: 003183dfe000 CR4: 
00362670
  [219901.524860] DR0:  DR1:  DR2: 

  [219901.532121] DR3:  DR6: fffe0ff0 DR7: 
0400
  [219901.539384] Stack:
  [219901.541509]   0013  

  [219901.549120]  885f7c043fa8 8102fa99 81f40200 
885f62e7fe98
  [219901.556747]  8182131f 885f62e7fde8   885f62e7c000 

  [219901.565006] Call Trace:
  [219901.567567]   
  [219901.569592]  [] smp_kvm_posted_intr_wakeup_ipi+0x59/0x70
  [219901.576795]  [] kvm_posted_intr_wakeup_ipi+0xbf/0xd0
  [219901.583431]   
  [219901.585456]  [] ? hard_disable_TSC+0x30/0x30
  [219901.591621]  [] ? nat

[Kernel-packages] [Bug 1908428] Re: 4.4 kernel panics in kvm wake_up() handler

2020-12-16 Thread Ioanna Alifieraki

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

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

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

Title:
  4.4 kernel panics in kvm wake_up() handler

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Confirmed

Bug description:
  User reported that 4.4 kernels are affected by the bug in [1].

  The bug presents itself with the following trace :

  [219901.424329] CPU: 19 PID: 0 Comm: swapper/19 Tainted: G   OE   
4.4.0-133-generic #159~14.04.1-Ubuntu
  [219901.441800] task: 885f62e63fc0 ti: 885f62e7c000 task.ti: 
885f62e7c000
  [219901.449408] RIP: 0010:[]  [] 
wakeup_handler+0x6d/0xa0 [kvm_intel]
  [219901.458791] RSP: 0018:885f7c043f70  EFLAGS: 00010083
  [219901.464217] RAX: 885f7c04 RBX: dead00b8 RCX: 
885f7c0586c0
  [219901.471480] RDX: dead0100 RSI:  RDI: 
885f7c0586b0
  [219901.478741] RBP: 885f7c043f90 R08:  R09: 
c7ffc2ec9069
  [219901.486003] R10: 0494 R11: 885f7c057370 R12: 
000186b0
  [219901.493267] R13: 0013 R14: 000186c0 R15: 
885f62e7c000
  [219901.500528] FS:  () GS:885f7c04() 
knlGS:
  [219901.511738] CS:  0010 DS:  ES:  CR0: 80050033
  [219901.517597] CR2: 7f6d57098000 CR3: 003183dfe000 CR4: 
00362670
  [219901.524860] DR0:  DR1:  DR2: 

  [219901.532121] DR3:  DR6: fffe0ff0 DR7: 
0400
  [219901.539384] Stack:
  [219901.541509]   0013  

  [219901.549120]  885f7c043fa8 8102fa99 81f40200 
885f62e7fe98
  [219901.556747]  8182131f 885f62e7fde8   885f62e7c000 

  [219901.565006] Call Trace:
  [219901.567567]   
  [219901.569592]  [] smp_kvm_posted_intr_wakeup_ipi+0x59/0x70
  [219901.576795]  [] kvm_posted_intr_wakeup_ipi+0xbf/0xd0
  [219901.583431]   
  [219901.585456]  [] ? hard_disable_TSC+0x30/0x30
  [219901.591621]  [] ? native_safe_halt+0x6/0x10
  [219901.597479]  [] default_idle+0x1e/0xe0
  [219901.602900]  [] arch_cpu_idle+0x15/0x20
  [219901.608416]  [] default_idle_call+0x2a/0x40
  [219901.614270]  [] cpu_startup_entry+0x2e0/0x350
  [219901.620305]  [] start_secondary+0x16c/0x190

  
  The root cause is blocked_vcpu_on_cpu list is corrupted.
  This bug is fixed  with the patchset found in [2].
  Only the first 3 (out of 4) of them have made their way in upstream kernel 
and 
  are the ones needed to fix the bug.

  A test kernel with the fixing patches have been provided to the user and they
  confirmed that it resolves the issue.

  [1] https://marc.info/?l=kvm&m=149559827906211&w=2
  [2] https://lore.kernel.org/lkml/20170606105707.23207-1-pbonz...@redhat.com/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1908428/+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 1908428] Re: 4.4 kernel panics in kvm wake_up() handler

2020-12-16 Thread Ioanna Alifieraki

** Description changed:

+ [Description]
+ 
  User reported that 4.4 kernels are affected by the bug in [1].
  
  The bug presents itself with the following trace :
  
  [219901.424329] CPU: 19 PID: 0 Comm: swapper/19 Tainted: G   OE   
4.4.0-133-generic #159~14.04.1-Ubuntu
  [219901.441800] task: 885f62e63fc0 ti: 885f62e7c000 task.ti: 
885f62e7c000
  [219901.449408] RIP: 0010:[]  [] 
wakeup_handler+0x6d/0xa0 [kvm_intel]
  [219901.458791] RSP: 0018:885f7c043f70  EFLAGS: 00010083
  [219901.464217] RAX: 885f7c04 RBX: dead00b8 RCX: 
885f7c0586c0
  [219901.471480] RDX: dead0100 RSI:  RDI: 
885f7c0586b0
  [219901.478741] RBP: 885f7c043f90 R08:  R09: 
c7ffc2ec9069
  [219901.486003] R10: 0494 R11: 885f7c057370 R12: 
000186b0
  [219901.493267] R13: 0013 R14: 000186c0 R15: 
885f62e7c000
  [219901.500528] FS:  () GS:885f7c04() 
knlGS:
  [219901.511738] CS:  0010 DS:  ES:  CR0: 80050033
  [219901.517597] CR2: 7f6d57098000 CR3: 003183dfe000 CR4: 
00362670
  [219901.524860] DR0:  DR1:  DR2: 

  [219901.532121] DR3:  DR6: fffe0ff0 DR7: 
0400
  [219901.539384] Stack:
  [219901.541509]   0013  

  [219901.549120]  885f7c043fa8 8102fa99 81f40200 
885f62e7fe98
  [219901.556747]  8182131f 885f62e7fde8   885f62e7c000 

  [219901.565006] Call Trace:
- [219901.567567]   
+ [219901.567567]  
  [219901.569592]  [] smp_kvm_posted_intr_wakeup_ipi+0x59/0x70
  [219901.576795]  [] kvm_posted_intr_wakeup_ipi+0xbf/0xd0
- [219901.583431]   
+ [219901.583431]  
  [219901.585456]  [] ? hard_disable_TSC+0x30/0x30
  [219901.591621]  [] ? native_safe_halt+0x6/0x10
  [219901.597479]  [] default_idle+0x1e/0xe0
  [219901.602900]  [] arch_cpu_idle+0x15/0x20
  [219901.608416]  [] default_idle_call+0x2a/0x40
  [219901.614270]  [] cpu_startup_entry+0x2e0/0x350
  [219901.620305]  [] start_secondary+0x16c/0x190
  
- 
  The root cause is blocked_vcpu_on_cpu list is corrupted.
  This bug is fixed  with the patchset found in [2].
- Only the first 3 (out of 4) of them have made their way in upstream kernel 
and 
+ Only the first 3 (out of 4) of them have made their way in upstream kernel and
  are the ones needed to fix the bug.
  
- A test kernel with the fixing patches have been provided to the user and they
- confirmed that it resolves the issue.
+ [Test case]
+ It was not possible to reproduce this bug locally.
+ A test kernel with the fixing patches has been provided to the user and they 
confirmed that it resolves the issue.
+ 
+ [Regression Potential]
+ 
+ The patches have been accepted upstream in 4.14 and so far there are no known 
regressions.
+ Backporting the patches was necessary; original patches modify 
pi_pre/post_block functions which are not present in 4.4.
+ These functions are introduced by upstream commit bc22512bb24c(kvm: vmx: 
rename vmx_pre/post_block to pi_pre/post_block).
+ Appropriate changes where made for the patches to modify vmx_pre/post_block 
function without changing the functionality of the patches.
+ Testing has not revealed any regressions.
+ 
+ 
+ [Other]
+ 
+ Only 4.4 kernels are affected.
+ 
  
  [1] https://marc.info/?l=kvm&m=149559827906211&w=2
  [2] https://lore.kernel.org/lkml/20170606105707.23207-1-pbonz...@redhat.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/1908428

Title:
  4.4 kernel panics in kvm wake_up() handler

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Confirmed

Bug description:
  [Description]

  User reported that 4.4 kernels are affected by the bug in [1].

  The bug presents itself with the following trace :

  [219901.424329] CPU: 19 PID: 0 Comm: swapper/19 Tainted: G   OE   
4.4.0-133-generic #159~14.04.1-Ubuntu
  [219901.441800] task: 885f62e63fc0 ti: 885f62e7c000 task.ti: 
885f62e7c000
  [219901.449408] RIP: 0010:[]  [] 
wakeup_handler+0x6d/0xa0 [kvm_intel]
  [219901.458791] RSP: 0018:885f7c043f70  EFLAGS: 00010083
  [219901.464217] RAX: 885f7c04 RBX: dead00b8 RCX: 
885f7c0586c0
  [219901.471480] RDX: dead0100 RSI:  RDI: 
885f7c0586b0
  [219901.478741] RBP: 885f7c043f90 R08:  R09: 
c7ffc2ec9069
  [219901.486003] R10: 0494 R11: 885f7c057370 R12: 
000186b0
  [219901.493267] R13: 0013 R14: 000186c0 R15: 
885f62e7c000
  [219901.500528] FS:  () GS:885f7c04() 
knlGS:
  [219901.511738] CS:  0010 DS:  ES:  CR0: 80050033

[Kernel-packages] [Bug 2042568] Re: Azure - Kernel crashes when removing gpu from pci

2024-01-24 Thread Ioanna Alifieraki

# VERIFICATION JAMMY

This verification is using a jammy 5.15.0-1055 kernel on a focal machine.
To reproduce this issue a special azure instance is required and currently I
have access to a focal vm.

root@jo-twosla:/home/ubuntu# uname -rv
5.15.0-1055-azure #63~20.04.1-Ubuntu SMP Thu Jan 18 15:30:26 UTC 2024

root@jo-twosla:/home/ubuntu# lspci
0001:00:00.0 3D controller: NVIDIA Corporation TU104GL [Tesla T4] (rev a1)
3240:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family
[ConnectX-4 Lx Virtual Function] (rev 80)

root@jo-twosla:/home/ubuntu# echo '1' >
/sys/bus/pci/devices/0001:00:00.0/remove

root@jo-twosla:/home/ubuntu# lspci
3240:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family
[ConnectX-4 Lx Virtual Function] (rev 80)

The gpu is successfully removed without the vm crashing.

** Tags removed: verification-needed-jammy-linux-azure
** Tags added: verification-done-jammy-linux-azure

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

Title:
Azure - Kernel crashes when removing gpu from pci

Status in linux-azure package in Ubuntu:
Invalid
Status in linux-azure source package in Jammy:
Fix Committed
Status in linux-azure source package in Lunar:
Fix Committed

Bug description:
[Description]

On a VM on Azure with a Tesla gpu it was noticed that when removing
the gpu from the pci the vm would crash. In case the nvidia drivers
are loaded, the machine won't crash. Instead the removing process will
hang and the machine will crash on reboot.

This is related to bug [1].
The bug reported in [1] regards another driver but the root cause is the same.
It is still investigated whether this is a bug in pci, or it is a bug of
various drivers on how they use pci.

For this case we have identified that removing commit [2] prevents the
kernel crashes.

Azure has requested to revert this commit, at least for the time being.
This commit is not in upstream, so it just need to be reverted from Ubuntu
kernels.

[Test Case]

On an Azure vm with a gpu :

# echo '1' > /sys/bus/pci/devices/0001:00:00.0/remove

where '0001:00:00.0' the pci address of the gpu.
The vm will crash.

[Where things could go wrong]

The commit to be reverted was included in a patchset to address lp
bugs https://bugs.launchpad.net/bugs/2023071 and
https://bugs.launchpad.net/bugs/2023594

However this commit just reduces boot time and removing shall not introduce
any regressions.
Side effects will be increase in the boot time.

[Other]

Only Ubuntu azure kernels are affected :

- Jammy 5.15
- Lunar 6.2

Focal is also affected since it's using 5.15 kernel.
This commit does not appear in Mantic 6.5 kernel.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=215515
[2]
https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-azure/+git/jammy/commit/?h=Ubuntu-azure-5.15.0-1043.50&id=75af0c10b3703400890d314d1d91d25294234a81

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/2042568/+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 1942784] [NEW] makedumpfile not properly working on focal with 5.11 kernel

Public bug reported:

[IMPACT]

When running Focal with the hwe 5.11 kernel makedumpfile is not working as it 
should.
Instead of compressing the dump makedumpfile falls back to cp.
This can create problems on systems with very large RAM and result into 
exhausting all storage on the host.
This can be resolved with upstream commit 54aec3878b3f([PATCH] make use of 
'uts_namespace.name' offset in VMCOREINFO).

In addition the dmesg. is not created.
This can be resolved with the following two commits  :
- commit c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
- commit 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state values)

[TEST CASE]

For testing a machine running focal with the 5.11 kernel is required.
Then trigger a crash.
On the console we can see that makedumpfile fails and `falls back to cp`. 
In /var/crash we can see that no dmesg file is created and instead of the dump 
file
the uncompressed vmcoreinfo is created.

[WHERE PROBLEMS COULD OCCUR]

The 3 commits pulled into focal make makedumpfile compatible with the 5.11 
kernel.
Any regression potential would involve the crash dump not being created after a 
crash in case kdump is configured.

[OTHER]

Only Focal with 5.11 kernel is affected.

** Affects: makedumpfile (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: makedumpfile (Ubuntu Focal)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

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

** Changed in: makedumpfile (Ubuntu Focal)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: makedumpfile (Ubuntu Focal)
   Importance: Undecided => Medium

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

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

Title:
  makedumpfile not properly working on focal with 5.11 kernel

Status in makedumpfile package in Ubuntu:
  New
Status in makedumpfile source package in Focal:
  Confirmed

Bug description:
  [IMPACT]

  When running Focal with the hwe 5.11 kernel makedumpfile is not working as it 
should.
  Instead of compressing the dump makedumpfile falls back to cp.
  This can create problems on systems with very large RAM and result into 
exhausting all storage on the host.
  This can be resolved with upstream commit 54aec3878b3f([PATCH] make use of 
'uts_namespace.name' offset in VMCOREINFO).

  In addition the dmesg. is not created.
  This can be resolved with the following two commits  :
  - commit c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  - commit 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state 
values)

  [TEST CASE]

  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
  On the console we can see that makedumpfile fails and `falls back to cp`. 
  In /var/crash we can see that no dmesg file is created and instead of the 
dump file
  the uncompressed vmcoreinfo is created.

  [WHERE PROBLEMS COULD OCCUR]

  The 3 commits pulled into focal make makedumpfile compatible with the 5.11 
kernel.
  Any regression potential would involve the crash dump not being created after 
a crash in case kdump is configured.

  [OTHER]

  Only Focal with 5.11 kernel is affected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1942784/+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 1942784] Re: makedumpfile not properly working on focal with 5.11 kernel

Debdiff for Focal.

** Patch added: "lp1942784_focal.debdiff"

https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1942784/+attachment/5523255/+files/lp1942784_focal.debdiff

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

Title:
makedumpfile not properly working on focal with 5.11 kernel

Status in makedumpfile package in Ubuntu:
New
Status in makedumpfile source package in Focal:
Confirmed

Bug description:
[IMPACT]

When running Focal with the hwe 5.11 kernel makedumpfile is not working as it
should.
Instead of compressing the dump makedumpfile falls back to cp.
This can create problems on systems with very large RAM and result into
exhausting all storage on the host.
This can be resolved with upstream commit 54aec3878b3f([PATCH] make use of
'uts_namespace.name' offset in VMCOREINFO).

In addition the dmesg. is not created.
This can be resolved with the following two commits :
- commit c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
- commit 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state
values)

[TEST CASE]

For testing a machine running focal with the 5.11 kernel is required.
Then trigger a crash.
On the console we can see that makedumpfile fails and `falls back to cp`.
In /var/crash we can see that no dmesg file is created and instead of the
dump file
the uncompressed vmcoreinfo is created.

[WHERE PROBLEMS COULD OCCUR]

The 3 commits pulled into focal make makedumpfile compatible with the 5.11
kernel.
Any regression potential would involve the crash dump not being created after
a crash in case kdump is configured.

[OTHER]

Only Focal with 5.11 kernel is affected.

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

[Kernel-packages] [Bug 1942784] Re: makedumpfile not properly working on focal with 5.11 kernel

** Tags added: sts

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

Title:
  makedumpfile not properly working on focal with 5.11 kernel

Status in makedumpfile package in Ubuntu:
  New
Status in makedumpfile source package in Focal:
  Confirmed

Bug description:
  [IMPACT]

  When running Focal with the hwe 5.11 kernel makedumpfile is not working as it 
should.
  Instead of compressing the dump makedumpfile falls back to cp.
  This can create problems on systems with very large RAM and result into 
exhausting all storage on the host.
  This can be resolved with upstream commit 54aec3878b3f([PATCH] make use of 
'uts_namespace.name' offset in VMCOREINFO).

  In addition the dmesg. is not created.
  This can be resolved with the following two commits  :
  - commit c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  - commit 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state 
values)

  [TEST CASE]

  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
  On the console we can see that makedumpfile fails and `falls back to cp`. 
  In /var/crash we can see that no dmesg file is created and instead of the 
dump file
  the uncompressed vmcoreinfo is created.

  [WHERE PROBLEMS COULD OCCUR]

  The 3 commits pulled into focal make makedumpfile compatible with the 5.11 
kernel.
  Any regression potential would involve the crash dump not being created after 
a crash in case kdump is configured.

  [OTHER]

  Only Focal with 5.11 kernel is affected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1942784/+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 1942784] Re: makedumpfile not properly working on focal with 5.11 kernel

@cascardo,

Good point, just tested it with 5.4 kernel and works fine with it too.

Thanks,
Jo

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

Title:
  makedumpfile not properly working on focal with 5.11 kernel

Status in makedumpfile package in Ubuntu:
  New
Status in makedumpfile source package in Focal:
  Confirmed

Bug description:
  [IMPACT]

  When running Focal with the hwe 5.11 kernel makedumpfile is not working as it 
should.
  Instead of compressing the dump makedumpfile falls back to cp.
  This can create problems on systems with very large RAM and result into 
exhausting all storage on the host.
  This can be resolved with upstream commit 54aec3878b3f([PATCH] make use of 
'uts_namespace.name' offset in VMCOREINFO).

  In addition the dmesg. is not created.
  This can be resolved with the following two commits  :
  - commit c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  - commit 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state 
values)

  [TEST CASE]

  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
  On the console we can see that makedumpfile fails and `falls back to cp`. 
  In /var/crash we can see that no dmesg file is created and instead of the 
dump file
  the uncompressed vmcoreinfo is created.

  [WHERE PROBLEMS COULD OCCUR]

  The 3 commits pulled into focal make makedumpfile compatible with the 5.11 
kernel.
  Any regression potential would involve the crash dump not being created after 
a crash in case kdump is configured.

  [OTHER]

  Only Focal with 5.11 kernel is affected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1942784/+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 1942784] Re: makedumpfile not properly working on focal with 5.11 kernel

2021-10-18 Thread Ioanna Alifieraki

** Description changed:

  [IMPACT]
  
  When running Focal with the hwe 5.11 kernel makedumpfile is not working as it 
should.
  Instead of compressing the dump makedumpfile falls back to cp.
  This can create problems on systems with very large RAM and result into 
exhausting all storage on the host.
- This can be resolved with upstream commit 54aec3878b3f([PATCH] make use of 
'uts_namespace.name' offset in VMCOREINFO).
+ This can be resolved with upstream commit f1197543d1c4 ([PATCH] Retrieve 
MAX_PHYSMEM_BITS from vmcoreinfo).
+ The reason for falling back to cp is that without this patch makedumpfile 
calculates wrongly the memory layout.
+ This happens after the kernel commit 1d50e5d0c505 ("crash_core, vmcoreinfo: 
Append 'MAX_PHYSMEM_BITS'to vmcoreinfo").
+ With this commit applied, reading MAX_PHYSMEM_BITS from vmcoreinfo instead of 
inferring lead to correctly detecting the memory layout and creating the dump 
file properly. 
  
  In addition the dmesg. is not created.
  This can be resolved with the following two commits  :
  - commit c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  - commit 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state 
values)
  
  [TEST CASE]
  
  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
- On the console we can see that makedumpfile fails and `falls back to cp`. 
+ On the console we can see that makedumpfile fails and `falls back to cp`.
  In /var/crash we can see that no dmesg file is created and instead of the 
dump file
  the uncompressed vmcoreinfo is created.
  
  [WHERE PROBLEMS COULD OCCUR]
  
  The 3 commits pulled into focal make makedumpfile compatible with the 5.11 
kernel.
  Any regression potential would involve the crash dump not being created after 
a crash in case kdump is configured.
  
  [OTHER]
  
  Only Focal with 5.11 kernel is affected.

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

Title:
  makedumpfile not properly working on focal with 5.11 kernel

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Focal:
  In Progress
Status in makedumpfile source package in Hirsute:
  In Progress

Bug description:
  [IMPACT]

  When running Focal with the hwe 5.11 kernel makedumpfile is not working as it 
should.
  Instead of compressing the dump makedumpfile falls back to cp.
  This can create problems on systems with very large RAM and result into 
exhausting all storage on the host.
  This can be resolved with upstream commit f1197543d1c4 ([PATCH] Retrieve 
MAX_PHYSMEM_BITS from vmcoreinfo).
  The reason for falling back to cp is that without this patch makedumpfile 
calculates wrongly the memory layout.
  This happens after the kernel commit 1d50e5d0c505 ("crash_core, vmcoreinfo: 
Append 'MAX_PHYSMEM_BITS'to vmcoreinfo").
  With this commit applied, reading MAX_PHYSMEM_BITS from vmcoreinfo instead of 
inferring lead to correctly detecting the memory layout and creating the dump 
file properly. 

  In addition the dmesg. is not created.
  This can be resolved with the following two commits  :
  - commit c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  - commit 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state 
values)

  [TEST CASE]

  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
  On the console we can see that makedumpfile fails and `falls back to cp`.
  In /var/crash we can see that no dmesg file is created and instead of the 
dump file
  the uncompressed vmcoreinfo is created.

  [WHERE PROBLEMS COULD OCCUR]

  The 3 commits pulled into focal make makedumpfile compatible with the 5.11 
kernel.
  Any regression potential would involve the crash dump not being created after 
a crash in case kdump is configured.

  [OTHER]

  Only Focal with 5.11 kernel is affected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1942784/+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 1942784] Re: makedumpfile not properly working on focal with 5.11 kernel

2021-10-22 Thread Ioanna Alifieraki

New debdiff for focal.

** Patch added: "lp1942784_focal.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1942784/+attachment/5535296/+files/lp1942784_focal.debdiff

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

Title:
  makedumpfile not properly working on focal with 5.11 kernel

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Focal:
  In Progress
Status in makedumpfile source package in Hirsute:
  In Progress

Bug description:
  [IMPACT]

  When running Focal with the hwe 5.11 kernel makedumpfile is not working as it 
should.
  Instead of compressing the dump makedumpfile falls back to cp.
  This can create problems on systems with very large RAM and result into 
exhausting all storage on the host.
  This can be resolved with upstream commit f1197543d1c4 ([PATCH] Retrieve 
MAX_PHYSMEM_BITS from vmcoreinfo).
  The reason for falling back to cp is that without this patch makedumpfile 
calculates wrongly the memory layout.
  This happens after the kernel commit 1d50e5d0c505 ("crash_core, vmcoreinfo: 
Append 'MAX_PHYSMEM_BITS'to vmcoreinfo").
  With this commit applied, reading MAX_PHYSMEM_BITS from vmcoreinfo instead of 
inferring lead to correctly detecting the memory layout and creating the dump 
file properly. 

  In addition the dmesg. is not created.
  This can be resolved with the following two commits  :
  - commit c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  - commit 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state 
values)

  [TEST CASE]

  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
  On the console we can see that makedumpfile fails and `falls back to cp`.
  In /var/crash we can see that no dmesg file is created and instead of the 
dump file
  the uncompressed vmcoreinfo is created.

  [WHERE PROBLEMS COULD OCCUR]

  The 3 commits pulled into focal make makedumpfile compatible with the 5.11 
kernel.
  Any regression potential would involve the crash dump not being created after 
a crash in case kdump is configured.

  [OTHER]

  Only Focal with 5.11 kernel is affected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1942784/+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 1942784] Re: makedumpfile not properly working on focal with 5.11 kernel

2021-10-25 Thread Ioanna Alifieraki

Tested new debdiff on Focal with 5.4 and 5.11 kernels, on amd64, arm64, ppc64el 
and s390x and
works as expected.
Making Hirsute 'Invalid' as all patches in new debdiff are already in H.

** Changed in: makedumpfile (Ubuntu Hirsute)
   Status: In Progress => Invalid

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

Title:
  makedumpfile not properly working on focal with 5.11 kernel

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Focal:
  In Progress
Status in makedumpfile source package in Hirsute:
  Invalid

Bug description:
  [IMPACT]

  When running Focal with the hwe 5.11 kernel makedumpfile is not working as it 
should.
  Instead of compressing the dump makedumpfile falls back to cp.
  This can create problems on systems with very large RAM and result into 
exhausting all storage on the host.
  This can be resolved with upstream commit f1197543d1c4 ([PATCH] Retrieve 
MAX_PHYSMEM_BITS from vmcoreinfo).
  The reason for falling back to cp is that without this patch makedumpfile 
calculates wrongly the memory layout.
  This happens after the kernel commit 1d50e5d0c505 ("crash_core, vmcoreinfo: 
Append 'MAX_PHYSMEM_BITS'to vmcoreinfo").
  With this commit applied, reading MAX_PHYSMEM_BITS from vmcoreinfo instead of 
inferring lead to correctly detecting the memory layout and creating the dump 
file properly. 

  In addition the dmesg. is not created.
  This can be resolved with the following two commits  :
  - commit c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  - commit 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state 
values)

  [TEST CASE]

  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
  On the console we can see that makedumpfile fails and `falls back to cp`.
  In /var/crash we can see that no dmesg file is created and instead of the 
dump file
  the uncompressed vmcoreinfo is created.

  [WHERE PROBLEMS COULD OCCUR]

  The 3 commits pulled into focal make makedumpfile compatible with the 5.11 
kernel.
  Any regression potential would involve the crash dump not being created after 
a crash in case kdump is configured.

  [OTHER]

  Only Focal with 5.11 kernel is affected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1942784/+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 1921403] Re: makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

2021-10-25 Thread Ioanna Alifieraki

** Description changed:

+ 
+ [DESCRIPTION]
  makedumpfile does not create the dmesg. in /var/crash.
  This happens only on 5.10+ kernel because 5.10 kernel introduces a new
  lockless ringbuffer.
  
  This issue has been addressed upstream with commits :
  [1] c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  [2] 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state values)
  
+ [TEST CASE]
+ 
+ For testing a machine running focal with the 5.11 kernel is required.
+ Then trigger a crash.
+ After reboot make sure that dmesg. file is created in 
/var/crash/
+ 
+ [WHERE PROBLEMS COULD OCCUR]
+ 
+ Any problems would involve the dmesg file not created.
+ 
+ [Other]
+ 
  [1] 
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
  [2] 
https://github.com/makedumpfile/makedumpfile/commit/44b073b7ec467aee0d7de381d455b8ace1199184

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

Title:
  makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Focal:
  In Progress
Status in makedumpfile source package in Hirsute:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  [IMPACT]
  makedumpfile does not create the dmesg. in /var/crash.
  This happens only on 5.10+ kernel because 5.10 kernel introduces a new
  lockless ringbuffer.

  This issue has been addressed upstream with commits :
  [1] c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  [2] 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state values)

  [TEST CASE]

  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
  After reboot make sure that dmesg. file is created in 
/var/crash/

  [WHERE PROBLEMS COULD OCCUR]

  Any problems would involve the dmesg file not created.

  [Other]

  [1] 
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
  [2] 
https://github.com/makedumpfile/makedumpfile/commit/44b073b7ec467aee0d7de381d455b8ace1199184

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1921403/+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 1921403] Re: makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

2021-10-25 Thread Ioanna Alifieraki

** Description changed:

  [IMPACT]
- 
  makedumpfile does not create the dmesg. in /var/crash.
  This happens only on 5.10+ kernel because 5.10 kernel introduces a new
  lockless ringbuffer.
- 
- [FIX]
  
  This issue has been addressed upstream with commits :
  [1] c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  [2] 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state values)
  
  [TEST CASE]
  
  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
  After reboot make sure that dmesg. file is created in 
/var/crash/
  
  [WHERE PROBLEMS COULD OCCUR]
  
  Any problems would involve the dmesg file not created.
  
  [Other]
  
  [1] 
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
  [2] 
https://github.com/makedumpfile/makedumpfile/commit/44b073b7ec467aee0d7de381d455b8ace1199184

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

Title:
  makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Focal:
  In Progress
Status in makedumpfile source package in Hirsute:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  [IMPACT]
  makedumpfile does not create the dmesg. in /var/crash.
  This happens only on 5.10+ kernel because 5.10 kernel introduces a new
  lockless ringbuffer.

  This issue has been addressed upstream with commits :
  [1] c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  [2] 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state values)

  [TEST CASE]

  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
  After reboot make sure that dmesg. file is created in 
/var/crash/

  [WHERE PROBLEMS COULD OCCUR]

  Any problems would involve the dmesg file not created.

  [Other]

  [1] 
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
  [2] 
https://github.com/makedumpfile/makedumpfile/commit/44b073b7ec467aee0d7de381d455b8ace1199184

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1921403/+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 1942784] Re: makedumpfile falls back to cp on focal with 5.11 kernel

2021-10-27 Thread Ioanna Alifieraki

VERIFICATION ON FOCAL

Installed makedumpfile from proposed.
Testing on a Focal machine running 5.11 kernel.

# uname -rv
5.11.0-40-generic #44~20.04.1-Ubuntu SMP Wed Oct 20 19:04:34 UTC 2021

Trigger crash:
# echo 1 > /proc/sys/kernel/sysrq 
# echo c > /proc/sysrq-trigger

>From console output :

[   57.418037] kdump-tools[548]: Starting kdump-tools:
[   57.419099] kdump-tools[554]:  * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/202110271414/dump-incomplete
Copying data  : [100.0 %] /   eta: 
0s
[   61.481957] kdump-tools[572]: The kernel version is not supported.
[   61.494134] kdump-tools[572]: The makedumpfile operation may be incomplete.
[   61.501242] kdump-tools[572]: The dumpfile is saved to 
/var/crash/202110271414/dump-incomplete.
[   61.502711] kdump-tools[572]: makedumpfile Completed.
[   61.503885] kdump-tools[554]:  * kdump-tools: saved vmcore in 
/var/crash/202110271414
[   61.851266] kdump-tools[554]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202110271414/dmesg.202110271414
[   61.867626] kdump-tools[576]: The kernel version is not supported.
[   61.871305] kdump-tools[576]: The makedumpfile operation may be incomplete.
[   61.877902] kdump-tools[576]: The dmesg log is saved to 
/var/crash/202110271414/dmesg.202110271414.
[   61.881797] kdump-tools[576]: makedumpfile Completed.
[   61.885645] kdump-tools[554]:  * kdump-tools: saved dmesg content in 
/var/crash/202110271414
[   61.989595] kdump-tools[579]: Wed, 27 Oct 2021 14:14:21 +
[   62.123243] kdump-tools[580]: Rebooting.
[   62.561341] reboot: Restarting system

Makedumpfile compress the dump and does not fall back to cp.

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

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

Title:
  makedumpfile falls back to cp on focal with 5.11 kernel

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Focal:
  Fix Committed

Bug description:
  [IMPACT]

  When running Focal with the hwe 5.11 kernel makedumpfile is not working as it 
should.
  Instead of compressing the dump makedumpfile falls back to cp.
  This can create problems on systems with very large RAM and result into 
exhausting all storage on the host.

  [FIX]

  This can be resolved with upstream commit f1197543d1c4 ([PATCH] Retrieve 
MAX_PHYSMEM_BITS from vmcoreinfo).
  The reason for falling back to cp is that without this patch makedumpfile 
calculates wrongly the memory layout.

  This happens after the kernel commit 1d50e5d0c505 ("crash_core, vmcoreinfo: 
Append 'MAX_PHYSMEM_BITS'to vmcoreinfo").
  With this commit applied, reading MAX_PHYSMEM_BITS from vmcoreinfo instead of 
inferring lead to correctly detecting the memory layout and creating the dump 
file properly.

  [TEST CASE]

  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
  On the console we can see that makedumpfile fails and `falls back to cp`.
  In /var/crash we can see that no dmesg file is created and instead of the 
dump file
  the uncompressed vmcoreinfo is created.

  [WHERE PROBLEMS COULD OCCUR]

  Any regression potential would involve the crash dump not being
  created after a crash in case kdump is configured.

  [OTHER]

  Only Focal with 5.11 kernel is affected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1942784/+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 1921403] Re: makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

2021-10-27 Thread Ioanna Alifieraki

VERIFICATION FOCAL

Installed makedumpfile from proposed.
Testing on a Focal machine running 5.11 kernel.

# uname -rv
5.11.0-40-generic #44~20.04.1-Ubuntu SMP Wed Oct 20 19:04:34 UTC 2021

Trigger crash:
# echo 1 > /proc/sys/kernel/sysrq 
# echo c > /proc/sysrq-trigger

After reboot contents of /var/crash :
/var/crash/202110271414# ls
dmesg.202110271414  dump.202110271414

dmesg file has been successfully created.

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

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

Title:
  makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Focal:
  Fix Committed
Status in makedumpfile source package in Hirsute:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  [IMPACT]
  makedumpfile does not create the dmesg. in /var/crash.
  This happens only on 5.10+ kernel because 5.10 kernel introduces a new
  lockless ringbuffer.

  This issue has been addressed upstream with commits :
  [1] c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  [2] 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state values)

  [TEST CASE]

  For testing a machine running focal with the 5.11 kernel is required.
  Then trigger a crash.
  After reboot make sure that dmesg. file is created in 
/var/crash/

  [WHERE PROBLEMS COULD OCCUR]

  Any problems would involve the dmesg file not created.

  [Other]

  [1] 
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
  [2] 
https://github.com/makedumpfile/makedumpfile/commit/44b073b7ec467aee0d7de381d455b8ace1199184

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1921403/+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 2011421] Re: TDX azure instances crash during boot because of glibc bug

2023-06-13 Thread Ioanna Alifieraki

# VERIFICATION JAMMY - glibc

On an Azure TDX instance installed libc6 and libc-bin from -proposed and
rebooted. It boots successfully.

I also installed a test kernel with the kernel workaround reverted and it 
also boots with no problems.


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

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

Title:
  TDX azure instances crash during boot because of glibc bug

Status in glibc package in Ubuntu:
  New
Status in linux-azure package in Ubuntu:
  Fix Released
Status in glibc source package in Jammy:
  Fix Committed
Status in linux-azure source package in Jammy:
  Invalid
Status in glibc source package in Kinetic:
  Won't Fix
Status in linux-azure source package in Kinetic:
  In Progress
Status in glibc source package in Lunar:
  Fix Released
Status in linux-azure source package in Lunar:
  New

Bug description:
  [IMPACT]

  Glibc in jammy and kinetic is affected by the following bug :
  https://sourceware.org/bugzilla/show_bug.cgi?id=29953

  When cpuid reports no information on a shared cache, the
  x86_non_temporal_threshold will be set to zero, causing memcpy/memset to
  behave wrong for mid-sized operations. sysdeps/x86/dl-cacheinfo.h indicates
  that the minimum value must be 0x4040, but this is not enforced for the
  default value.

  The issue was reported because jammy tdx instances are failing to boot
  (crashing) on azure. The bug has been resolved upstream in
  
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=48b74865c63840b288bd85b4d8743533b73b339b

  [TEST CASE]

  Test case requires an azure tdx instance.
  Microsoft has tested a test package with the above commit and
  confirmed that instances boot successfully.

  [REGRESSION POTENTIAL]

  The patches have been accepted upstream. They modify code for x86 
architecture, so any
  potential regression would affect x86.

  [OTHER]

  Bug upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=29953
  Duplicate bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30037

  In jammy we need 2 commits :
  
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b446822b6ae4e8149902a78cdd4a886634ad6321
  
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=48b74865c63840b288bd85b4d8743533b73b339b

  In kinetic we just need :
  
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=48b74865c63840b288bd85b4d8743533b73b339b

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2011421/+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 2024479] [NEW] kdump fails on arm64 when offset is not specified

2023-06-20 Thread Ioanna Alifieraki

Public bug reported:

[Description]

kdump fails on arm64, on machines with a lot of memory when offeset is not 
specified,
e.g when /etc/default/grub.d/kdump-tools.cfg looks like:
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G"

If kdump-tools.cfg specifies the offset e.g.:
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=4G@4G"
it works ok.

The reason for this is that the kernel needs to allocate memory for the 
crashkernel both
in low and high memory.
This is addressed in kernel 6.2.
In addition kexec-tools needs to support more than one crash kernel regions.

To address this issue the following upstrem commits are needed:

>From the kernel side :
commit a9ae89df737756d92f0e14873339cf393f7f7eb0
Author: Zhen Lei 
Date: Wed Nov 16 20:10:44 2022 +0800

arm64: kdump: Support crashkernel=X fall back to reserve region above
DMA zones

commit a149cf00b158e1793a8dd89ca492379c366300d2
Author: Zhen Lei 
Date: Wed Nov 16 20:10:43 2022 +0800

arm64: kdump: Provide default size when crashkernel=Y,low is not
specified


>From kexec-tools
commit b5a34a20984c4ad27cc5054d9957af8130b42a50
Author: Chen Zhou 
Date: Mon Jan 10 18:20:08 2022 +0800

arm64: support more than one crash kernel regions

Affected releases:
Jammy, Focal, Bionic

For Bionic we won't fix it as we need to backport a lot of code and the 
regression potential is too high.
The same applies for the Focal 5.4 kernel.
Only the 5.15 hwe focal kernel will be fixed.


[Test]

You need a machine (can be a VM too) with large memory e.g. 128G.
Install linux-crashdump and trigger a crash.
It won't work unless the offset is specified because the memory crashkernel 
cannot be allocated.

With the patches applied it works as expected without having to specify
the offset.

[Regression Potential]


[Other]

Commits to backport

JAMMY:

kernel:
a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X 
fall back to reserve region above DMA zones
a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size 
when crashkernel=Y,low is not specified

kexec:
b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash 
kernel regions

FOCAL:

kernel (5.15 hwe kernel):
a9ae89df737756d92f0e14873339cf393f7f7eb0 arm64: kdump: Support crashkernel=X 
fall back to reserve region above DMA zones
a149cf00b158e1793a8dd89ca492379c366300d2 arm64: kdump: Provide default size 
when crashkernel=Y,low is not specified
4890cc18f94979b406f95708f8cb238eb2d0e5a9 arm64/mm: Define 
defer_reserve_crashkernel()
8f0f104e2ab6eed4cad3b111dc206f843bda43ea arm64: kdump: Do not allocate crash 
low memory if not needed
5832f1ae50600ac6b2b6d00cfef42d33a9473f06 docs: kdump: Update the crashkernel 
description for arm64
944a45abfabc171fd121315ff0d5e62b11cb5d6f arm64: kdump: Reimplement crashkernel=X
d339f1584f0acf32b32326627fa3b48e6e65c599 arm64: mm: use 
IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef


kexec:
b5a34a20984c4ad27cc5054d9957af8130b42a50 arm64: support more than one crash 
kernel regions
2572b8d702e452624bdb8d7b7c39f458e7dcf2ce arm64: kdump: deal with a lot of 
resource entries in /proc/iomem
cf977b1af9ec67fabcc6a625589c49c52d07b11d kexec: add variant helper functions 
for handling memory regions
f736104f533290b4ce6fbfbca74abde9ffd3888c arm64: kexec: allocate memory space 
avoiding reserved regions
64c49f27d88024eaab990d2cd6069289cf853098 arm64: Add support to read PHYS_OFFSET 
from 'kcore' - pt_note or pt_load (if available)
f4ce0706d9574aecb7d4aa9af7208a1bc9b6afb4 util_lib: Add functionality to read 
elf notes

** Affects: kexec-tools (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: kexec-tools (Ubuntu Focal)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Focal)
 Importance: Undecided
 Status: New

** Affects: kexec-tools (Ubuntu Jammy)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Jammy)
 Importance: Undecided
 Status: New

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

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

** Also affects: kexec-tools (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/2024479

Title:
  kdump fails on arm64 when offset is not specified

Status in kexec-tools package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New
Status in kexec-tools source package in Focal:
  New
Status in linux source package in Focal:
  New
Status in kexec-tools source package in Jammy:
  New
Status in linux source package in Jammy:
  New

Bug description:
  [Description]

  kdump fails on arm64, on machines with a lot of memory when offeset is not 
specified,
  e.g when /etc/default/grub.d/kd

[Kernel-packages] [Bug 1950666] [NEW] system crash when removing ipmi_msghandler module

2021-11-11 Thread Ioanna Alifieraki

Public bug reported:

[IMPACT]

Commit 3b9a907223d7 (ipmi: fix sleep-in-atomic in free_user at cleanup SRCU 
user->release_barrier)
pushes the removal of an ipmi_user into the system's workqueue.

Whenever an ipmi_user struct is about to be removed it is scheduled as a
work on the system's workqueue to guarantee the free operation won't be
executed in atomic context. When the work is executed the
free_user_work() function is invoked which frees the ipmi_user.

When ipmi_msghandler module is removed in cleanup_ipmi() function, there is no 
check if there are any pending works to be executed.
Therefore, there is a potential race condition :
An ipmi_user is scheduled for removal and shortly after to remove the 
ipmi_msghandler module.
If the scheduled work delays execution for any reason and the module is removed 
first, then when the work is executed the pages of free_user_work() are gone 
and the system crashes with the following :

BUG: unable to handle page fault for address: c05c3450
#PF: supervisor instruction fetch in kernel mode
#PF: error_code(0x0010) - not-present page
PGD 635420e067 P4D 635420e067 PUD 6354210067 PMD 4711e51067 PTE 0
Oops: 0010 [#1] SMP PTI
CPU: 19 PID: 29646 Comm: kworker/19:1 Kdump: loaded Not tainted 
5.4.0-77-generic #86~18.04.1-Ubuntu
Hardware name: Ciara Technologies ORION RS610-G4-DTH4S/MR91-FS1-Y9, BIOS F29 
05/23/2019
Workqueue: events 0xc05c3450
RIP: 0010:0xc05c3450
Code: Bad RIP value.
RSP: 0018:b721333c3e88 EFLAGS: 00010286
RAX: c05c3450 RBX: 92a95f56a740 RCX: b7221cfd14e8
RDX: 0001 RSI: 92616040d4b0 RDI: b7221cf404e0
RBP: b721333c3ec0 R08: 73746e657665 R09: 8080808080808080
R10: b721333c3de0 R11: fefefefefefefeff R12: 92a95f570700
R13: 92a0a40ece40 R14: b7221cf404e0 R15: 092a95f57070
FS: () GS:92a95f54() knlGS:
CS: 0010 DS:  ES:  CR0: 80050033
CR2: c05c3426 CR3: 0081e9bfc005 CR4: 007606e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
PKRU: 5554
Call Trace:
? process_one_work+0x20f/0x400
worker_thread+0x34/0x410
kthread+0x121/0x140
? process_one_work+0x400/0x400
? kthread_park+0x90/0x90
ret_from_fork+0x35/0x40
Modules linked in: xt_REDIRECT xt_owner ipt_rpfilter xt_CT xt_multiport xt_set 
ip_set_hash_ip veth xt_statistic ipt_REJECT
... megaraid_sas ahci libahci wmi [last unloaded: ipmi_msghandler]
CR2: c05c3450

[TEST CASE]

The user who reported the issue can reproduce reliably by stopping the ipmi 
related services and then removing the ipmi modules.
I could reproduce the issue only when turning the normal 'work' to delayed work.

[WHERE PROBLEMS COULD OCCUR]

TBD

[OTHER]

Upstream is affected too, working on a patch to address this.

** Affects: linux (Ubuntu)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: In Progress

** Affects: linux (Ubuntu Focal)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

** Affects: linux (Ubuntu Hirsute)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

** Affects: linux (Ubuntu Impish)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

** Affects: linux (Ubuntu Jammy)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: In Progress

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

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

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

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

** Changed in: linux (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Hirsute)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Impish)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Jammy)
   Importance: Undecided => Medium

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

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

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

** Changed in: linux (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: linux (Ubuntu Jammy)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux (Ubuntu Impish)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux (Ubuntu Hirsute)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux (Ubuntu Focal)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Description changed:

  [IMPACT]
  
  Commit 3b9a907223d7 (ipmi: fix sleep-in-atomic in free_user at cleanup S

[Kernel-packages] [Bug 1950666] Re: system crash when removing ipmi_msghandler module

2021-12-04 Thread Ioanna Alifieraki

** Description changed:

  [IMPACT]
  
  Commit 3b9a907223d7 (ipmi: fix sleep-in-atomic in free_user at cleanup SRCU 
user->release_barrier)
  pushes the removal of an ipmi_user into the system's workqueue.
  
  Whenever an ipmi_user struct is about to be removed it is scheduled as a
  work on the system's workqueue to guarantee the free operation won't be
  executed in atomic context. When the work is executed the
  free_user_work() function is invoked which frees the ipmi_user.
  
  When ipmi_msghandler module is removed in cleanup_ipmi() function, there is 
no check if there are any pending works to be executed.
  Therefore, there is a potential race condition :
  An ipmi_user is scheduled for removal and shortly after to remove the 
ipmi_msghandler module.
  If the scheduled work delays execution for any reason and the module is 
removed first, then when the work is executed the pages of free_user_work() are 
gone and the system crashes with the following :
  
  BUG: unable to handle page fault for address: c05c3450
  #PF: supervisor instruction fetch in kernel mode
  #PF: error_code(0x0010) - not-present page
  PGD 635420e067 P4D 635420e067 PUD 6354210067 PMD 4711e51067 PTE 0
  Oops: 0010 [#1] SMP PTI
  CPU: 19 PID: 29646 Comm: kworker/19:1 Kdump: loaded Not tainted 
5.4.0-77-generic #86~18.04.1-Ubuntu
  Hardware name: Ciara Technologies ORION RS610-G4-DTH4S/MR91-FS1-Y9, BIOS F29 
05/23/2019
  Workqueue: events 0xc05c3450
  RIP: 0010:0xc05c3450
  Code: Bad RIP value.
  RSP: 0018:b721333c3e88 EFLAGS: 00010286
  RAX: c05c3450 RBX: 92a95f56a740 RCX: b7221cfd14e8
  RDX: 0001 RSI: 92616040d4b0 RDI: b7221cf404e0
  RBP: b721333c3ec0 R08: 73746e657665 R09: 8080808080808080
  R10: b721333c3de0 R11: fefefefefefefeff R12: 92a95f570700
  R13: 92a0a40ece40 R14: b7221cf404e0 R15: 092a95f57070
  FS: () GS:92a95f54() knlGS:
  CS: 0010 DS:  ES:  CR0: 80050033
  CR2: c05c3426 CR3: 0081e9bfc005 CR4: 007606e0
  DR0:  DR1:  DR2: 
  DR3:  DR6: fffe0ff0 DR7: 0400
  PKRU: 5554
  Call Trace:
  ? process_one_work+0x20f/0x400
  worker_thread+0x34/0x410
  kthread+0x121/0x140
  ? process_one_work+0x400/0x400
  ? kthread_park+0x90/0x90
  ret_from_fork+0x35/0x40
  Modules linked in: xt_REDIRECT xt_owner ipt_rpfilter xt_CT xt_multiport 
xt_set ip_set_hash_ip veth xt_statistic ipt_REJECT
  ... megaraid_sas ahci libahci wmi [last unloaded: ipmi_msghandler]
  CR2: c05c3450
  
  [TEST CASE]
  
  The user who reported the issue can reproduce reliably by stopping the ipmi 
related services and then removing the ipmi modules.
  I could reproduce the issue only when turning the normal 'work' to delayed 
work.
  
  [WHERE PROBLEMS COULD OCCUR]
  
- TBD
+ The fixing patch creates a dedicated workqueue for the remove_work
+ struct of ipmi_user when loading the ipmi_msghandler modules and
+ destroys the workqueue when removing the module. Therefore any potential
+ problems would occur during these two operations or when scheduling
+ works on the dedicated workqueue.
  
  [OTHER]
  
- Upstream is affected too, working on a patch to address this.
+ Upstream patches : 
+ 1d49eb91e86e (ipmi: Move remove_work to dedicated workqueue)
+ 5a3ba99b62d8 (ipmi: msghandler: Make symbol 'remove_work_wq' static)

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

Title:
  system crash when removing ipmi_msghandler module

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Focal:
  Confirmed
Status in linux source package in Hirsute:
  Confirmed
Status in linux source package in Impish:
  Confirmed
Status in linux source package in Jammy:
  In Progress

Bug description:
  [IMPACT]

  Commit 3b9a907223d7 (ipmi: fix sleep-in-atomic in free_user at cleanup SRCU 
user->release_barrier)
  pushes the removal of an ipmi_user into the system's workqueue.

  Whenever an ipmi_user struct is about to be removed it is scheduled as
  a work on the system's workqueue to guarantee the free operation won't
  be executed in atomic context. When the work is executed the
  free_user_work() function is invoked which frees the ipmi_user.

  When ipmi_msghandler module is removed in cleanup_ipmi() function, there is 
no check if there are any pending works to be executed.
  Therefore, there is a potential race condition :
  An ipmi_user is scheduled for removal and shortly after to remove the 
ipmi_msghandler module.
  If the scheduled work delays execution for any reason and the module is 
removed first, then when the work is executed the pages of free_user_work() are 
gone and the system crashes with the following :

  BUG: unable to handle page fault for address: f

[Kernel-packages] [Bug 1950666] Re: system crash when removing ipmi_msghandler module

2022-01-19 Thread Ioanna Alifieraki

VERIFICATION

User that reported the issue has tested from -proposed and confirmed
that it works.

** Tags removed: verification-needed-focal verification-needed-hirsute 
verification-needed-impish
** Tags added: verification-done-focal verification-done-hirsute 
verification-done-impish

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

Title:
  system crash when removing ipmi_msghandler module

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Focal:
  Fix Committed
Status in linux source package in Hirsute:
  Fix Committed
Status in linux source package in Impish:
  Fix Committed
Status in linux source package in Jammy:
  In Progress

Bug description:
  [IMPACT]

  Commit 3b9a907223d7 (ipmi: fix sleep-in-atomic in free_user at cleanup SRCU 
user->release_barrier)
  pushes the removal of an ipmi_user into the system's workqueue.

  Whenever an ipmi_user struct is about to be removed it is scheduled as
  a work on the system's workqueue to guarantee the free operation won't
  be executed in atomic context. When the work is executed the
  free_user_work() function is invoked which frees the ipmi_user.

  When ipmi_msghandler module is removed in cleanup_ipmi() function, there is 
no check if there are any pending works to be executed.
  Therefore, there is a potential race condition :
  An ipmi_user is scheduled for removal and shortly after to remove the 
ipmi_msghandler module.
  If the scheduled work delays execution for any reason and the module is 
removed first, then when the work is executed the pages of free_user_work() are 
gone and the system crashes with the following :

  BUG: unable to handle page fault for address: c05c3450
  #PF: supervisor instruction fetch in kernel mode
  #PF: error_code(0x0010) - not-present page
  PGD 635420e067 P4D 635420e067 PUD 6354210067 PMD 4711e51067 PTE 0
  Oops: 0010 [#1] SMP PTI
  CPU: 19 PID: 29646 Comm: kworker/19:1 Kdump: loaded Not tainted 
5.4.0-77-generic #86~18.04.1-Ubuntu
  Hardware name: Ciara Technologies ORION RS610-G4-DTH4S/MR91-FS1-Y9, BIOS F29 
05/23/2019
  Workqueue: events 0xc05c3450
  RIP: 0010:0xc05c3450
  Code: Bad RIP value.
  RSP: 0018:b721333c3e88 EFLAGS: 00010286
  RAX: c05c3450 RBX: 92a95f56a740 RCX: b7221cfd14e8
  RDX: 0001 RSI: 92616040d4b0 RDI: b7221cf404e0
  RBP: b721333c3ec0 R08: 73746e657665 R09: 8080808080808080
  R10: b721333c3de0 R11: fefefefefefefeff R12: 92a95f570700
  R13: 92a0a40ece40 R14: b7221cf404e0 R15: 092a95f57070
  FS: () GS:92a95f54() knlGS:
  CS: 0010 DS:  ES:  CR0: 80050033
  CR2: c05c3426 CR3: 0081e9bfc005 CR4: 007606e0
  DR0:  DR1:  DR2: 
  DR3:  DR6: fffe0ff0 DR7: 0400
  PKRU: 5554
  Call Trace:
  ? process_one_work+0x20f/0x400
  worker_thread+0x34/0x410
  kthread+0x121/0x140
  ? process_one_work+0x400/0x400
  ? kthread_park+0x90/0x90
  ret_from_fork+0x35/0x40
  Modules linked in: xt_REDIRECT xt_owner ipt_rpfilter xt_CT xt_multiport 
xt_set ip_set_hash_ip veth xt_statistic ipt_REJECT
  ... megaraid_sas ahci libahci wmi [last unloaded: ipmi_msghandler]
  CR2: c05c3450

  [TEST CASE]

  The user who reported the issue can reproduce reliably by stopping the ipmi 
related services and then removing the ipmi modules.
  I could reproduce the issue only when turning the normal 'work' to delayed 
work.

  [WHERE PROBLEMS COULD OCCUR]

  The fixing patch creates a dedicated workqueue for the remove_work
  struct of ipmi_user when loading the ipmi_msghandler modules and
  destroys the workqueue when removing the module. Therefore any
  potential problems would occur during these two operations or when
  scheduling works on the dedicated workqueue.

  [OTHER]

  Upstream patches : 
  1d49eb91e86e (ipmi: Move remove_work to dedicated workqueue)
  5a3ba99b62d8 (ipmi: msghandler: Make symbol 'remove_work_wq' static)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1950666/+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 1931435] Re: crash fails to build on ubuntu 20.10 (Groovy) on arm64

2021-06-17 Thread Ioanna Alifieraki

#VERIFICATION GROOVY

Package can now be built from source without erros.

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

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

Title:
  crash fails to build on ubuntu 20.10 (Groovy) on arm64

Status in crash package in Ubuntu:
  Fix Released
Status in crash source package in Groovy:
  Fix Committed

Bug description:
  On arm64, crash fails to build with error "multiple definition of 
`tdesc_aarch64'" [1].
  From upstream git log, seems it can be resolved with commit 
e770735200c02ac2414c394ea6ec5f7f033efe64 .

  [1]
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.10.1/+build/21630861

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1931435/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

2021-06-17 Thread Ioanna Alifieraki

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

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Fix Committed
Status in linux source package in Focal:
  Fix Released
Status in crash source package in Groovy:
  Fix Committed
Status in linux source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

2021-05-18 Thread Ioanna Alifieraki

#VERIFICATION FOCAL - kernel part

Installed kernel from -proposed, triggered a crash and opened dump with crash.
Crash opens dump successfully (patched version of crash required with commit 
from description).

# crash usr/lib/debug/boot/vmlinux-5.4.0-1049-aws
/var/crash/202105181907/dump.202105181907

crash 7.2.8
Copyright (C) 2002-2020  Red Hat, Inc.
...

crash>

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Confirmed
Status in linux source package in Focal:
  Fix Committed
Status in crash source package in Groovy:
  Confirmed
Status in linux source package in Groovy:
  Fix Committed

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

2021-05-18 Thread Ioanna Alifieraki

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

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Confirmed
Status in linux source package in Focal:
  Fix Committed
Status in crash source package in Groovy:
  Confirmed
Status in linux source package in Groovy:
  Fix Committed

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

2021-05-18 Thread Ioanna Alifieraki

#VERIFICATION GROOVY - kernel part

Installed kernel from -proposed, triggered a crash and opened dump with crash.
Crash opens dump successfully (patched version of crash required with commit 
from description).

# crash usr/lib/debug/boot/vmlinux-5.8.0-1034-aws
/var/crash/202105182030/dump.202105182030

crash 7.2.8
Copyright (C) 2002-2020  Red Hat, Inc.


crash>

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

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Confirmed
Status in linux source package in Focal:
  Fix Committed
Status in crash source package in Groovy:
  Confirmed
Status in linux source package in Groovy:
  Fix Committed

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

** Changed in: crash (Ubuntu Bionic)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: crash (Ubuntu Focal)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: crash (Ubuntu Groovy)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux (Ubuntu Focal)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux (Ubuntu Groovy)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Fix Committed
Status in linux source package in Focal:
  Fix Committed
Status in crash source package in Groovy:
  Fix Committed
Status in linux source package in Groovy:
  Fix Committed

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

#VERIFICATION FOCAL - crash part

Installed crash from -proposed, triggered a crash and opened dump
with crash.
Crash opens dump successfully.

# crash usr/lib/debug/boot/vmlinux-5.4.0-1049-aws
/var/crash/202106021329/dump.202106021329

crash 7.2.8
Copyright (C) 2002-2020  Red Hat, Inc.

crash>

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Fix Committed
Status in linux source package in Focal:
  Fix Committed
Status in crash source package in Groovy:
  Fix Committed
Status in linux source package in Groovy:
  Fix Committed

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

#VERIFICATION BIONIC - crash part

Installed crash from -proposed, triggered a crash and opened dump
with crash.
Crash opens dump successfully.

~# crash usr/lib/debug/boot/vmlinux-5.4.0-1049-aws
/var/crash/202106021531/dump.202106021531

crash 7.2.8
Copyright (C) 2002-2020  Red Hat, Inc.

crash> 


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

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Fix Committed
Status in linux source package in Focal:
  Fix Committed
Status in crash source package in Groovy:
  Fix Committed
Status in linux source package in Groovy:
  Fix Committed

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

Verification for F and B done. On G build fails, I'll look into it and
update the bug.

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Fix Committed
Status in linux source package in Focal:
  Fix Committed
Status in crash source package in Groovy:
  Fix Committed
Status in linux source package in Groovy:
  Fix Committed

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1931431] [NEW] crash FTBFS on riscv64

Public bug reported:

Crash fails to build from source on riscv at least for Focal and Groovy,
later releases may also be affected but I haven't confirm it.

Examples of failed builds :

Groovy : 
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.10.1/+build/21630864
Focal : 
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.04.1/+build/21630885

** Affects: crash (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  crash FTBFS on riscv64

Status in crash package in Ubuntu:
  New

Bug description:
  Crash fails to build from source on riscv at least for Focal and
  Groovy, later releases may also be affected but I haven't confirm it.

  Examples of failed builds :

  Groovy : 
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.10.1/+build/21630864
  Focal : 
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.04.1/+build/21630885

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1931431/+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 1931432] [NEW] crash FTBFS on riscv64

Public bug reported:

Crash fails to build from source on riscv at least for Focal and Groovy,
later releases may also be affected but I haven't confirm it.

Examples of failed builds :

Groovy : 
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.10.1/+build/21630864
Focal : 
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.04.1/+build/21630885

** Affects: crash (Ubuntu)
 Importance: Medium
 Status: Confirmed

** Affects: crash (Ubuntu Focal)
 Importance: Medium
 Status: Confirmed

** Affects: crash (Ubuntu Groovy)
 Importance: Medium
 Status: Confirmed

** Changed in: crash (Ubuntu)
   Importance: Undecided => Medium

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

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

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

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

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

** Changed in: crash (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: crash (Ubuntu Groovy)
   Importance: Undecided => Medium

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

Title:
  crash FTBFS on riscv64

Status in crash package in Ubuntu:
  Confirmed
Status in crash source package in Focal:
  Confirmed
Status in crash source package in Groovy:
  Confirmed

Bug description:
  Crash fails to build from source on riscv at least for Focal and
  Groovy, later releases may also be affected but I haven't confirm it.

  Examples of failed builds :

  Groovy : 
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.10.1/+build/21630864
  Focal : 
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.04.1/+build/21630885

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1931432/+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 1931435] [NEW] crash fails to build on ubuntu 20.10 (Groovy) on arm64

Public bug reported:

On arm64, crash fails to build with error "multiple definition of 
`tdesc_aarch64'" [1].
>From upstream git log, seems it can be resolved with commit 
>e770735200c02ac2414c394ea6ec5f7f033efe64 .

[1]
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.10.1/+build/21630861

** Affects: crash (Ubuntu)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

** Affects: crash (Ubuntu Groovy)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

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

** Changed in: crash (Ubuntu)
   Importance: Undecided => Medium

** Changed in: crash (Ubuntu)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

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

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

** Changed in: crash (Ubuntu Groovy)
   Importance: Undecided => Medium

** Changed in: crash (Ubuntu Groovy)
     Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Description changed:

- On arm64, crash fails to build with error "multiple definition of 
`tdesc_aarch64'".
+ On arm64, crash fails to build with error "multiple definition of 
`tdesc_aarch64'" [1].
  From upstream git log, seems it can be resolved with commit 
e770735200c02ac2414c394ea6ec5f7f033efe64 .
+ 
+ [1]
+ 
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.10.1/+build/21630861

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

Title:
  crash fails to build on ubuntu 20.10 (Groovy) on arm64

Status in crash package in Ubuntu:
  Confirmed
Status in crash source package in Groovy:
  Confirmed

Bug description:
  On arm64, crash fails to build with error "multiple definition of 
`tdesc_aarch64'" [1].
  From upstream git log, seems it can be resolved with commit 
e770735200c02ac2414c394ea6ec5f7f033efe64 .

  [1]
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.10.1/+build/21630861

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1931435/+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 1931435] Re: crash fails to build on ubuntu 20.10 (Groovy) on arm64

Currently, working on it. Once I get hands on an arm vm I'll confirm the
fix and make a debdiff.

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

Title:
  crash fails to build on ubuntu 20.10 (Groovy) on arm64

Status in crash package in Ubuntu:
  Confirmed
Status in crash source package in Groovy:
  Confirmed

Bug description:
  On arm64, crash fails to build with error "multiple definition of 
`tdesc_aarch64'" [1].
  From upstream git log, seems it can be resolved with commit 
e770735200c02ac2414c394ea6ec5f7f033efe64 .

  [1]
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.10.1/+build/21630861

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1931435/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

The arm64 build failure on groovy is due to a commit missning regarding
gdb. See bug
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1931435.

On riscv64 it seems it never built successfully and the failure is irrelevant 
to the patch.
See bug https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1931432.

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Fix Committed
Status in linux source package in Focal:
  Fix Released
Status in crash source package in Groovy:
  Fix Committed
Status in linux source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1931435] Re: crash fails to build on ubuntu 20.10 (Groovy) on arm64

2021-06-10 Thread Ioanna Alifieraki

Debdiff for G.

** Patch added: "lp1931435_groovy.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1931435/+attachment/5503885/+files/lp1931435_groovy.debdiff

** Tags added: sts-sponsor-ddstreet

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

Title:
  crash fails to build on ubuntu 20.10 (Groovy) on arm64

Status in crash package in Ubuntu:
  Confirmed
Status in crash source package in Groovy:
  Confirmed

Bug description:
  On arm64, crash fails to build with error "multiple definition of 
`tdesc_aarch64'" [1].
  From upstream git log, seems it can be resolved with commit 
e770735200c02ac2414c394ea6ec5f7f033efe64 .

  [1]
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu1.20.10.1/+build/21630861

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1931435/+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 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

2021-04-13 Thread Ioanna Alifieraki

Debdiff for Bionic.

** Patch added: "lp1879214_bionic.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1879214/+attachment/5487329/+files/lp1879214_bionic.debdiff

** Also affects: makedumpfile (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Bionic:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed
Status in makedumpfile source package in Hirsute:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only

  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
  and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.

  From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
  great regression potentional and if any it would only affect arm64.

  Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  arm64 only
  Linux 5.4 and later kernels for arm64 changed the kernel VA space
  arrangement and introduced 52-bit kernel VAs by merging branch
  commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
  and 5.4+ kernels with best guessing.

  This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, page_offset
  Any regression potential would affect only arm64 and the

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

2021-04-13 Thread Ioanna Alifieraki

This bug also affects Bionic when 5.4 hwe kernel is used.

** Description changed:

  [Impact]
  
  On arm64 and kernels 5.4+ makedumpfile fails.
  
  Upstream patches solve this bug :
  
  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab
  
  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183
  
  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583
  
  [Test Case]
  
  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16
  
  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done
  
  [Regression Potential]
  
  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only
  
  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
  and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.
  
  From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
  great regression potentional and if any it would only affect arm64.
  
  Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  arm64 only
  Linux 5.4 and later kernels for arm64 changed the kernel VA space
  arrangement and introduced 52-bit kernel VAs by merging branch
  commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
  and 5.4+ kernels with best guessing.
  
  This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, page_offset
  Any regression potential would affect only arm64 and the calculation of the 
above variables.
  
  [Other]
  
  For H only the 3 commits are needed and they cherry-pick.
  
  For G and F the 3rd commit does not apply and an extra commit is needed
  :
  
  commit da0d25ffa585c9a1adb94562c815daa393b1ee5e
  [PATCH] arm64: Add support for ARMv8.2-LPA (52-bit PA support)
+ 
+ This bug also affects Bionic when 5.4 hwe kernel is used.

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Bionic:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed
Status i

[Kernel-packages] [Bug 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

** Changed in: crash (Ubuntu)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: crash (Ubuntu)
   Importance: Undecided => Medium

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  
  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  
  [Where problems could occur]

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

** Description changed:

+ [Impact]
+ 
  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:
  
  crash: cannot determine VA_BITS_ACTUAL
  
- This bug/change in crash provides a workaround for 5.4+
- https://github.com/crash-utility/crash/issues/52 kernels.
+ This bug has been addressed upstream and needed patches both in crash
+ and kernel.
+ 
+ Kernel patch :
+ 
+ commit bbdbc11804ff0b4130e7550113b452e96a74d16e
+ Author: Bhupesh Sharma 
+ Date:   Thu May 14 00:22:37 2020 +0530
+ arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
+ 
+ 
+ Crash patch :
+ 
+ commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
+ Author: Bhupesh Sharma 
+ Date:   Tue Jul 14 01:14:49 2020 +0530
+ 
+ arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ
+ 
+ 
+ [Test Case]
+ 
+ On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
+ It will fail with :
+ crash: cannot determine VA_BITS_ACTUAL
+ 
+ 
+ [Where problems could occur]
+ 
+ [Other]
+ 
+ Workaround :
+ This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.
  
  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  
  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  
  [Where problems could occur]

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

** Description changed:

  [Impact]
  
  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:
  
  crash: cannot determine VA_BITS_ACTUAL
  
  This bug has been addressed upstream and needed patches both in crash
  and kernel.
  
  Kernel patch :
  
  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
- arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
- 
+ arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
  
  Crash patch :
  
  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530
  
- arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ
- 
+ arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ
  
  [Test Case]
  
  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL
  
+ [Where problems could occur]
  
- [Where problems could occur]
+ Kernel patch :
+ 
+ The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
+ and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
+ Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.
+ 
+ Crash patch :
+ 
+ This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
+ The regression potential is small and any problem would regard reading this 
variable.
+ 
  
  [Other]
  
  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.
  
  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  
  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

** Also affects: crash-installer
   Importance: Undecided
   Status: New

** No longer affects: crash-installer

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  
  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

Focal kernel :
Patch submitted 
https://lists.ubuntu.com/archives/kernel-team/2021-April/119287.html

Groovy kernel : 
Patch submitted 
https://lists.ubuntu.com/archives/kernel-team/2021-April/119288.html

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

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

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

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

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

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

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

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

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

** Changed in: linux (Ubuntu Groovy)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu)
   Importance: Undecided => Medium

** Changed in: crash (Ubuntu Groovy)
   Importance: Undecided => Medium

** Changed in: crash (Ubuntu Focal)
   Importance: Undecided => Medium

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New
Status in crash source package in Focal:
  Confirmed
Status in linux source package in Focal:
  Confirmed
Status in crash source package in Groovy:
  Confirmed
Status in linux source package in Groovy:
  Confirmed

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  
  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

** Also affects: crash (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

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

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

** Description changed:

  [Impact]
  
  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:
  
  crash: cannot determine VA_BITS_ACTUAL
  
  This bug has been addressed upstream and needed patches both in crash
  and kernel.
  
  Kernel patch :
  
  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
  
  Crash patch :
  
  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530
  
  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ
  
+ 
+ Series affected :
+ 
+ Kenrel : 
+ This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
+ Hirsute already contains the commit and kernels prior to 5.3 are not affected.
+ 
+ Crash :
+ The commit is already in Hirsute.
+ Groovy, Focal and Bionic are affected.
+ In case of Bionic the bug appears only if 5.4 hwe kernel is used.
+ 
  [Test Case]
  
  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL
  
  [Where problems could occur]
  
  Kernel patch :
  
  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.
  
  Crash patch :
  
  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.
  
- 
  [Other]
  
  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.
  
  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Confirmed
Status in linux source package in Focal:
  Confirmed
Status in crash source package in Groovy:
  Confirmed
Status in linux source package in Groovy:
  Confirmed

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1

[Kernel-packages] [Bug 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

** Changed in: crash (Ubuntu Bionic)
   Importance: Undecided => Medium

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Confirmed
Status in linux source package in Focal:
  Confirmed
Status in crash source package in Groovy:
  Confirmed
Status in linux source package in Groovy:
  Confirmed

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1919275] Re: crash utility fails on arm64 with cannot determine VA_BITS_ACTUAL

** Merge proposal linked:
   
https://code.launchpad.net/~joalif/ubuntu/+source/crash/+git/crash/+merge/401229

** Merge proposal linked:
   
https://code.launchpad.net/~joalif/ubuntu/+source/crash/+git/crash/+merge/401230

** Merge proposal linked:
   
https://code.launchpad.net/~joalif/ubuntu/+source/crash/+git/crash/+merge/401231

** Merge proposal linked:
   
https://code.launchpad.net/~joalif/ubuntu/+source/crash/+git/crash/+merge/401232

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

Title:
  crash utility fails on arm64 with  cannot determine VA_BITS_ACTUAL

Status in crash package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in crash source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Invalid
Status in crash source package in Focal:
  Confirmed
Status in linux source package in Focal:
  Confirmed
Status in crash source package in Groovy:
  Confirmed
Status in linux source package in Groovy:
  Confirmed

Bug description:
  [Impact]

  On Ubuntu Bionic with the 5.4.0-1038-aws kernel the crash utility
  7.2.8-1ubuntu0.18.04 fails with:

  crash: cannot determine VA_BITS_ACTUAL

  This bug has been addressed upstream and needed patches both in crash
  and kernel.

  Kernel patch :

  commit bbdbc11804ff0b4130e7550113b452e96a74d16e
  Author: Bhupesh Sharma 
  Date:   Thu May 14 00:22:37 2020 +0530
  arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

  Crash patch :

  commit 1c45cea02df7f947b4296c1dcaefa1024235ef10
  Author: Bhupesh Sharma 
  Date:   Tue Jul 14 01:14:49 2020 +0530

  arm64: Change tcr_el1_t1sz variable name to TCR_EL1_T1SZ

  
  Series affected :

  Kenrel : 
  This affects Focal (5.4 kernel)  and Groovy (5.8 kernel).
  Hirsute already contains the commit and kernels prior to 5.3 are not affected.

  Crash :
  The commit is already in Hirsute.
  Groovy, Focal and Bionic are affected.
  In case of Bionic the bug appears only if 5.4 hwe kernel is used.

  [Test Case]

  On an arm64 host which runs the affected releases and kernels after creating 
a crashdump try to open it with crash.
  It will fail with :
  crash: cannot determine VA_BITS_ACTUAL

  [Where problems could occur]

  Kernel patch :

  The kernel patch reads the appropriate cpu register and exports TCR_EL1.T1SZ 
variable in vmcoreinfo. Given that this is a simple operation
  and that this patch landed upstream in 5.9 and no regressions have been 
reported, it is safe to assume that the regression potential is minimal.
  Any potential problem would occur in vmcoreinfo since this is where 
TCR_EL1.T1SZ variable is exported.

  Crash patch :

  This patch renames tcr_el1_t1sz variable to TCR_EL1_T1SZ to be compatible 
with the kernel change above for crash to be able to read it.
  The regression potential is small and any problem would regard reading this 
variable.

  [Other]

  Workaround :
  This bug/change in crash provides a workaround for 5.4+ 
https://github.com/crash-utility/crash/issues/52 kernels.

  While it appears as though it this was fixed it
  https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1858958 it still
  doesn't seem to work with a 5.4 kernel including. I also tested
  
https://launchpad.net/ubuntu/+source/crash/7.2.8-1ubuntu0.18.04.1/+build/18807621/+files/crash_7.2.8-1ubuntu0.18.04.1_arm64.deb
  and it exhibits the same problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1919275/+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 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

Debdiff for Groovy V2.

** Patch added: "lp1879214_groovy_v2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1879214/+attachment/5488487/+files/lp1879214_groovy_v2.debdiff

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Bionic:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed
Status in makedumpfile source package in Hirsute:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only

  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
  and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.

  From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
  great regression potentional and if any it would only affect arm64.

  Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  arm64 only
  Linux 5.4 and later kernels for arm64 changed the kernel VA space
  arrangement and introduced 52-bit kernel VAs by merging branch
  commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
  and 5.4+ kernels with best guessing.

  This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, page_offset
  Any regression potential would affect only arm64 and the calculation of the 
above variables.

  [Other]

  For H only the 3 commits are needed and they cherry-pick.

  For G and F the 3rd commit does not apply and

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

Debdiff for Focal V2.

** Patch added: "lp1879214_focal_v2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1879214/+attachment/5488488/+files/lp1879214_focal_v2.debdiff

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Bionic:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed
Status in makedumpfile source package in Hirsute:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only

  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
  and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.

  From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
  great regression potentional and if any it would only affect arm64.

  Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  arm64 only
  Linux 5.4 and later kernels for arm64 changed the kernel VA space
  arrangement and introduced 52-bit kernel VAs by merging branch
  commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
  and 5.4+ kernels with best guessing.

  This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, page_offset
  Any regression potential would affect only arm64 and the calculation of the 
above variables.

  [Other]

  For H only the 3 commits are needed and they cherry-pick.

  For G and F the 3rd commit does not apply and an

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

Debdiff for Bionic V2.

** Patch added: "lp1879214_bionic_v2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1879214/+attachment/5488489/+files/lp1879214_bionic_v2.debdiff

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Bionic:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed
Status in makedumpfile source package in Hirsute:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only

  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
  and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.

  From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
  great regression potentional and if any it would only affect arm64.

  Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  arm64 only
  Linux 5.4 and later kernels for arm64 changed the kernel VA space
  arrangement and introduced 52-bit kernel VAs by merging branch
  commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
  and 5.4+ kernels with best guessing.

  This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, page_offset
  Any regression potential would affect only arm64 and the calculation of the 
above variables.

  [Other]

  For H only the 3 commits are needed and they cherry-pick.

  For G and F the 3rd commit does not apply and

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

2021-04-26 Thread Ioanna Alifieraki

#VERIFICATION FOCAL

On an arm64 focal vm installed makedumpfile from -proposed and triggered a 
crash.
Crashdump file is created without any problems : 

[  131.348948] kdump-tools[521]: Starting kdump-tools:
[  131.350648] kdump-tools[527]:  * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/202104261059/dump-incomplete
[  OK  ] Started Hostname Service.
Copying data  : [100.0 %] |   eta: 
0s
[  136.780294] kdump-tools[544]: The dumpfile is saved to 
/var/crash/202104261059/dump-incomplete.
[  136.782771] kdump-tools[544]: makedumpfile Completed.
[  136.787843] kdump-tools[527]:  * kdump-tools: saved vmcore in 
/var/crash/202104261059
[  136.909187] kdump-tools[527]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202104261059/dmesg.202104261059
[  136.917750] kdump-tools[549]: The dmesg log is saved to 
/var/crash/202104261059/dmesg.202104261059.
[  136.919930] kdump-tools[549]: makedumpfile Completed.
[  136.924282] kdump-tools[527]:  * kdump-tools: saved dmesg content in 
/var/crash/202104261059
[  136.938369] kdump-tools[552]: Mon, 26 Apr 2021 11:00:01 +
[  136.947826] kdump-tools[553]: Rebooting.

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Bionic:
  Fix Committed
Status in makedumpfile source package in Focal:
  Fix Committed
Status in makedumpfile source package in Groovy:
  Fix Committed
Status in makedumpfile source package in Hirsute:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only

  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

2021-04-26 Thread Ioanna Alifieraki

#VERIFICATION BIONIC

On an arm64 bionic vm running 5.4 kernel installed makedumpfile
from -proposed and triggered a crash.
Crashdump file is created without any problems : 

[  130.240270] kdump-tools[632]: Starting kdump-tools:  * running makedumpfile 
-c -d 31 /proc/vmcore /var/crash/202104261056/dump-incomplete
Copying data  : [ 62.6 
[2021-04-26T10:56:38.86529Copying data  : 
[100.0 %] |   eta: 0s
[  143.377037] kdump-tools[632]: The kernel version is not supported.
[  143.378979] kdump-tools[632]: The makedumpfile operation may be incomplete.
[  143.383191] kdump-tools[632]: The dumpfile is saved to 
/var/crash/202104261056/dump-incomplete.
[  143.385712] kdump-tools[632]: makedumpfile Completed.
[  143.388291] kdump-tools[632]:  * kdump-tools: saved vmcore in 
/var/crash/202104261056
[  143.432646] kdump-tools[632]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202104261056/dmesg.202104261056
[  143.440986] kdump-tools[632]: The kernel version is not supported.
[  143.442600] kdump-tools[632]: The makedumpfile operation may be incomplete.
[  143.444345] kdump-tools[632]: The dmesg log is saved to 
/var/crash/202104261056/dmesg.202104261056.
[  143.446879] kdump-tools[632]: makedumpfile Completed.
[  143.448527] kdump-tools[632]:  * kdump-tools: saved dmesg content in 
/var/crash/202104261056
[  143.463805] kdump-tools[632]: Mon, 26 Apr 2021 10:56:38 +
[  143.473132] kdump-tools[632]: Rebooting.

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Bionic:
  Fix Committed
Status in makedumpfile source package in Focal:
  Fix Committed
Status in makedumpfile source package in Groovy:
  Fix Committed
Status in makedumpfile source package in Hirsute:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would af

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

2021-04-26 Thread Ioanna Alifieraki

#VERIFICATION GROOVY

On an arm64 groovy vm installed makedumpfile from -proposed and triggered a 
crash.
Crashdump file is created without any problems : 

[  192.577224] kdump-tools[528]: Starting kdump-tools:
[  192.579315] kdump-tools[534]:  * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/202104261101/dump-incomplete
[  OK  ] Started Hostname Service.
Copying data  : [100.0 %] \   eta: 
0s
[  198.320536] kdump-tools[551]: The kernel version is not supported.
[  198.322120] kdump-tools[551]: The makedumpfile operation may be incomplete.
[  198.323793] kdump-tools[551]: The dumpfile is saved to 
/var/crash/202104261101/dump-incomplete.
[  198.325900] kdump-tools[551]: makedumpfile Completed.
[  198.333425] kdump-tools[534]:  * kdump-tools: saved vmcore in 
/var/crash/202104261101
[  198.424133] kdump-tools[534]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202104261101/dmesg.202104261101
[  198.433298] kdump-tools[555]: The kernel version is not supported.
[  198.434926] kdump-tools[555]: The makedumpfile operation may be incomplete.
[  198.436644] kdump-tools[555]: The dmesg log is saved to 
/var/crash/202104261101/dmesg.202104261101.
[  198.438770] kdump-tools[555]: makedumpfile Completed.
[  198.440651] kdump-tools[534]:  * kdump-tools: saved dmesg content in 
/var/crash/202104261101
[  198.454465] kdump-tools[558]: Mon, 26 Apr 2021 11:01:48 +
[  198.464208] kdump-tools[559]: Rebooting.


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

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Bionic:
  Fix Committed
Status in makedumpfile source package in Focal:
  Fix Committed
Status in makedumpfile source package in Groovy:
  Fix Committed
Status in makedumpfile source package in Hirsute:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function

[Kernel-packages] [Bug 1922738] Re: 5.4 kernel: when iommu is on crashdump fails

2021-05-07 Thread Ioanna Alifieraki

VERIFICATION

Installed kernel from -proposed, enabled iommu rebooted and triggered a crash.
Crashdump generated successfully.

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

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

Title:
  5.4 kernel: when iommu is on crashdump fails

Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Focal:
  Fix Committed

Bug description:
  [IMPACT]

  When iommu is enabled crashdump fails to be collected because crash-kernel 
crashes
  with following trace [1].

  Commits that address it :

  1ddb32da4a62 iommu/vt-d: Simplify check in identity_mapping()
  96d170f3b1a6 iommu/vt-d: Remove deferred_attach_domain()
  a11bfde9c77d iommu/vt-d: Do deferred attachment in iommu_need_mapping()
  034d98cc0cdc iommu/vt-d: Move deferred device attachment into helper function
  1d4615978f52 iommu/vt-d: Add attach_deferred() helper
  1ee0186b9a12 iommu/vt-d: Refactor find_domain() helper

  [TEST CASE]

  Install a 5.4 kernel, add intel_iommu=on and iommu=pt to grub cmdline
  and trigger a crash.
  The crash kernel that boots will crash with trace [1].

  [REGRESSION POTENTIAL]

  1) 1ee0186b9a12 iommu/vt-d: Refactor find_domain() helper
  Refactors find_domain() into two helpers: 1) find_domain()
  only returns the domain in use; 2) deferred_attach_domain() does
  the deferred domain attachment if required and return the domain
  in use.

  2) 1d4615978f52 iommu/vt-d: Add attach_deferred() helper
  Add helper function to check if a device's attach process is deffered.
  Before this commit, this check was done with "dev->archdata.iommu == 
DEFER_DEVICE_DOMAIN_INFO".
  This commit wraps it into a function.
  Fixes (1).

  3) 034d98cc0cdc iommu/vt-d: Move deferred device attachment into helper 
function
  Takes the code that does the deffered attachment from 
deferred_attach_domain() function
  and places it in new do_deferred_attach() function.
  Fixes (1).

  4) a11bfde9c77d iommu/vt-d: Do deferred attachment in iommu_need_mapping()
  This one actually fixes the bug.
  Attachement of devive needs to happen before checking if device is identity 
mapped.
  Fixes (1).

  5) 96d170f3b1a6 iommu/vt-d: Remove deferred_attach_domain()
  Code cleanup, removes deferred_attach_domain() which now is just a wrapper 
around
  find_domain and calls directly find_domain from caller sites.
  Fixes (1).

  6) 1ddb32da4a62 iommu/vt-d: Simplify check in identity_mapping()
  Code cleanup.
  Fixes (1).

  Commits 2,3,5, and 6 are code movements/cleanups so little regression 
potential.
  Commit 1 is the intial code refactroring ( the rest of commits fix it) and 
commit
  3 fixes the bug.

  So far testing has not revealed any regression. Any possible regression will 
regard 
  device deffered attachment.

  [OTHER]

  Kernel affected 5.4.

  [1] https://pastebin.ubuntu.com/p/FNxTxjg3DV/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1922738/+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 1908428] Re: 4.4 kernel panics in kvm wake_up() handler

2021-02-18 Thread Ioanna Alifieraki

#VERIFICATION

The user who brought this bug to our attention, had tested a test kernel
with the relevant commits included and had confirmed that it addresses
the bug.

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

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

Title:
  4.4 kernel panics in kvm wake_up() handler

Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  [Description]

  User reported that 4.4 kernels are affected by the bug in [1].

  The bug presents itself with the following trace :

  [219901.424329] CPU: 19 PID: 0 Comm: swapper/19 Tainted: G   OE   
4.4.0-133-generic #159~14.04.1-Ubuntu
  [219901.441800] task: 885f62e63fc0 ti: 885f62e7c000 task.ti: 
885f62e7c000
  [219901.449408] RIP: 0010:[]  [] 
wakeup_handler+0x6d/0xa0 [kvm_intel]
  [219901.458791] RSP: 0018:885f7c043f70  EFLAGS: 00010083
  [219901.464217] RAX: 885f7c04 RBX: dead00b8 RCX: 
885f7c0586c0
  [219901.471480] RDX: dead0100 RSI:  RDI: 
885f7c0586b0
  [219901.478741] RBP: 885f7c043f90 R08:  R09: 
c7ffc2ec9069
  [219901.486003] R10: 0494 R11: 885f7c057370 R12: 
000186b0
  [219901.493267] R13: 0013 R14: 000186c0 R15: 
885f62e7c000
  [219901.500528] FS:  () GS:885f7c04() 
knlGS:
  [219901.511738] CS:  0010 DS:  ES:  CR0: 80050033
  [219901.517597] CR2: 7f6d57098000 CR3: 003183dfe000 CR4: 
00362670
  [219901.524860] DR0:  DR1:  DR2: 

  [219901.532121] DR3:  DR6: fffe0ff0 DR7: 
0400
  [219901.539384] Stack:
  [219901.541509]   0013  

  [219901.549120]  885f7c043fa8 8102fa99 81f40200 
885f62e7fe98
  [219901.556747]  8182131f 885f62e7fde8   885f62e7c000 

  [219901.565006] Call Trace:
  [219901.567567]  
  [219901.569592]  [] smp_kvm_posted_intr_wakeup_ipi+0x59/0x70
  [219901.576795]  [] kvm_posted_intr_wakeup_ipi+0xbf/0xd0
  [219901.583431]  
  [219901.585456]  [] ? hard_disable_TSC+0x30/0x30
  [219901.591621]  [] ? native_safe_halt+0x6/0x10
  [219901.597479]  [] default_idle+0x1e/0xe0
  [219901.602900]  [] arch_cpu_idle+0x15/0x20
  [219901.608416]  [] default_idle_call+0x2a/0x40
  [219901.614270]  [] cpu_startup_entry+0x2e0/0x350
  [219901.620305]  [] start_secondary+0x16c/0x190

  The root cause is blocked_vcpu_on_cpu list is corrupted.
  This bug is fixed  with the patchset found in [2].
  Only the first 3 (out of 4) of them have made their way in upstream kernel and
  are the ones needed to fix the bug.

  [Test case]
  It was not possible to reproduce this bug locally.
  A test kernel with the fixing patches has been provided to the user and they 
confirmed that it resolves the issue.

  [Regression Potential]

  The patches have been accepted upstream in 4.14 and so far there are no known 
regressions.
  Backporting the patches was necessary; original patches modify 
pi_pre/post_block functions which are not present in 4.4.
  These functions are introduced by upstream commit bc22512bb24c(kvm: vmx: 
rename vmx_pre/post_block to pi_pre/post_block).
  Appropriate changes where made for the patches to modify vmx_pre/post_block 
function without changing the functionality of the patches.
  Testing has not revealed any regressions.

  
  [Other]

  Only 4.4 kernels are affected.

  
  [1] https://marc.info/?l=kvm&m=149559827906211&w=2
  [2] https://lore.kernel.org/lkml/20170606105707.23207-1-pbonz...@redhat.com/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1908428/+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 1920759] [NEW] kdump-tools passes wrong arguments to makedumpfile

2021-03-22 Thread Ioanna Alifieraki

Public bug reported:

Commit 38fe0c8f41fd (Support compressing the dumpfile) [1] 
changes the call to makedumpfile : 
- makedumpfile $MAKEDUMP_ARGS $vmcore_file "$KDUMP_CORETEMP"
+ makedumpfile $MAKEDUMP_ARGS $vmcore_file | compress > "$KDUMP_CORETEMP"

This introduces a regression because makedumpfile is called with the wrong 
arguments and as a result instead of creating a real dumpfile it creates
a file which contains an error message : 

# cat /var/crash/202103181853/dump.202103181853 
makedumpfile: version 1.6.8++ (released on 16 Nov 2020)
command line: makedumpfile -c -d 31 -D /proc/vmcore 

Commandline parameter is invalid.
Try `makedumpfile --help' for more information.

makedumpfile Failed.


[1] 
https://salsa.debian.org/debian/kdump-tools/-/commit/38fe0c8f41fd0deeafa3719ab5e82d8b536d8b17

** Affects: kdump-tools (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: kdump-tools (Ubuntu Hirsute)
 Importance: Undecided
 Status: New

** Also affects: kdump-tools (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

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

Title:
  kdump-tools passes wrong arguments to makedumpfile

Status in kdump-tools package in Ubuntu:
  New
Status in kdump-tools source package in Hirsute:
  New

Bug description:
  Commit 38fe0c8f41fd (Support compressing the dumpfile) [1] 
  changes the call to makedumpfile : 
  - makedumpfile $MAKEDUMP_ARGS $vmcore_file "$KDUMP_CORETEMP"
  + makedumpfile $MAKEDUMP_ARGS $vmcore_file | compress > "$KDUMP_CORETEMP"

  This introduces a regression because makedumpfile is called with the wrong 
  arguments and as a result instead of creating a real dumpfile it creates
  a file which contains an error message : 

  # cat /var/crash/202103181853/dump.202103181853 
  makedumpfile: version 1.6.8++ (released on 16 Nov 2020)
  command line: makedumpfile -c -d 31 -D /proc/vmcore 

  Commandline parameter is invalid.
  Try `makedumpfile --help' for more information.

  makedumpfile Failed.

  
  [1] 
https://salsa.debian.org/debian/kdump-tools/-/commit/38fe0c8f41fd0deeafa3719ab5e82d8b536d8b17

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/1920759/+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 1920759] Re: kdump-tools passes wrong arguments to makedumpfile

2021-03-22 Thread Ioanna Alifieraki

** Bug watch added: Debian Bug tracker #985716
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985716

** Also affects: kdump-tools (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985716
   Importance: Unknown
   Status: Unknown

** Changed in: kdump-tools (Ubuntu Hirsute)
   Importance: Undecided => Medium

** Changed in: kdump-tools (Ubuntu Hirsute)
   Status: New => Confirmed

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

Title:
  kdump-tools passes wrong arguments to makedumpfile

Status in kdump-tools package in Ubuntu:
  Confirmed
Status in kdump-tools source package in Hirsute:
  Confirmed
Status in kdump-tools package in Debian:
  Unknown

Bug description:
  Commit 38fe0c8f41fd (Support compressing the dumpfile) [1] 
  changes the call to makedumpfile : 
  - makedumpfile $MAKEDUMP_ARGS $vmcore_file "$KDUMP_CORETEMP"
  + makedumpfile $MAKEDUMP_ARGS $vmcore_file | compress > "$KDUMP_CORETEMP"

  This introduces a regression because makedumpfile is called with the wrong 
  arguments and as a result instead of creating a real dumpfile it creates
  a file which contains an error message : 

  # cat /var/crash/202103181853/dump.202103181853 
  makedumpfile: version 1.6.8++ (released on 16 Nov 2020)
  command line: makedumpfile -c -d 31 -D /proc/vmcore 

  Commandline parameter is invalid.
  Try `makedumpfile --help' for more information.

  makedumpfile Failed.

  
  [1] 
https://salsa.debian.org/debian/kdump-tools/-/commit/38fe0c8f41fd0deeafa3719ab5e82d8b536d8b17

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/1920759/+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 1921403] [NEW] makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

2021-03-25 Thread Ioanna Alifieraki

Public bug reported:

makedumpfile does not create the dmesg. in /var/crash.
This happens only on 5.10+ kernel because 5.10 kernel introduces a new
lockless ringbuffer.

This issue has been addressed upstream with commits :
[1] c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
[2] 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state values)

[1] 
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
[2] 
https://github.com/makedumpfile/makedumpfile/commit/44b073b7ec467aee0d7de381d455b8ace1199184

** Affects: makedumpfile (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: makedumpfile (Ubuntu Hirsute)
 Importance: Undecided
 Status: New

** Affects: makedumpfile (Debian)
 Importance: Unknown
 Status: Unknown

** Also affects: makedumpfile (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

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

Title:
  makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

Status in makedumpfile package in Ubuntu:
  New
Status in makedumpfile source package in Hirsute:
  New
Status in makedumpfile package in Debian:
  Unknown

Bug description:
  makedumpfile does not create the dmesg. in /var/crash.
  This happens only on 5.10+ kernel because 5.10 kernel introduces a new
  lockless ringbuffer.

  This issue has been addressed upstream with commits :
  [1] c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  [2] 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state values)

  [1] 
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
  [2] 
https://github.com/makedumpfile/makedumpfile/commit/44b073b7ec467aee0d7de381d455b8ace1199184

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1921403/+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 1921403] Re: makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

2021-03-25 Thread Ioanna Alifieraki

** Bug watch added: Debian Bug tracker #985896
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985896

** Also affects: makedumpfile (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985896
   Importance: Unknown
   Status: Unknown

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

Title:
  makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

Status in makedumpfile package in Ubuntu:
  New
Status in makedumpfile source package in Hirsute:
  New
Status in makedumpfile package in Debian:
  Unknown

Bug description:
  makedumpfile does not create the dmesg. in /var/crash.
  This happens only on 5.10+ kernel because 5.10 kernel introduces a new
  lockless ringbuffer.

  This issue has been addressed upstream with commits :
  [1] c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  [2] 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state values)

  [1] 
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
  [2] 
https://github.com/makedumpfile/makedumpfile/commit/44b073b7ec467aee0d7de381d455b8ace1199184

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1921403/+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 1922738] [NEW] 5.4 kernel: when iommu is on crashdump fails

2021-04-06 Thread Ioanna Alifieraki

Public bug reported:

[IMPACT]

When iommu is enabled crashdump fails to be collected because crash-kernel 
crashes
with following trace [1].

Commits that address it :

1ddb32da4a62 iommu/vt-d: Simplify check in identity_mapping()
96d170f3b1a6 iommu/vt-d: Remove deferred_attach_domain()
a11bfde9c77d iommu/vt-d: Do deferred attachment in iommu_need_mapping()
034d98cc0cdc iommu/vt-d: Move deferred device attachment into helper function
1d4615978f52 iommu/vt-d: Add attach_deferred() helper
1ee0186b9a12 iommu/vt-d: Refactor find_domain() helper

[TEST CASE]

Install a 5.4 kernel, add intel_iommu=on and iommu=pt to grub cmdline
and trigger a crash.
The crash kernel that boots will crash with trace [1].

[REGRESSION POTENTIAL]

[OTHER]

Kernel affected 5.4.

[1] https://pastebin.ubuntu.com/p/FNxTxjg3DV/

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Incomplete

** Affects: linux (Ubuntu Focal)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: Confirmed

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

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

** Changed in: linux (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Focal)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Description changed:

+ [IMPACT]
+ 
  When iommu is enabled crashdump fails to be collected because crash-kernel 
crashes
- with following trace [1]. 
+ with following trace [1].
  
  Commits that address it :
  
  1ddb32da4a62 iommu/vt-d: Simplify check in identity_mapping()
  96d170f3b1a6 iommu/vt-d: Remove deferred_attach_domain()
- a11bfde9c77d iommu/vt-d: Do deferred attachment in iommu_need_mapping() 
+ a11bfde9c77d iommu/vt-d: Do deferred attachment in iommu_need_mapping()
  034d98cc0cdc iommu/vt-d: Move deferred device attachment into helper function
  1d4615978f52 iommu/vt-d: Add attach_deferred() helper
  1ee0186b9a12 iommu/vt-d: Refactor find_domain() helper
  
+ [TEST CASE]
+ 
+ Install a 5.4 kernel, add intel_iommu=on and iommu=pt to grub cmdline
+ and trigger a crash.
+ The crash kernel that boots will crash with trace [1].
+ 
+ [REGRESSION POTENTIAL]
+ 
+ [OTHER]
+ 
  Kernel affected 5.4.
  
  [1] https://pastebin.ubuntu.com/p/FNxTxjg3DV/

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

Title:
  5.4 kernel: when iommu is on crashdump fails

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Focal:
  Confirmed

Bug description:
  [IMPACT]

  When iommu is enabled crashdump fails to be collected because crash-kernel 
crashes
  with following trace [1].

  Commits that address it :

  1ddb32da4a62 iommu/vt-d: Simplify check in identity_mapping()
  96d170f3b1a6 iommu/vt-d: Remove deferred_attach_domain()
  a11bfde9c77d iommu/vt-d: Do deferred attachment in iommu_need_mapping()
  034d98cc0cdc iommu/vt-d: Move deferred device attachment into helper function
  1d4615978f52 iommu/vt-d: Add attach_deferred() helper
  1ee0186b9a12 iommu/vt-d: Refactor find_domain() helper

  [TEST CASE]

  Install a 5.4 kernel, add intel_iommu=on and iommu=pt to grub cmdline
  and trigger a crash.
  The crash kernel that boots will crash with trace [1].

  [REGRESSION POTENTIAL]

  [OTHER]

  Kernel affected 5.4.

  [1] https://pastebin.ubuntu.com/p/FNxTxjg3DV/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1922738/+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 1922738] Re: 5.4 kernel: when iommu is on crashdump fails

2021-04-06 Thread Ioanna Alifieraki

** Description changed:

  [IMPACT]
  
  When iommu is enabled crashdump fails to be collected because crash-kernel 
crashes
  with following trace [1].
  
  Commits that address it :
  
  1ddb32da4a62 iommu/vt-d: Simplify check in identity_mapping()
  96d170f3b1a6 iommu/vt-d: Remove deferred_attach_domain()
  a11bfde9c77d iommu/vt-d: Do deferred attachment in iommu_need_mapping()
  034d98cc0cdc iommu/vt-d: Move deferred device attachment into helper function
  1d4615978f52 iommu/vt-d: Add attach_deferred() helper
  1ee0186b9a12 iommu/vt-d: Refactor find_domain() helper
  
  [TEST CASE]
  
  Install a 5.4 kernel, add intel_iommu=on and iommu=pt to grub cmdline
  and trigger a crash.
  The crash kernel that boots will crash with trace [1].
  
  [REGRESSION POTENTIAL]
  
+ 1) 1ee0186b9a12 iommu/vt-d: Refactor find_domain() helper
+ Refactors find_domain() into two helpers: 1) find_domain()
+ only returns the domain in use; 2) deferred_attach_domain() does
+ the deferred domain attachment if required and return the domain
+ in use.
+ 
+ 2) 1d4615978f52 iommu/vt-d: Add attach_deferred() helper
+ Add helper function to check if a device's attach process is deffered.
+ Before this commit, this check was done with "dev->archdata.iommu == 
DEFER_DEVICE_DOMAIN_INFO".
+ This commit wraps it into a function.
+ Fixes (1).
+ 
+ 3) 034d98cc0cdc iommu/vt-d: Move deferred device attachment into helper 
function
+ Takes the code that does the deffered attachment from 
deferred_attach_domain() function
+ and places it in new do_deferred_attach() function.
+ Fixes (1).
+ 
+ 4) a11bfde9c77d iommu/vt-d: Do deferred attachment in iommu_need_mapping()
+ This one actually fixes the bug.
+ Attachement of devive needs to happen before checking if device is identity 
mapped.
+ Fixes (1).
+ 
+ 5) 96d170f3b1a6 iommu/vt-d: Remove deferred_attach_domain()
+ Code cleanup, removes deferred_attach_domain() which now is just a wrapper 
around
+ find_domain and calls directly find_domain from caller sites.
+ Fixes (1).
+ 
+ 6) 1ddb32da4a62 iommu/vt-d: Simplify check in identity_mapping()
+ Code cleanup.
+ Fixes (1).
+ 
+ Commits 2,3,5, and 6 are code movements/cleanups so little regression 
potential.
+ Commit 1 is the intial code refactroring ( the rest of commits fix it) and 
commit
+ 3 fixes the bug.
+ 
+ So far testing has not revealed any regression. Any possible regression will 
regard 
+ device deffered attachment.
+ 
  [OTHER]
  
  Kernel affected 5.4.
  
  [1] https://pastebin.ubuntu.com/p/FNxTxjg3DV/

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

Title:
  5.4 kernel: when iommu is on crashdump fails

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Focal:
  Confirmed

Bug description:
  [IMPACT]

  When iommu is enabled crashdump fails to be collected because crash-kernel 
crashes
  with following trace [1].

  Commits that address it :

  1ddb32da4a62 iommu/vt-d: Simplify check in identity_mapping()
  96d170f3b1a6 iommu/vt-d: Remove deferred_attach_domain()
  a11bfde9c77d iommu/vt-d: Do deferred attachment in iommu_need_mapping()
  034d98cc0cdc iommu/vt-d: Move deferred device attachment into helper function
  1d4615978f52 iommu/vt-d: Add attach_deferred() helper
  1ee0186b9a12 iommu/vt-d: Refactor find_domain() helper

  [TEST CASE]

  Install a 5.4 kernel, add intel_iommu=on and iommu=pt to grub cmdline
  and trigger a crash.
  The crash kernel that boots will crash with trace [1].

  [REGRESSION POTENTIAL]

  1) 1ee0186b9a12 iommu/vt-d: Refactor find_domain() helper
  Refactors find_domain() into two helpers: 1) find_domain()
  only returns the domain in use; 2) deferred_attach_domain() does
  the deferred domain attachment if required and return the domain
  in use.

  2) 1d4615978f52 iommu/vt-d: Add attach_deferred() helper
  Add helper function to check if a device's attach process is deffered.
  Before this commit, this check was done with "dev->archdata.iommu == 
DEFER_DEVICE_DOMAIN_INFO".
  This commit wraps it into a function.
  Fixes (1).

  3) 034d98cc0cdc iommu/vt-d: Move deferred device attachment into helper 
function
  Takes the code that does the deffered attachment from 
deferred_attach_domain() function
  and places it in new do_deferred_attach() function.
  Fixes (1).

  4) a11bfde9c77d iommu/vt-d: Do deferred attachment in iommu_need_mapping()
  This one actually fixes the bug.
  Attachement of devive needs to happen before checking if device is identity 
mapped.
  Fixes (1).

  5) 96d170f3b1a6 iommu/vt-d: Remove deferred_attach_domain()
  Code cleanup, removes deferred_attach_domain() which now is just a wrapper 
around
  find_domain and calls directly find_domain from caller sites.
  Fixes (1).

  6) 1ddb32da4a62 iommu/vt-d: Simplify check in identity_mapping()
  Code cleanup.
  Fixes (1).

  Commits 2,3,5, and 6 are code movements/cleanups so little regressi

[Kernel-packages] [Bug 1921403] Re: makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

2021-04-07 Thread Ioanna Alifieraki

** Changed in: makedumpfile (Ubuntu Hirsute)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

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

Title:
  makedumpfile does not create dmesg file in /var/crash on 5.10+ kernels

Status in makedumpfile package in Ubuntu:
  New
Status in makedumpfile source package in Hirsute:
  New
Status in makedumpfile package in Debian:
  New

Bug description:
  makedumpfile does not create the dmesg. in /var/crash.
  This happens only on 5.10+ kernel because 5.10 kernel introduces a new
  lockless ringbuffer.

  This issue has been addressed upstream with commits :
  [1] c617ec633392([PATCH 1/2] printk: add support for lockless ringbuffer)
  [2] 44b073b7ec46([PATCH 2/2] printk: use committed/finalized state values)

  [1] 
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
  [2] 
https://github.com/makedumpfile/makedumpfile/commit/44b073b7ec467aee0d7de381d455b8ace1199184

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1921403/+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 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

2021-04-07 Thread Ioanna Alifieraki

** Bug watch added: Debian Bug tracker #986594
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986594

** Also affects: makedumpfile (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986594
   Importance: Unknown
   Status: Unknown

** Changed in: makedumpfile (Ubuntu Groovy)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: makedumpfile (Ubuntu Focal)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed
Status in makedumpfile source package in Hirsute:
  Confirmed
Status in makedumpfile package in Debian:
  Unknown

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only

  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
  and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.

  From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
  great regression potentional and if any it would only affect arm64.

  Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  arm64 only
  Linux 5.4 and later kernels for arm64 changed the kernel VA space
  arrangement and introduced 52-bit kernel VAs by merging branch
  commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
  and 5.4+ kernels with best guessing.

  This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, pag

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

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

** Also affects: makedumpfile (Ubuntu Hirsute)
   Importance: Undecided
 Assignee: Ioanna Alifieraki (joalif)
   Status: Confirmed

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

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Confirmed
Status in makedumpfile source package in Focal:
  New
Status in makedumpfile source package in Groovy:
  New
Status in makedumpfile source package in Hirsute:
  Confirmed

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only

  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
  and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.

  From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
  great regression potentional and if any it would only affect arm64.

  
  Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  arm64 only
  Linux 5.4 and later kernels for arm64 changed the kernel VA space
  arrangement and introduced 52-bit kernel VAs by merging branch
  commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
  and 5.4+ kernels with best guessing.

  This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, page_offset
  Any regression potential would affect only arm64 and the calculation of the 
above variables.

  [Other]

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

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

** Description changed:

+ [Impact]
+ 
+ On arm64 and kernels 5.4+ makedumpfile fails.
+ 
+ Upstream patches solve this bug :
+ 
+ [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
+ 
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab
+ 
+ [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
+ 
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183
+ 
+ [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
+ 
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583
+ 
+ [Test Case]
+ 
  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16
  
- 
  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done
+ 
+ [Regression Potential]
+ 
+ Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
+ removes get_elf_loads function this function was only used with --mem-usage 
option
+ , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
+ the information needed is in vmcoreinfo
+ Any regression potential would affect the --mem-usage only
+ 
+ Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
+ arm64 only
+ make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
+ does not work on Linux 5.4 and later.
+ Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
+ this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
+ and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.
+ 
+ From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
+ great regression potentional and if any it would only affect arm64.
+ 
+ 
+ Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
+ arm64 only
+ Linux 5.4 and later kernels for arm64 changed the kernel VA space
+ arrangement and introduced 52-bit kernel VAs by merging branch
+ commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
+ and 5.4+ kernels with best guessing.
+ 
+ This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, page_offset
+ Any regression potential would affect only arm64 and the calculation of the 
above variables.
+ 
+ [Other]

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Confirmed
Status in makedumpfile source package in Focal:
  New
Status in makedumpfile source package in Groovy:
  New
Status in makedumpfile source package in Hirsute:
  Confirmed

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/comm

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

Debdiff for H.

** Description changed:

  [Impact]
  
  On arm64 and kernels 5.4+ makedumpfile fails.
  
  Upstream patches solve this bug :
  
  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab
  
  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183
  
  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583
  
  [Test Case]
  
  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16
  
  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done
  
  [Regression Potential]
  
  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only
  
  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
  and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.
  
  From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
  great regression potentional and if any it would only affect arm64.
  
- 
  Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  arm64 only
  Linux 5.4 and later kernels for arm64 changed the kernel VA space
  arrangement and introduced 52-bit kernel VAs by merging branch
  commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
  and 5.4+ kernels with best guessing.
  
  This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, page_offset
  Any regression potential would affect only arm64 and the calculation of the 
above variables.
  
  [Other]
+ 
+ For H only the 3 commits are needed and they cherry-pick.
+ 
+ For G and F the 3rd commit does not apply and an extra commit is needed
+ :
+ 
+ commit da0d25ffa585c9a1adb94562c815daa393b1ee5e
+ [PATCH] arm64: Add support for ARMv8.2-LPA (52-bit PA support)

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

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

** Patch added: "lp1879214_hirsute.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1879214/+attachment/5472235/+files/lp1879214_hirsute.debdiff

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile pack

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

Debdiff for H.

** Patch added: "lp1879214_hirsute.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1879214/+attachment/5472236/+files/lp1879214_hirsute.debdiff

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed
Status in makedumpfile source package in Hirsute:
  Confirmed

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only

  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
  and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.

  From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
  great regression potentional and if any it would only affect arm64.

  Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  arm64 only
  Linux 5.4 and later kernels for arm64 changed the kernel VA space
  arrangement and introduced 52-bit kernel VAs by merging branch
  commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
  and 5.4+ kernels with best guessing.

  This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, page_offset
  Any regression potential would affect only arm64 and the calculation of the 
above variables.

  [Other]

  For H only the 3 commits are needed and they cherry-pick.

  For G and F the 3rd commit does not apply and an extra commit is
  needed :

  commit da0d25ffa585c9a1adb94562c815daa393b1ee5e
  [PATCH] arm64: Add support for ARMv8.2-LPA (52-bit PA

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

Debdiff for G.

** Patch added: "lp1879214_groovy.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1879214/+attachment/5472237/+files/lp1879214_groovy.debdiff

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed
Status in makedumpfile source package in Hirsute:
  Confirmed

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only

  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
  and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.

  From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
  great regression potentional and if any it would only affect arm64.

  Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  arm64 only
  Linux 5.4 and later kernels for arm64 changed the kernel VA space
  arrangement and introduced 52-bit kernel VAs by merging branch
  commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
  and 5.4+ kernels with best guessing.

  This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, page_offset
  Any regression potential would affect only arm64 and the calculation of the 
above variables.

  [Other]

  For H only the 3 commits are needed and they cherry-pick.

  For G and F the 3rd commit does not apply and an extra commit is
  needed :

  commit da0d25ffa585c9a1adb94562c815daa393b1ee5e
  [PATCH] arm64: Add support for ARMv8.2-LPA (52-bit PA s

[Kernel-packages] [Bug 1879214] Re: Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported

Debdiff for F.

** Patch added: "lp1879214_focal.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1879214/+attachment/5472238/+files/lp1879214_focal.debdiff

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

Title:
  Package makedumpfile 1:1.6.7-1ubuntu2(arm64) failed to
  makedumpfile:calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47
  not supported

Status in makedumpfile package in Ubuntu:
  Confirmed
Status in makedumpfile source package in Focal:
  Confirmed
Status in makedumpfile source package in Groovy:
  Confirmed
Status in makedumpfile source package in Hirsute:
  Confirmed

Bug description:
  [Impact]

  On arm64 and kernels 5.4+ makedumpfile fails.

  Upstream patches solve this bug :

  [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage option
  
https://github.com/makedumpfile/makedumpfile/commit/d8b701796f0491f2ac4b06c7a5b795c29399efab

  [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  
https://github.com/makedumpfile/makedumpfile/commit/67d0e1d68f28c567a704fd6b9b8fd696ad3df183

  [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  
https://github.com/makedumpfile/makedumpfile/commit/a0216b678a95f099a16172cc4a67ad5aa6a89583

  [Test Case]

  OS: Ubuntu 20.04 LTS
  kernel: 5.4.0-21-generic
  arch:arm64
  Description:
  When testing kdump on Ubuntu 20.04 LTS (arm64), makedumpfile fails. The test 
steps are as follows:
  # echo 1> / proc / sys / kernel / sysrq
  # echo c> / proc / sysrq-trigger
  The error logs are as follows:
  [   26.599161] kdump-tools[653]: Starting kdump-tools:
  [   26.612761] kdump-tools[659]: Starting kdump-tools:
  [   26.628565] kdump-tools[659]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.648621] kdump-tools[676]: * running makedumpfile -c -d 31 /proc/vmcore 
/var/crash/2020050
  [   26.668445] kdump-tools[676]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   26.678199] kdump-tools[676]: get_machdep_info_arm64
  [   26.692518] kdump-tools[659]: get_machdep_info_arm64
  [   26.852221] hns3 :7d:00.0: get link status cmd failed -16

  [   94.351303] kdump-tools[659]: * kdump-tools: makedumpfile failed, * 
kdump-tools: saved vmcore in /var/crash/202005061048
  [   94.435510] kdump-tools[659]:  * running makedumpfile --dump-dmesg 
/proc/vmcore /var/crash/202005061048/dmesg.202005061048
  [   94.457103] kdump-tools[688]: calculate_plat_config: PAGE SIZE 0x1000 and 
VA Bits 47 not supported
  [   94.476228] kdump-tools[688]: get_machdep_info_arm64: Can't determine 
platform config values
  [   94.485912] kdump-tools[688]: makedumpfile Failed.
  [   94.500760] kdump-tools[659]:  * kdump-tools: makedumpfile --dump-dmesg 
failed. dmesg content will be unavailable
  [   94.520225] kdump-tools[659]:  * kdump-tools: failed to save dmesg content 
in /var/crash/202005061048
  [   94.544205] kdump-tools[691]: Wed, 06 May 2020 10:49:42 -0400
  [   94.564597] kdump-tools[692]: Rebooting.
  [   94.678709] reboot: Restarting systemlpc uart init Done

  [Regression Potential]

  Patch 1 : [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for --mem-usage 
option
  removes get_elf_loads function this function was only used with --mem-usage 
option
  , since kernel commit kernel commit 23c85094fe18 (kernel versions >4.19)
  the information needed is in vmcoreinfo
  Any regression potential would affect the --mem-usage only

  Patch 2 : [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in vmcoreinfo
  arm64 only
  make use of NUMBER(VA_BITS) in vmcoreinfo as the current way of guessing 
VA_BITS
  does not work on Linux 5.4 and later.
  Before this commit VA_BITS would be calculated in get_versiondep_info_arm64, 
however
  this way of calculation breaks after 5.4. This commit gets the VA_BITS from 
vmcoreinfo
  and as a safeguard it uses the old way of deriving VA_BITS only if reading 
from vmcoreinfo doesn't work.

  From the kernel side VA_BITS is in vmcoreinfo since kernel 4.12, F and later 
use later kernel so not
  great regression potentional and if any it would only affect arm64.

  Patch 3 : [PATCH 3/3] arm64: support flipped VA and 52-bit kernel VA
  arm64 only
  Linux 5.4 and later kernels for arm64 changed the kernel VA space
  arrangement and introduced 52-bit kernel VAs by merging branch
  commit b333b0ba2346.  Support 5.9+ kernels with vmcoreinfo entries
  and 5.4+ kernels with best guessing.

  This patch makes adjustemnt to properly calculate vabits_actual, 
max_physmem_bits, page_offset
  Any regression potential would affect only arm64 and the calculation of the 
above variables.

  [Other]

  For H only the 3 commits are needed and they cherry-pick.

  For G and F the 3rd commit does not apply and an extra commit is
  needed :

  commit da0d25ffa585c9a1adb94562c815daa393b1ee5e
  [PATCH] arm64: Add support for ARMv8.2-LPA (52-bit PA sup

[Kernel-packages] [Bug 2042568] [NEW] Azure - Kernel crashes when removing gpu from pci

Public bug reported:

[Description]

[Test Case]


[Where things could go wrong]


[Other]

** Affects: linux-azure (Ubuntu)
 Importance: Medium
 Status: New

** Affects: linux-azure (Ubuntu Jammy)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: New

** Affects: linux-azure (Ubuntu Lunar)
 Importance: Medium
 Assignee: Ioanna Alifieraki (joalif)
 Status: New

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

** Changed in: linux (Ubuntu)
   Importance: Undecided => Medium

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

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

** Changed in: linux (Ubuntu Jammy)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux (Ubuntu Lunar)
 Assignee: (unassigned) => Ioanna Alifieraki (joalif)

** Changed in: linux (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Lunar)
   Importance: Undecided => Medium

** Package changed: linux (Ubuntu) => linux-azure (Ubuntu)

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

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

Title:
  Azure - Kernel crashes when removing gpu from pci

Status in linux-azure package in Ubuntu:
  New
Status in linux-azure source package in Jammy:
  New
Status in linux-azure source package in Lunar:
  New

Bug description:
  [Description]

  [Test Case]

  
  [Where things could go wrong]

  
  [Other]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/2042568/+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 2042568] Re: Azure - Kernel crashes when removing gpu from pci

** Description changed:

  [Description]
+ 
+ On a VM on Azure with a Tesla gpu it was noticed that when removing the
+ gpu from the pci the vm would crash. In case the nvidia drivers are
+ loaded, the machine won't crash. Instead the removing process will hang
+ and the machine will crash on reboot.
+ 
+ This is related to bug [1].
+ The bug reported in [1] regards another driver but the root cause is the same.
+ It is still investigated whether this is a bug in pci, or it is a bug of 
various drivers on how they use pci.
+ 
+ For this case we have identified that removing commit [2] prevents the
+ kernel crashes.
+ 
+ Azure has requested to revert this commit, at least for the time being.
+ This commit is not in upstream, so it just need to be reverted from Ubuntu 
kernels.
  
  [Test Case]
  
+ On an Azure vm with a gpu :
+ 
+ # echo '1' > /sys/bus/pci/devices/0001:00:00.0/remove
+ 
+ where '0001:00:00.0' the pci address of the gpu.
+ The vm will crash.
  
  [Where things could go wrong]
  
+ [Other]
  
- [Other]
+ [1] https://bugzilla.kernel.org/show_bug.cgi?id=215515
+ [2] 
https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-azure/+git/jammy/commit/?h=Ubuntu-azure-5.15.0-1043.50&id=75af0c10b3703400890d314d1d91d25294234a81

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

Title:
  Azure - Kernel crashes when removing gpu from pci

Status in linux-azure package in Ubuntu:
  New
Status in linux-azure source package in Jammy:
  New
Status in linux-azure source package in Lunar:
  New

Bug description:
  [Description]

  On a VM on Azure with a Tesla gpu it was noticed that when removing
  the gpu from the pci the vm would crash. In case the nvidia drivers
  are loaded, the machine won't crash. Instead the removing process will
  hang and the machine will crash on reboot.

  This is related to bug [1].
  The bug reported in [1] regards another driver but the root cause is the same.
  It is still investigated whether this is a bug in pci, or it is a bug of 
various drivers on how they use pci.

  For this case we have identified that removing commit [2] prevents the
  kernel crashes.

  Azure has requested to revert this commit, at least for the time being.
  This commit is not in upstream, so it just need to be reverted from Ubuntu 
kernels.

  [Test Case]

  On an Azure vm with a gpu :

  # echo '1' > /sys/bus/pci/devices/0001:00:00.0/remove

  where '0001:00:00.0' the pci address of the gpu.
  The vm will crash.

  [Where things could go wrong]

  [Other]

  [1] https://bugzilla.kernel.org/show_bug.cgi?id=215515
  [2] 
https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-azure/+git/jammy/commit/?h=Ubuntu-azure-5.15.0-1043.50&id=75af0c10b3703400890d314d1d91d25294234a81

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/2042568/+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 2042568] Re: Azure - Kernel crashes when removing gpu from pci

** Description changed:

[Description]

On a VM on Azure with a Tesla gpu it was noticed that when removing the
gpu from the pci the vm would crash. In case the nvidia drivers are
loaded, the machine won't crash. Instead the removing process will hang
and the machine will crash on reboot.

For this case we have identified that removing commit [2] prevents the
kernel crashes.

Azure has requested to revert this commit, at least for the time being.
This commit is not in upstream, so it just need to be reverted from Ubuntu
kernels.

[Test Case]

On an Azure vm with a gpu :

# echo '1' > /sys/bus/pci/devices/0001:00:00.0/remove

where '0001:00:00.0' the pci address of the gpu.
The vm will crash.

[Where things could go wrong]

+ The commit to be reverted was included in a patchset to address lp bugs
+ https://bugs.launchpad.net/bugs/2023071 and
+ https://bugs.launchpad.net/bugs/2023594
+
+ However this commit just reduces boot time and removing shall not introduce
any regressions.
+ Side effects will be increase in the boot time.
+
[Other]
+
+ Only Ubuntu azure kernels are affected :
+
+ - Jammy 5.15
+ - Lunar 6.2
+
+ Focal is also affected since it's using 5.15 kernel.
+ This commit does not appear in Mantic 6.5 kernel.
+
+

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

Title:
Azure - Kernel crashes when removing gpu from pci

Status in linux-azure package in Ubuntu:
New
Status in linux-azure source package in Jammy:
New
Status in linux-azure source package in Lunar:
New

Bug description:
[Description]

For this case we have identified that removing commit [2] prevents the
kernel crashes.

Azure has requested to revert this commit, at least for the time being.
This commit is not in upstream, so it just need to be reverted from Ubuntu
kernels.

[Test Case]

On an Azure vm with a gpu :

# echo '1' > /sys/bus/pci/devices/0001:00:00.0/remove

where '0001:00:00.0' the pci address of the gpu.
The vm will crash.

[Where things could go wrong]

The commit to be reverted was included in a patchset to address lp
bugs https://bugs.launchpad.net/bugs/2023071 and
https://bugs.launchpad.net/bugs/2023594

However this commit just reduces boot time and removing shall not introduce
any regressions.
Side effects will be increase in the boot time.

[Other]

Only Ubuntu azure kernels are affected :

- Jammy 5.15
- Lunar 6.2

Focal is also affected since it's using 5.15 kernel.
This commit does not appear in Mantic 6.5 kernel.

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

[Kernel-packages] [Bug 2042568] Re: Azure - Kernel crashes when removing gpu from pci