On Fri, 19 Jan 2018 08:16:04 -0800
Andi Kleen wrote:
> On Fri, Jan 19, 2018 at 02:45:38PM +0900, Sergey Senozhatsky wrote:
> > On (01/18/18 10:02), Andi Kleen wrote:
> > > Dave Young writes:
> > > > printk("%sHardware name: %s\n",
> > > >log_lvl, dump_
On Fri, Jan 19, 2018 at 02:45:38PM +0900, Sergey Senozhatsky wrote:
> On (01/18/18 10:02), Andi Kleen wrote:
> > Dave Young writes:
> > > printk("%sHardware name: %s\n",
> > > log_lvl, dump_stack_arch_desc_str);
> > > + if (kexec_crash_loaded())
> > > + printk("%
On Fri, 19 Jan 2018 12:47:19 +0800
Dave Young wrote:
> On 01/18/18 at 01:57pm, Steven Rostedt wrote:
> > On Thu, 18 Jan 2018 10:02:17 -0800
> > Andi Kleen wrote:
> >
> > > Dave Young writes:
> > > > printk("%sHardware name: %s\n",
> > > >log_lvl, dum
Hello,
On 16/01/18 07:07, takahiro.aka...@linaro.org wrote:
> On Mon, Jan 15, 2018 at 10:14:05AM +0530, Bhupesh SHARMA wrote:
>> On Sat, Jan 13, 2018 at 8:37 AM, Poonam Aggrwal
>> wrote:
On 08/01/18 04:31, Poonam Aggrwal wrote:
> Yeah, this is a good point. So ideally the address of the
The crashed reserved memory end offset is the last address within
range, whereas the end offset in the pt_loads[] denotes the first
address past the range. This has caused a number of off-by-one
errors in exclude_segment().
First, let's unify the meaning of "end" to be the first out-of-range
addre
I have observed that makedumpfile --mem-usage shows bogus numbers
on a kaslr-enabled kernel. This boils down to incorrect calculations
in exclude_segment(). Consequently, data beyond a split LOAD segment
are read from the wrong file offset.
Petr Tesarik (2):
Fix off-by-one errors in exclude_segm
With kaslr enabled, PAGE_OFFSET may no longer be aligned to allow
calculation using bitwise OR. My fix follows the same idea as
Baoquan's commit 4c53423b995463067fbbd394e724b4d1d6ea3d62 for
set_kcore_vmcoreinfo, i.e. use arithmetic addition instead.
Signed-off-by: Petr Tesarik
---
elf_info.c | 4
Hi Akashi,
On 11/01/18 11:38, AKASHI Takahiro wrote:
> On Wed, Jan 10, 2018 at 11:26:55AM +, James Morse wrote:
>> On 10/01/18 10:09, AKASHI Takahiro wrote:
>>> This is a fix against the issue that crash dump kernel may hang up
>>> during booting, which can happen on any ACPI-based system with
On (01/19/18 16:42), Dave Young wrote:
[..]
> > [I'm not entirely sure I see why do we have printk_delay() in
> >vprintk_emit()... I mean I probably can see some reasoning behind
> >it, but at the same it makes sense to slow down console_unlock()
> >as well]
>
> Looks like I am the guy
On 01/19/18 at 05:28pm, Sergey Senozhatsky wrote:
> On (01/19/18 16:16), Dave Young wrote:
> > On 01/19/18 at 02:45pm, Sergey Senozhatsky wrote:
> > > On (01/18/18 10:02), Andi Kleen wrote:
> > > > Dave Young writes:
> > > > > printk("%sHardware name: %s\n",
> > > > >
On (01/19/18 16:16), Dave Young wrote:
> I thought about adding an option to improve printk_delay so it can
> delay every n lines, eg. 25 rows. Maybe that idea works for this
> issue?
/* sent the message too soon */
printk_delay() has no effect there. it limits only printk()->vprintk_emit()
and w
On (01/19/18 16:16), Dave Young wrote:
> On 01/19/18 at 02:45pm, Sergey Senozhatsky wrote:
> > On (01/18/18 10:02), Andi Kleen wrote:
> > > Dave Young writes:
> > > > printk("%sHardware name: %s\n",
> > > >log_lvl, dump_stack_arch_desc_str);
> > > > +
On 01/19/18 at 02:45pm, Sergey Senozhatsky wrote:
> On (01/18/18 10:02), Andi Kleen wrote:
> > Dave Young writes:
> > > printk("%sHardware name: %s\n",
> > > log_lvl, dump_stack_arch_desc_str);
> > > + if (kexec_crash_loaded())
> > > + printk("%skdump kernel load
13 matches
Mail list logo
