# /sbin/kexec -p '--command-line=ro root=/dev/mapper/VolGroup-lv_root
rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD
rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us
rhgb quiet console=tty0 console=ttyS0,115200 crashkernel=128M irqpoll ma
On 09/25/2010 08:11 PM, caiq...@redhat.com wrote:
> # /sbin/kexec -p '--command-line=ro root=/dev/mapper/VolGroup-lv_root
> rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
> KEYTABLE=us rhgb quiet con
- "Yinghai Lu" wrote:
> On 09/25/2010 08:11 PM, caiq...@redhat.com wrote:
> > # /sbin/kexec -p '--command-line=ro
> root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root
> rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM
> LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE
On 09/25/2010 11:55 PM, CAI Qian wrote:
>>
>> are you kexec from 2.6.35+ to 2.6.36-rc3+?
> No, both kernels were the same version. I am sorry the above logs were
> misleading that were copy-and-pasted from different kernel versions.
can you check tip instead of next tree?
Yinghai
__
- "Yinghai Lu" wrote:
> On 09/25/2010 11:55 PM, CAI Qian wrote:
> >>
> >> are you kexec from 2.6.35+ to 2.6.36-rc3+?
> > No, both kernels were the same version. I am sorry the above logs
> were misleading that were copy-and-pasted from different kernel
> versions.
>
> can you check tip inst
- "Yinghai Lu" wrote:
> On 09/25/2010 11:55 PM, CAI Qian wrote:
> >>
> >> are you kexec from 2.6.35+ to 2.6.36-rc3+?
> > No, both kernels were the same version. I am sorry the above logs
> were misleading that were copy-and-pasted from different kernel
> versions.
>
> can you check tip inst
On 09/26/2010 07:47 AM, caiq...@redhat.com wrote:
>
> - "Yinghai Lu" wrote:
>
>> On 09/25/2010 11:55 PM, CAI Qian wrote:
are you kexec from 2.6.35+ to 2.6.36-rc3+?
>>> No, both kernels were the same version. I am sorry the above logs
>> were misleading that were copy-and-pasted fro
- "Yinghai Lu" wrote:
> On 09/26/2010 07:47 AM, caiq...@redhat.com wrote:
> >
> > - "Yinghai Lu" wrote:
> >
> >> On 09/25/2010 11:55 PM, CAI Qian wrote:
>
> are you kexec from 2.6.35+ to 2.6.36-rc3+?
> >>> No, both kernels were the same version. I am sorry the above logs
> >
Please check this one on top of tip or next.
Thanks
Yinghai
[PATCH] x86, memblock: Fix crashkernel allocation
Cai Qian found that crashkernel is broken with x86 memblock changes
1. crashkernel=1...@32m always reported that range is used, even first kernel
is small
no one use that range
2. a
Please check this one on top of tip or next.
Thanks
Yinghai
[PATCH] x86, memblock: Fix crashkernel allocation
Cai Qian found that crashkernel is broken with x86 memblock changes
1. crashkernel=1...@32m always reported that range is used, even first kernel
is small
no one use that range
2. a
- "Yinghai Lu" wrote:
> Please check this one on top of tip or next.
This failed for both trees.
[r...@localhost linux-next]# patch -Np1
> Thanks
>
> Yinghai
>
> [PATCH] x86, memblock: Fix crashkernel allocation
>
> Cai Qian found that crashkernel is broken with x86 memblock changes
> 1
- "CAI Qian" wrote:
> - "Yinghai Lu" wrote:
>
> > Please check this one on top of tip or next.
> This failed for both trees.
> [r...@localhost linux-next]# patch -Np1 patching file arch/x86/kernel/setup.c
> Hunk #1 FAILED at 516.
> 1 out of 1 hunk FAILED -- saving rejects to file
> ar
+ crash_base = alignment;
+ while ((crash_base + crash_size) <= total_mem) {
+ start = memblock_find_in_range(crash_base,
+ crash_base + crash_size, crash_size, alignment);
+
+ if (start == crash_b
On 09/27/2010 03:50 PM, H. Peter Anvin wrote:
> + crash_base = alignment;
> + while ((crash_base + crash_size) <= total_mem) {
> + start = memblock_find_in_range(crash_base,
> + crash_base + crash_size, crash_size, alignment);
On 09/27/2010 04:20 PM, Yinghai Lu wrote:
>
> x86 own version for find_area?
>
No, double no.
Same kind of crap: overloading an interface with semantics it shouldn't
have. The right thing is to introduce a new interface with carries the
explicitly needed policy with it... e.g. memblock_find_in
On 09/27/2010 04:26 PM, H. Peter Anvin wrote:
> On 09/27/2010 04:20 PM, Yinghai Lu wrote:
>>
>> x86 own version for find_area?
>>
>
> No, double no.
>
> Same kind of crap: overloading an interface with semantics it shouldn't
> have. The right thing is to introduce a new interface with carries th
On 09/27/2010 04:32 PM, Yinghai Lu wrote:
> On 09/27/2010 04:26 PM, H. Peter Anvin wrote:
>> On 09/27/2010 04:20 PM, Yinghai Lu wrote:
>>>
>>> x86 own version for find_area?
>>>
>>
>> No, double no.
>>
>> Same kind of crap: overloading an interface with semantics it shouldn't
>> have. The right th
On 09/27/2010 04:34 PM, H. Peter Anvin wrote:
> On 09/27/2010 04:32 PM, Yinghai Lu wrote:
>> On 09/27/2010 04:26 PM, H. Peter Anvin wrote:
>>> On 09/27/2010 04:20 PM, Yinghai Lu wrote:
x86 own version for find_area?
>>>
>>> No, double no.
>>>
>>> Same kind of crap: overloading an int
On Mon, Sep 27, 2010 at 04:41:31PM -0700, Yinghai Lu wrote:
> On 09/27/2010 04:34 PM, H. Peter Anvin wrote:
> > On 09/27/2010 04:32 PM, Yinghai Lu wrote:
> >> On 09/27/2010 04:26 PM, H. Peter Anvin wrote:
> >>> On 09/27/2010 04:20 PM, Yinghai Lu wrote:
>
> x86 own version for find_area?
>
On 09/27/2010 04:21 AM, caiq...@redhat.com wrote:
>
> - "CAI Qian" wrote:
>
>> - "Yinghai Lu" wrote:
>>
>>> Please check this one on top of tip or next.
>> This failed for both trees.
>> [r...@localhost linux-next]# patch -Np1 > patching file arch/x86/kernel/setup.c
>> Hunk #1 FAILED at
On 09/27/2010 05:53 PM, Vivek Goyal wrote:
> Actually, hardcoding the upper limit to 4G is probably not the best idea.
> Kexec loads the the relocatable binary (purgatory) and I remember that
> one of the generated relocation type was signed 32 bit and allowed max value
> to be 2G only. So IIRC, pu
On 09/27/2010 05:53 PM, Vivek Goyal wrote:
>
> Actually, hardcoding the upper limit to 4G is probably not the best idea.
> Kexec loads the the relocatable binary (purgatory) and I remember that
> one of the generated relocation type was signed 32 bit and allowed max value
> to be 2G only. So IIRC,
On 09/27/2010 08:46 PM, H. Peter Anvin wrote:
> On 09/27/2010 05:53 PM, Vivek Goyal wrote:
>>
>> Actually, hardcoding the upper limit to 4G is probably not the best idea.
>> Kexec loads the the relocatable binary (purgatory) and I remember that
>> one of the generated relocation type was signed 32
On Mon, Sep 27, 2010 at 08:46:42PM -0700, H. Peter Anvin wrote:
> On 09/27/2010 05:53 PM, Vivek Goyal wrote:
> >
> > Actually, hardcoding the upper limit to 4G is probably not the best idea.
> > Kexec loads the the relocatable binary (purgatory) and I remember that
> > one of the generated relocat
On Tue, Sep 28, 2010 at 12:14:31AM -0700, Yinghai Lu wrote:
> On 09/27/2010 08:46 PM, H. Peter Anvin wrote:
> > On 09/27/2010 05:53 PM, Vivek Goyal wrote:
> >>
> >> Actually, hardcoding the upper limit to 4G is probably not the best idea.
> >> Kexec loads the the relocatable binary (purgatory) and
25 matches
Mail list logo
