On Wed, Nov 13, 2019 at 07:36:01PM +, Kazuhito Hagio wrote:
> I think I've fixed the ELF issues which I could reproduce:
> - wrong statistics
> - e_phnum overflow
>
> If you still see any problems with the latest makedumpfile,
> please let me know.
>
> Thanks,
> Kazu
It's taken me
On Thu, Oct 17, 2019 at 08:55:54PM +, Kazuhito Hagio wrote:
> > I'll rework things so that it redirects to a file instead of dmesg, but
> > it's going to take me a while to get that deployed and tested.
>
> If your hosts have a big space enough, thare is another way that
> you use cp for
On Wed, Oct 09, 2019 at 08:03:51PM +, Kazuhito Hagio wrote:
> In this case, was the "makedumpfile Completed." message emitted?
> It looks like the buffer of program headers was not written to the file..
>
> Anyway, a debugging patch attached below.
Our kdump tooling redirects makedumpfil
On Wed, Oct 09, 2019 at 08:03:51PM +, Kazuhito Hagio wrote:
> > 0x 0x 0
> > NULL 0x 0x 0x
> > 0x 0x 0
> >
>
> In
On Mon, Oct 07, 2019 at 08:13:07PM +, Kazuhito Hagio wrote:
> > [ 518.819690] Original pages : 0x
> > [ 518.828894] Excluded pages : 0x03decd15
> > [ 518.838635] Pages filled with zero : 0x000210ee
> > [ 518.849920] Non-private cache pages
On Thu, Sep 26, 2019 at 06:41:48PM +, Kazuhito Hagio wrote:
> > -Original Message-
> > If info->max_mapnr and pfn_memhole are equal, we divide by zero when
> > trying determine the 'shrinking' value.
> >
> > On the system I saw this error, we arrived at this function with
> > in
On Wed, Jan 26, 2011 at 03:07:44PM -0800, Luck, Tony wrote:
> >- The latest approach (proposed by Linus) is to forget the disk: jump to
> > real-mode, but display the kernel log in a fancy format (with scroll
> > ups and downs) instead.
>
> A while ago (first Plumbers conference?) someone w
