This bug was fixed in the package linux - 4.15.0-29.31
---
linux (4.15.0-29.31) bionic; urgency=medium
* linux: 4.15.0-29.31 -proposed tracker (LP: #1782173)
* [SRU Bionic][Cosmic] kernel panic in ipmi_ssif at msg_done_handler
(LP: #116)
- ipmi_ssif: Fix kernel panic
This bug was fixed in the package linux - 4.15.0-29.31
---
linux (4.15.0-29.31) bionic; urgency=medium
* linux: 4.15.0-29.31 -proposed tracker (LP: #1782173)
* [SRU Bionic][Cosmic] kernel panic in ipmi_ssif at msg_done_handler
(LP: #116)
- ipmi_ssif: Fix kernel panic
Verification results:
ubuntu@d05-6:~$ sudo ./stress
+ umount /tmp/mnt
umount: /tmp/mnt: not mounted.
+ /bin/true
+ mkdir -p /tmp/mnt
+ mkfs.ext4 -F /dev/sda1
mke2fs 1.44.1 (24-Mar-2018)
/dev/sda1 contains a ext4 file system
last mounted on Wed Jul 11 23:26:23 2018
/dev/sda1 alignment is
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
bionic' to 'verification-done-bionic'. If the problem still exists,
change the tag
** Changed in: linux (Ubuntu)
Status: Triaged => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1780137
Title:
[Regression] EXT4-fs error (device sda1):
@dannf, my command is
`while true; do sudo /usr/lib/plainbox-provider-
checkbox/bin/disk_stress_ng sda --base-time 240 --really-run; mkfs.ext4
-F /dev/sda2; done`
But I also find out that the e2fsprogs I am using is upstream one.
mke2fs 1.44.3-rc2 (3-July-2018)
I am going to reset my
** Changed in: linux (Ubuntu Bionic)
Status: Triaged => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1780137
Title:
[Regression] EXT4-fs error (device sda1):
** Description changed:
- We're seeing a very reproducible regression in the bionic kernel
- triggered by the stress-ng chdir test performed by the Ubuntu
- certification suite. We see this on both the HiSilicon D05 arm64 server
- and the HiSilicon D06 arm64 server. We have been unable to
@Ike: Let me know if the above sounds plausible. I should also make the
following notes, which may provide evidence counter to my theory of pre-
existing corruption:
It is possible that mkfs.ext4 was ran outside of sudo (e.g. directly in
a root shell), and would therefore not be logged in
Copying over comments from Ike from a different forum:
Ike Panhc (ikepanhc) wrote on 2018-07-09: #42
I build kernel debs based on Ted's response on ext4 mailing list at
http://kernel.ubuntu.com/~ikepanhc/ext4msg61578/
Please also see
https://www.spinics.net/lists/linux-ext4/msg61578.html
I am no longer able to reproduce after applying Ted's patch. I was able
to run my unit test 20 times w/o failing on upstream + patch on d05-6. I
then switched over to the Ubuntu kernel + patch, and it has now passed
64 times (and counting).
I then looked to see why Ike is still observing a
I would be useful to see if a non-SMP boot will cause the same issue; if
it only occurs in SMP boots then we know it's a lower level locking/race
style of problem.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Upstream thread: https://lkml.org/lkml/2018/7/6/763
--
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/1780137
Title:
[Regression] EXT4-fs error (device sda1):
The significant difference in the cert test wrapper actually appears to
be that it creates a directory in which to run the test, vs. running it
at the root of the mount point. I'm able to reproduce the failure
outside of cert after a fresh reboot with the following script. The fs
.aio-max-nr
** Description changed:
We're seeing a very reproducible regression in the bionic kernel
triggered by the stress-ng chdir test performed by the Ubuntu
- certification suite. Platform is a HiSilicon D05 arm64 server, but we
- don't have reason to believe it is platform specific at this time.
+
It may be worth grabbing a copy of the /proc/sys on a clean boot and
then a copy after the sysctl changes so we can get and idea of any
specific tweaks that may have occurred.
Just to note, I've been running the stress-ng command as noted in
comment #3 on a 24 CPU ARM64 Synquacer box with the
On Thu, Jul 5, 2018 at 9:35 AM Colin Ian King
<1780...@bugs.launchpad.net> wrote:
>
> What is the stress-ng command that is being run by /usr/lib/plainbox-
> provider-checkbox/bin/disk_stress_ng - without knowing that it's hard to
> figure out the initial stressor conditions
It runs several
What is the stress-ng command that is being run by /usr/lib/plainbox-
provider-checkbox/bin/disk_stress_ng - without knowing that it's hard to
figure out the initial stressor conditions
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Tags added: kernel-da-key
** Changed in: linux (Ubuntu)
Status: Incomplete => Triaged
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Bionic)
19 matches
Mail list logo
