I can't answer what is happening here. But can you obtain more information
using SysRq-t
and SysRq-m as described at
https://akari.osdn.jp/capturing-kernel-messages.html#Tips5 ?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
Since 18.04 seems to give up LSM stacking patchset, safest choice (if
acceptable) would be to completely revert LSM stacking patchset for
17.10 as well.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Thanks for reporting. This is a duplicate of bug 1734327 .
--
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/1752621
Title:
BUG: unable to handle kernel paging request at ded533a0
No plan to land upstream yet. Casey's upstream proposal
(
http://kernsec.org/pipermail/linux-security-module-archive/2017-December/004728.html
) is stalling.
Please carry my patch as UBUNTU: SAUCE: patch.
--
You received this bug notification because you are a member of Kernel
Packages, which
Since you are using apparmor=0 parameter,
this will be a duplicate of bug 1734327.
Try removing apparmor=0 parameter for now.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1749221
You can monitor
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1744199 .
--
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/1744071
Title:
linux 3.13.0-140.189 - kernel panic after
F.Y.I. Here is the kernel panic message.
You can google for "PANIC: double fault, error_code: 0x0".
[ 193.361839] PANIC: double fault, error_code: 0x0
[ 193.363960] Kernel panic - not syncing: Machine halted.
[ 193.366020] CPU: 1 PID: 1822 Comm: a.out Not tainted 3.13.0-140-generic
The problematic patches are not yet in mainline/upstream kernels,
and hence the fix patch is not yet in mainline/upstream kernels.
Please ask Joseph Salisbury when the action for Artful kernel will be
taken.
--
You received this bug notification because you are a member of Kernel
Packages,
OK. Your report will be duplicate of 1731031, 1734327, 1734686.
Explanation of the bug is
http://kernsec.org/pipermail/linux-security-module-archive/2017-November/004532.html
and the fix for the bug is
http://kernsec.org/pipermail/linux-security-module-archive/2017-December/004638.html
.
Forgot to mention. Try removing apparmor=0 parameter for now.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734686
--
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/1742572
Title:
The dump looks like below bug. Was the bug already fixed in 4.13.0-25.29
?
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1731031
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734327
--
You received this bug notification because you are a member of Kernel
Packages, which is
As far as I can see, nothing is wrong, except you put too much memory
pressure on your machine.
--
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/1739928
Title:
Kernel segfault playing
Well, not 6 seconds. It is 21 seconds.
I overlooked that timestamp in syslog and uptime are not in sync.
--
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/1739928
Title:
Kernel segfault
It seems to me that this is not a kernel problem.
I guess that there was a NULL pointer dereference in RSG-Linux-Shipping when
the system started entering severe memory pressure. Then, due to severe memory
pressure, many memory allocation requests started stalling. But there is no
kernel oops
Thank you for reporting this problem. Ubuntu 17.10 kernel has
"LSM: Stacking for major security modules" patches enabled and
this problem will be a bug in the patches. That's why mainline
4.13.11 kernel works fine.
I reported this problem at
Just a comment from a security module developer.
What happens if you pass security=none to kernel command line options
(i.e. disable AppArmor security module), for I think it might help
isolating the problem because you are hitting oops at
security_vm_enough_memory_mm() and security_file_free().
Recent distros can silently hang due to insufficient RAM while decompressing
kernel image. Did you give enough RAM?
--
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/1303657
Title:
Cannot
Hello, Marco.
The problem handled by this entry is about mptsas_probe() hitting
scsi4: error handler thread failed to spawn, error = -12
mptsas: ioc0: WARNING - Unable to register controller with SCSI subsystem
BUG: unable to handle kernel NULL pointer dereference at 0060
due
(a) Linux kernel guys think that a hardcoded timeout is a systemd bug.
https://lkml.org/lkml/2014/3/23/42
(b) The systemd guys think that kernel module loading takes more than
30 seconds is a kernel module's bug. But Linux kernel guys won't
be able to fix it immediately. Also,
PierreF wrote:
Applied patch on tag v3.14-rc6 (fa389e2), run kernel 4 four times, all
worked.
Thank you!
Now we proved that systemd-udevd's 30 seconds timeout is the trigger of
this problem. It would be best if we can fix systemd side.
Joseph, is there any possibility that systemd-udevd's
Pierre, would you give me a hand? I proposed the final patch but
I'm unable to prove that SIGKILL sent by systemd-udevd's 30 seconds
timeout is the trigger of this problem, for I don't have a real
machine which takes very long time upon initialization.
According to
I reproduced a similar result using test patch shown below.
-- test patch start --
diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index 5653e50..eaaa5e2 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -1412,6
Thank you. I missed that we are not allowed to call wait_for_completion() again
if wait_for_completion_timeout() succeeded, for do_wait_for_common() does
x-done-- which cancels x-done++ done by complete(). I must update this patch.
--
You received this bug notification because you are a member
I changed this patch to call wait_for_completion() again only if
wait_for_completion_timeout() returned 0, for
wait_for_completion_timeout() will return non-0 if completed.
** Patch added: kthread: defer leaving kthread_create() upon SIGKILL. (v2)
Great!
I updated this patch to be more OOM killer friendly.
I will propose this patch for 3.14-final.
** Patch added: Final patch
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+attachment/4026689/+files/kthread-Do-not-leave-kthread_create-immediately.patch
--
You received
OK. I read this thread.
I'm sure that somebody is sending SIGKILL to the systemd-udevd process
who is doing finit_module() system call, after waiting for 30 seconds.
However, since the probe function takes more than 30 seconds, the probe
function already received SIGKILL by the moment
Would you try this patch?
** Patch added: kthread: defer leaving kthread_create() upon SIGKILL.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/+attachment/4026192/+files/kthread-defer-leaving.patch
--
You received this bug notification because you are a member of Kernel
starvation because the OOM killer cannot kill such users.
kthread_create() is one of such users and this patch fixes the problem for
kthreadd by making kthread_create() killable.
Signed-off-by: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Cc: Oleg Nesterov o...@redhat.com
Acked-by: David Rientjes rient
28 matches
Mail list logo
