--- Comment From hbath...@in.ibm.com 2019-05-20 13:34 EDT---
(In reply to comment #61)
> Issue is now "Fix Released" everywhere except Xenial. Should this now be
> backported to Xenial or would that incur too much regression risk?
No regressions expected but would be better off taking
--- Comment From hbath...@in.ibm.com 2019-05-10 11:40 EDT---
(In reply to comment #53)
[...]
> bionic? I know newer kernels may have regressed when crashing from the
> non-boot CPU, which should affect 4.18 kernels and later, but not 4.15.
Raised launchpad bug 1828597 to follow-up on
--- Comment From hbath...@in.ibm.com 2019-05-10 11:32 EDT---
(In reply to comment #55)
> (In reply to comment #53)
> [...]
> > could proceed with the SRU, and open a new bug to fix the CPU hotplug case,
> > if there is one.
>
> Raised bug 177551 to follow-up on the problem in CPU hot-add
--- Comment From hbath...@in.ibm.com 2019-05-10 07:10 EDT---
(In reply to comment #53)
[...]
> could proceed with the SRU, and open a new bug to fix the CPU hotplug case,
> if there is one.
Raised bug 177551 to follow-up on the problem in CPU hot-add case which
is currently being screened
--- Comment From hbath...@in.ibm.com 2019-05-07 15:03 EDT---
While I initially suggested the udev below rules:
SUBSYSTEM=="memory", ACTION=="online", PROGRAM="/bin/systemctl try-restart
kdump-tools.service"
SUBSYSTEM=="memory", ACTION=="offline", PROGRAM="/bin/systemctl try-restart
--- Comment From hbath...@in.ibm.com 2018-08-11 08:48 EDT---
After upgrading to kdump-tools_1.6.4-1~16.04.0cascardo2_ppc64el.deb package,
dump capture succeeds without any complaints:
The udev rules trigger kdump-tools service reload as can be seen below:
--
root@ubuntu:~# dpkg -l | grep
--- Comment From hbath...@in.ibm.com 2018-03-22 13:18 EDT---
(In reply to comment #32)
> (In reply to comment #31)
> > Could you please comment as to whether the workaround resolved the issue?
>
> Yes, the workaround resolves the issue. But could we have a udev rule added
> in kdump-tools
--- Comment From hbath...@in.ibm.com 2018-03-21 09:04 EDT---
(In reply to comment #31)
> Could you please comment as to whether the workaround resolved the issue?
Yes, the workaround resolves the issue. But could we have a udev rule added in
kdump-tools
to trigger kdump-tools.service
--- Comment From hbath...@in.ibm.com 2018-03-08 14:01 EDT---
(In reply to comment #29)
> So, the workaround would be reloading the dump after DLPAR. In order to do
> that, run:
>
> kdump-config unload ; kdump-config load
>
The "console log" attachment is basically the error seen when the
--- Comment From hbath...@in.ibm.com 2017-08-31 04:54 EDT---
(In reply to comment #22)
> Hi, Hari.
Hello Cascardo,
>
> My understanding is that the kernel should handle that. Otherwise, whenever
Sadly, it can't as kexec-tools is the one that creates elf headers for
/proc/vmcore.
So,
--- Comment From hbath...@in.ibm.com 2017-08-22 10:32 EDT---
(In reply to comment #20)
> Hi, hbathini.
>
Hello Cascardo,
> Why is it needed to restart kdump-tools after a DLPAR? Does it refer
to a
Yes. It refers to either of memory or CPU hot add/remove operations, when
kdump kernel
--- Comment From pavra...@in.ibm.com 2017-07-14 05:02 EDT---
Issue is observed even on 16.04.03. When crash is triggered after memory remove
operation.
Thanks,
Pavithra
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--- Comment From hbath...@in.ibm.com 2017-01-23 01:45 EDT---
Hi Canonical,
After a DLPAR operation, kdump-tools.service must be restarted for kdump/fadump
to work properly..
Thanks
Hari
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
--- Comment From pt...@cn.ibm.com 2017-01-10 20:20 EDT---
(In reply to comment #7)
> Assigning to Hari for some assistance but would like to know if this issue
> can be recreated consistently and if so how and does this occur on other
> LPARs running the same level?
Looks like this bug
14 matches
Mail list logo
