On 07/30/14 12:58, Borislav Petkov wrote:
> On Wed, Jul 30, 2014 at 10:21:26AM -0700, H. Peter Anvin wrote:
>> Arguably the exactness is available in the range...
>
> ... and the size too. FWIW, other region dumps don't even print size:
>
> [0.00] e820: BIOS-provided physical RAM map:
> [
On Wed, Jul 30, 2014 at 10:21:26AM -0700, H. Peter Anvin wrote:
> Arguably the exactness is available in the range...
... and the size too. FWIW, other region dumps don't even print size:
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x
On 07/30/2014 10:10 AM, Randy Dunlap wrote:
>>
>> My issue is simply that I'd like to know *exactly* how big each range is and
>> not
>> have it rounded off. Others think that it is easier to read Mib & Gib ...
>
> It is easier to read in MiB or GiB IMHO, but since it is debug info,
> exact is g
On 07/30/14 10:04, Prarit Bhargava wrote:
>
>
> On 07/30/2014 11:05 AM, Colin Ian King wrote:
>> On 30/07/14 15:48, Matt Fleming wrote:
>>> On Wed, 30 Jul, at 12:29:32AM, Borislav Petkov wrote:
On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
> The current debug print in
On 07/30/2014 11:05 AM, Colin Ian King wrote:
> On 30/07/14 15:48, Matt Fleming wrote:
>> On Wed, 30 Jul, at 12:29:32AM, Borislav Petkov wrote:
>>> On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
The current debug print in EFI does
[0.00] efi: mem84: type=3
On 30/07/14 15:48, Matt Fleming wrote:
> On Wed, 30 Jul, at 12:29:32AM, Borislav Petkov wrote:
>> On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
>>> The current debug print in EFI does
>>>
>>> [0.00] efi: mem84: type=3, attr=0xf,
>>> range=[0x645b5000-0x64
On Wed, 30 Jul, at 12:29:32AM, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
> > The current debug print in EFI does
> >
> > [0.00] efi: mem84: type=3, attr=0xf,
> > range=[0x645b5000-0x645fb000) (0MB)
> >
> > and rounds off the
On Tue, Jul 29, 2014 at 3:54 PM, Prarit Bhargava wrote:
>
>
> On 07/29/2014 06:36 PM, Borislav Petkov wrote:
>> On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
>>> and it was best to keep the code simple with a KiB.
>>
>> You're missing the point - the output doesn't get simple wi
On Tue, 29 Jul 2014, Joe Perches wrote:
> Maybe yet another vsprintf extension?
>
> Maybe %pH where vartype is one of [hh, h, u, ul, ull]
> with something like
> u64 t1 = (u64)*(appropriate cast)vartype;
> u64 t2 = t1;
> int index = 0;
> while ((t1 >>= 10)) {
>
On Tue, 2014-07-29 at 15:42 -0700, David Rientjes wrote:
> On Wed, 30 Jul 2014, Borislav Petkov wrote:
>
> > On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
> > > and it was best to keep the code simple with a KiB.
> >
> > You're missing the point - the output doesn't get simple
On 07/29/2014 07:01 PM, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 03:42:55PM -0700, David Rientjes wrote:
>> If Prarit is going to implement this suggested reverse memparse() ...
>
> The only meaningful argument about the formatting here IMO is what
> people staring at this output are goi
On Tue, Jul 29, 2014 at 03:42:55PM -0700, David Rientjes wrote:
> If Prarit is going to implement this suggested reverse memparse() ...
The only meaningful argument about the formatting here IMO is what
people staring at this output are going to understand from it.
And since those people most oft
On 07/29/2014 06:36 PM, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
>> and it was best to keep the code simple with a KiB.
>
> You're missing the point - the output doesn't get simple with KiB. Read
> the example I just gave you!
>
> (13893632kiB) i
On Wed, 30 Jul 2014, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
> > and it was best to keep the code simple with a KiB.
>
> You're missing the point - the output doesn't get simple with KiB. Read
> the example I just gave you!
>
> (13893632kiB) is a
On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
> and it was best to keep the code simple with a KiB.
You're missing the point - the output doesn't get simple with KiB. Read
the example I just gave you!
(13893632kiB) is actively *not* helping when one looks at it!
--
Regards/Gr
On 07/29/2014 06:29 PM, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
>> The current debug print in EFI does
>>
>> [0.00] efi: mem84: type=3, attr=0xf,
>> range=[0x645b5000-0x645fb000) (0MB)
>>
>> and rounds off the size to 0MB
On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
> The current debug print in EFI does
>
> [0.00] efi: mem84: type=3, attr=0xf,
> range=[0x645b5000-0x645fb000) (0MB)
>
> and rounds off the size to 0MB and isn't very useful. We should print this in
> Kib.
On 07/29/2014 06:02 PM, Joe Perches wrote:
> On Tue, 2014-07-29 at 13:29 -0700, David Rientjes wrote:
>> On Tue, 29 Jul 2014, Prarit Bhargava wrote:
>>> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> []
>>> @@ -384,10 +384,10 @@ static void __init print_efi_memmap(void)
On 07/29/2014 04:29 PM, David Rientjes wrote:
> On Tue, 29 Jul 2014, Prarit Bhargava wrote:
>
>> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
>> index 87fc96b..3875090 100644
>> --- a/arch/x86/platform/efi/efi.c
>> +++ b/arch/x86/platform/efi/efi.c
>> @@ -384,10 +384,10
On Tue, 2014-07-29 at 13:29 -0700, David Rientjes wrote:
> On Tue, 29 Jul 2014, Prarit Bhargava wrote:
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
[]
> > @@ -384,10 +384,10 @@ static void __init print_efi_memmap(void)
> > p < memmap.map_end;
> > p +=
On Tue, 29 Jul 2014, Prarit Bhargava wrote:
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 87fc96b..3875090 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -384,10 +384,10 @@ static void __init print_efi_memmap(void)
>
The current debug print in EFI does
[0.00] efi: mem84: type=3, attr=0xf,
range=[0x645b5000-0x645fb000) (0MB)
and rounds off the size to 0MB and isn't very useful. We should print this in
Kib. After applying this patch we get better info with
[0.00] efi: mem84:
22 matches
Mail list logo
