(2013/11/25 23:41), Vivek Goyal wrote:
On Mon, Nov 25, 2013 at 06:01:37PM +0900, HATAYAMA Daisuke wrote:
[..]
I agree to avoid this issue by fixing makedumpfile as workaround while to
fix kernel is so tough and risky. However, it sounds strange to me to fix
userspace side elaborately for such d
On 11/25/13 at 08:09am, Atsushi Kumagai wrote:
> Hello WANG,
>
> On 2013/11/21 16:15:22, kexec wrote:
> > > How about this fail back structure instead of such an extra option ?
> > >
> > > Thanks
> > > Atsushi Kumagai
> > >
> > > From: Atsushi Kumagai
> > > Date: Wed, 20 Nov 2013 14:10:19 +090
On 2013/11/20 15:44:45, kexec wrote:
> (2013/11/20 14:27), Atsushi Kumagai wrote:
> > On 2013/11/19 18:56:21, kexec wrote:
> >> (2013/11/18 9:51), Atsushi Kumagai wrote:
> >>> (2013/11/15 23:26), Vivek Goyal wrote:
> On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote:
>
>
On 2013/11/25 23:42:31, kexec wrote:
> On Mon, Nov 25, 2013 at 06:01:37PM +0900, HATAYAMA Daisuke wrote:
>
> [..]
> > > I agree to avoid this issue by fixing makedumpfile as workaround while to
> > > fix kernel is so tough and risky. However, it sounds strange to me to fix
> > > userspace side el
On Mon, Nov 25, 2013 at 06:01:37PM +0900, HATAYAMA Daisuke wrote:
[..]
> > I agree to avoid this issue by fixing makedumpfile as workaround while to
> > fix kernel is so tough and risky. However, it sounds strange to me to fix
> > userspace side elaborately for such definite kernel issue whose cau
(2013/11/25 17:10), Atsushi Kumagai wrote:
> On 2013/11/22 1:53:14, kexec wrote:
>> On Thu, Nov 21, 2013 at 05:31:46PM +0900, HATAYAMA Daisuke wrote:
>>
>> [..]
So I think the patch I sent is enough, the policy will be simpler as
"Don't use mmap() for buggy kernels".
[PATCH] Fa
On 2013/11/22 1:53:14, kexec wrote:
> On Thu, Nov 21, 2013 at 05:31:46PM +0900, HATAYAMA Daisuke wrote:
>
> [..]
> > > So I think the patch I sent is enough, the policy will be simpler as
> > > "Don't use mmap() for buggy kernels".
> > >
> > > [PATCH] Fall back to read() when mmap() fails.
> > >
Hello WANG,
On 2013/11/21 16:15:22, kexec wrote:
> > How about this fail back structure instead of such an extra option ?
> >
> > Thanks
> > Atsushi Kumagai
> >
> > From: Atsushi Kumagai
> > Date: Wed, 20 Nov 2013 14:10:19 +0900
> > Subject: [PATCH] Fall back to read() when mmap() fails.
> >
On 11/20/13 at 05:27am, Atsushi Kumagai wrote:
> On 2013/11/19 18:56:21, kexec wrote:
> > (2013/11/18 9:51), Atsushi Kumagai wrote:
> > > (2013/11/15 23:26), Vivek Goyal wrote:
> > >> On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote:
> > >>
> > >> [..]
> > Given the fact that
On Wed, Nov 20, 2013 at 05:29:16AM +, Atsushi Kumagai wrote:
> On 2013/11/18 22:56:10, kexec wrote:
> > On Mon, Nov 18, 2013 at 12:51:39AM +, Atsushi Kumagai wrote:
> >
> > [..]
> > > > Is there any chance that you could look into fixing this. I have no
> > > > experience writing code fo
(2013/11/20 14:27), Atsushi Kumagai wrote:
> On 2013/11/19 18:56:21, kexec wrote:
>> (2013/11/18 9:51), Atsushi Kumagai wrote:
>>> (2013/11/15 23:26), Vivek Goyal wrote:
On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote:
[..]
>> Given the fact that hpa does not li
On 2013/11/18 22:56:10, kexec wrote:
> On Mon, Nov 18, 2013 at 12:51:39AM +, Atsushi Kumagai wrote:
>
> [..]
> > > Is there any chance that you could look into fixing this. I have no
> > > experience writing code for makedumpfile.
> >
> > I'll send a patch to fix this soon.
>
> Thanks Atsu
On 2013/11/19 18:56:21, kexec wrote:
> (2013/11/18 9:51), Atsushi Kumagai wrote:
> > (2013/11/15 23:26), Vivek Goyal wrote:
> >> On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote:
> >>
> >> [..]
> Given the fact that hpa does not like fixing it in kernel. We are
> left wi
(2013/11/18 9:51), Atsushi Kumagai wrote:
> (2013/11/15 23:26), Vivek Goyal wrote:
>> On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote:
>>
>> [..]
Given the fact that hpa does not like fixing it in kernel. We are left
with option of fixing it in following places.
On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote:
[..]
> >Given the fact that hpa does not like fixing it in kernel. We are left
> >with option of fixing it in following places.
> >
> >- Drop partial pages in kexec-tools
> >- Drop partial pages in makeudmpfile.
> >- Read partial pa
(2013/11/15 0:13), Vivek Goyal wrote:
On Thu, Nov 14, 2013 at 07:31:37PM +0900, HATAYAMA Daisuke wrote:
[..]
BTW, I previously found a part of makedumpfile that truncates the first and
last pages if they are not aligned in page size. Discussing with Kumagai-san,
the truncation is performed on s
On Thu, Nov 14, 2013 at 07:31:37PM +0900, HATAYAMA Daisuke wrote:
[..]
> BTW, I previously found a part of makedumpfile that truncates the first and
> last pages if they are not aligned in page size. Discussing with Kumagai-san,
> the truncation is performed on some ia64 system and he found a vali
(2013/11/14 5:41), Vivek Goyal wrote:
Hi Hatayama,
We are facing some /proc/vmcore mmap() failure issues and then makdumpfile
exits without saving dump and system reboots.
I tried latest makedumpfile (devel branch) with 3.12 kernel.
I think this issue happens only on some machines. And it look
On 11/13/2013 03:00 PM, Vivek Goyal wrote:
> I think it should be easy to truncate ELF headers in kexec-tools too when
> we are preparing elf headers. I am not sure if it is right thing to do or
> not. If some entry is showing up in /proc/iomem as RAM, then kexec-tools
> need to believe that it is
On Wed, Nov 13, 2013 at 02:44:45PM -0800, H. Peter Anvin wrote:
> On 11/13/2013 02:41 PM, Vivek Goyal wrote:
> >
> > Hi Peter,
> >
> > I noticed we seem to be trimming away partial pages in memblock.
> >
> > memblock_x86_fill() {
> > /* throw away partial pages */
> > memblock_trim_m
On 11/13/2013 02:41 PM, Vivek Goyal wrote:
>
> Hi Peter,
>
> I noticed we seem to be trimming away partial pages in memblock.
>
> memblock_x86_fill() {
> /* throw away partial pages */
> memblock_trim_memory(PAGE_SIZE);
> }
>
> But not in e820 hence they show up in /proc/iomem.
>
On Wed, Nov 13, 2013 at 01:14:53PM -0800, H. Peter Anvin wrote:
> On 11/13/2013 01:04 PM, Vivek Goyal wrote:
> > [CC hpa ]
> >
> > And this issue brings me to the question that why do we allow sytem RAM
> > ranges which do not start on page boundary or do not end on page boundary.
> > Can't we tr
On 11/13/2013 01:04 PM, Vivek Goyal wrote:
> [CC hpa ]
>
> And this issue brings me to the question that why do we allow sytem RAM
> ranges which do not start on page boundary or do not end on page boundary.
> Can't we truncate the BIOS reported RAM ranges in such a way so that
> they start and e
[CC hpa ]
And this issue brings me to the question that why do we allow sytem RAM
ranges which do not start on page boundary or do not end on page boundary.
Can't we truncate the BIOS reported RAM ranges in such a way so that
they start and end at PAGE boundary and rest of the kernel will never s
Hi Hatayama,
We are facing some /proc/vmcore mmap() failure issues and then makdumpfile
exits without saving dump and system reboots.
I tried latest makedumpfile (devel branch) with 3.12 kernel.
I think this issue happens only on some machines. And it looks like it
happens when end of system RAM
25 matches
Mail list logo
