On Wed, May 29, 2024 at 06:51:19PM +0900, Jaewon Kim wrote:
><!DOCTYPE html>
><html>
><head>
..
Would you mind sending it in pure text again?
--
Wei Yang
Help you, Help me
(Sorry I might forget to change to be plain text)
Oh good thing, I did not know this patch. Thanks.
By the way, I've tried to get memblock/memory and kernel log from a
device based on
v6.6.17 kernel device, to see upstream patches above.
memblok/memory does not show region for
0x00000000_80000000..0x0x00000000_8195ffff.
0: 0x0000000081960000..0x00000000819fffff 0 NONE
The kernel log shows information for 0x0000000080000000..0x00000000813fffff, but
we don't see information for 0x0000000081400000..0x000000008195ffff
from kernel log.
(I removed the name.)
<6>[ 0.000000][ T0] OF: reserved mem:
0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable
AAA
<6>[ 0.000000][ T0] OF: reserved mem:
0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable
BBB
<6>[ 0.000000][ T0] OF: reserved mem:
0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable
CCC
<6>[ 0.000000][ T0] OF: reserved mem:
0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DD
A smart parser should gather these kernel log and memblock/memory log
and should show
log like my memsize logic shows below.
0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap
unusable unknown
Thank you
Jaewon
On Wed, May 29, 2024 at 8:35 PM Wei Yang <[email protected]> wrote:
>
> On Wed, May 29, 2024 at 06:51:19PM +0900, Jaewon Kim wrote:
> ><!DOCTYPE html>
> ><html>
> ><head>
> ...
>
> Would you mind sending it in pure text again?
>
> --
> Wei Yang
> Help you, Help me
On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote:
>(Sorry I might forget to change to be plain text)
>
>Oh good thing, I did not know this patch. Thanks.
>
>By the way, I've tried to get memblock/memory and kernel log from a
>device based on
>v6.6.17 kernel device, to see upstream patches above.
>memblok/memory does not show region for
memblock/memory only shows ranges put in "memory".
memblock/reserved shows ranges put in "reserved".
If we just put them in "reserved", it will not displayed in "memory".
>0x00000000_80000000..0x0x00000000_8195ffff.
>
> 0: 0x0000000081960000..0x00000000819fffff 0 NONE
>
>The kernel log shows information for 0x0000000080000000..0x00000000813fffff, but
>we don't see information for 0x0000000081400000..0x000000008195ffff
>from kernel log.
>
>(I removed the name.)
><6>[ 0.000000][ T0] OF: reserved mem:
>0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable
>AAA
><6>[ 0.000000][ T0] OF: reserved mem:
>0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable
>BBB
><6>[ 0.000000][ T0] OF: reserved mem:
>0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable
>CCC
><6>[ 0.000000][ T0] OF: reserved mem:
>0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DD
>
I guess those ranges are only put into "reserved"? Have those ranges put in
"memory"? Would you mind point the code where those messages are printed?
>A smart parser should gather these kernel log and memblock/memory log
>and should show
>log like my memsize logic shows below.
>0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap
>unusable unknown
>
>Thank you
>Jaewon
>
>On Wed, May 29, 2024 at 8:35 PM Wei Yang <[email protected]> wrote:
>>
>> On Wed, May 29, 2024 at 06:51:19PM +0900, Jaewon Kim wrote:
>> ><!DOCTYPE html>
>> ><html>
>> ><head>
>> ...
>>
>> Would you mind sending it in pure text again?
>>
>> --
>> Wei Yang
>> Help you, Help me
--
Wei Yang
Help you, Help me
>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote:
>>(Sorry I might forget to change to be plain text)
>>
>>Oh good thing, I did not know this patch. Thanks.
>>
>>By the way, I've tried to get memblock/memory and kernel log from a
>>device based on
>>v6.6.17 kernel device, to see upstream patches above.
>>memblok/memory does not show region for
>
>memblock/memory only shows ranges put in "memory".
>memblock/reserved shows ranges put in "reserved".
>
>If we just put them in "reserved", it will not displayed in "memory".
>
Hi
Let me explain more.
In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is.
# xxd -g 8 /proc/device-tree/memory/reg
00000000: 0000000081960000 00000000000a0000 ................
00000010: 0000000081a40000 00000000001c0000 ................
# cat sys/kernel/debug/memblock/memory
0: 0x0000000081960000..0x00000000819fffff 0 NONE
1: 0x0000000081a40000..0x0000000081bfffff 0 NONE
# cat sys/kernel/debug/memblock/reserved
0: 0x0000000082800000..0x00000000847fffff 0 NONE
The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map.
(I removed the name.)
<6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable AAA
<6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable BBB
<6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable CCC
<6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DDD
So a smart parser should combine the krenel log and the memblock/memory log.
In my memsize feature shows it like this though.
0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown
BR
>>0x00000000_80000000..0x0x00000000_8195ffff.
>>
>> 0: 0x0000000081960000..0x00000000819fffff 0 NONE
>>
>>The kernel log shows information for 0x0000000080000000..0x00000000813fffff, but
>>we don't see information for 0x0000000081400000..0x000000008195ffff
>>from kernel log.
>>
>>(I removed the name.)
>><6>[ 0.000000][ T0] OF: reserved mem:
>>0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable
>>AAA
>><6>[ 0.000000][ T0] OF: reserved mem:
>>0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable
>>BBB
>><6>[ 0.000000][ T0] OF: reserved mem:
>>0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable
>>CCC
>><6>[ 0.000000][ T0] OF: reserved mem:
>>0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DD
>>
>
>I guess those ranges are only put into "reserved"? Have those ranges put in
>"memory"? Would you mind point the code where those messages are printed?
>
>>A smart parser should gather these kernel log and memblock/memory log
>>and should show
>>log like my memsize logic shows below.
>>0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap
>>unusable unknown
>>
>>Thank you
>>Jaewon
>>
>>On Wed, May 29, 2024 at 8:35?PM Wei Yang <[email protected]> wrote:
>>>
>>> On Wed, May 29, 2024 at 06:51:19PM +0900, Jaewon Kim wrote:
>>> ><!DOCTYPE html>
>>> ><html>
>>> ><head>
>>> ...
>>>
>>> Would you mind sending it in pure text again?
>>>
>>> --
>>> Wei Yang
>>> Help you, Help me
>
>--
>Wei Yang
>Help you, Help me
On Thu, May 30, 2024 at 07:49:28PM +0900, Jaewon Kim wrote:
>>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote:
>>>(Sorry I might forget to change to be plain text)
>>>
>>>Oh good thing, I did not know this patch. Thanks.
>>>
>>>By the way, I've tried to get memblock/memory and kernel log from a
>>>device based on
>>>v6.6.17 kernel device, to see upstream patches above.
>>>memblok/memory does not show region for
>>
>>memblock/memory only shows ranges put in "memory".
>>memblock/reserved shows ranges put in "reserved".
>>
>>If we just put them in "reserved", it will not displayed in "memory".
>
>Hi
>Let me explain more.
>
>In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is.
>
># xxd -g 8 /proc/device-tree/memory/reg
>00000000: 0000000081960000 00000000000a0000 ................
>00000010: 0000000081a40000 00000000001c0000 ................
>
># cat sys/kernel/debug/memblock/memory
> 0: 0x0000000081960000..0x00000000819fffff 0 NONE
> 1: 0x0000000081a40000..0x0000000081bfffff 0 NONE
>
># cat sys/kernel/debug/memblock/reserved
> 0: 0x0000000082800000..0x00000000847fffff 0 NONE
>
>The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map.
>
>(I removed the name.)
><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable AAA
><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable BBB
><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable CCC
><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DDD
>
This looks not printed by memblock_reserve(), right? It is printed by your own
driver?
>So a smart parser should combine the krenel log and the memblock/memory log.
>
>In my memsize feature shows it like this though.
>
>0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown
>
>BR
>
I am sorry, I still not catch your point. Let me try to understand your message.
You mentioned several regions, let me put them in order.
(1) 0x0000000080000000..0x0000000080dfffff printed by driver
(2) 0x0000000080e00000..0x00000000811fffff printed by driver
(3) 0x0000000081200000..0x00000000813fffff printed by driver
(4) 0x0000000081400000..0x0000000081960000 expected to print in new debugfs
(5) 0x0000000081960000..0x00000000819fffff listed in reg/memory
(6) 0x0000000081a00000..0x0000000081a3ffff printed by driver
(7) 0x0000000081a40000..0x0000000081bfffff listed in reg/memory
(8) 0x0000000082800000..0x00000000847fffff listed in reserved
If you just want information for region (4), sound we can do it in user-space?
BTW, are region 1, 2, 3, 6, reserved in membock?
--
Wei Yang
Help you, Help me
>On Thu, May 30, 2024 at 07:49:28PM +0900, Jaewon Kim wrote:
>>>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote:
>>>>(Sorry I might forget to change to be plain text)
>>>>
>>>>Oh good thing, I did not know this patch. Thanks.
>>>>
>>>>By the way, I've tried to get memblock/memory and kernel log from a
>>>>device based on
>>>>v6.6.17 kernel device, to see upstream patches above.
>>>>memblok/memory does not show region for
>>>
>>>memblock/memory only shows ranges put in "memory".
>>>memblock/reserved shows ranges put in "reserved".
>>>
>>>If we just put them in "reserved", it will not displayed in "memory".
>>
>>Hi
>>Let me explain more.
>>
>>In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is.
>>
>># xxd -g 8 /proc/device-tree/memory/reg
>>00000000: 0000000081960000 00000000000a0000 ................
>>00000010: 0000000081a40000 00000000001c0000 ................
>>
>># cat sys/kernel/debug/memblock/memory
>> 0: 0x0000000081960000..0x00000000819fffff 0 NONE
>> 1: 0x0000000081a40000..0x0000000081bfffff 0 NONE
>>
>># cat sys/kernel/debug/memblock/reserved
>> 0: 0x0000000082800000..0x00000000847fffff 0 NONE
>>
>>The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map.
>>
>>(I removed the name.)
>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable AAA
>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable BBB
>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable CCC
>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DDD
>>
>
>This looks not printed by memblock_reserve(), right? It is printed by your own
>driver?
AFAIK these log came from the commit below.
aeb9267eb6b1 of: reserved-mem: print out reserved-mem details during boot
>
>>So a smart parser should combine the krenel log and the memblock/memory log.
>>
>>In my memsize feature shows it like this though.
>>
>>0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown
>>
>>BR
>>
>
>I am sorry, I still not catch your point. Let me try to understand your message.
>
>You mentioned several regions, let me put them in order.
>
>(1) 0x0000000080000000..0x0000000080dfffff printed by driver
>(2) 0x0000000080e00000..0x00000000811fffff printed by driver
>(3) 0x0000000081200000..0x00000000813fffff printed by driver
>(4) 0x0000000081400000..0x0000000081960000 expected to print in new debugfs
>(5) 0x0000000081960000..0x00000000819fffff listed in reg/memory
>(6) 0x0000000081a00000..0x0000000081a3ffff printed by driver
>(7) 0x0000000081a40000..0x0000000081bfffff listed in reg/memory
>(8) 0x0000000082800000..0x00000000847fffff listed in reserved
>
>If you just want information for region (4), sound we can do it in user-space?
>
>BTW, are region 1, 2, 3, 6, reserved in membock?
Yes correct, I though (4) case could be shown to easily catch these hidden regions.
As I said, I think 1, 2, 3, 6 seem to be not passed to kernel, it was just tried as
they are defined in kernel device tree.
>
>--
>Wei Yang
>Help you, Help me
On Fri, May 31, 2024 at 05:21:41PM +0900, Jaewon Kim wrote:
>>On Thu, May 30, 2024 at 07:49:28PM +0900, Jaewon Kim wrote:
>>>>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote:
>>>>>(Sorry I might forget to change to be plain text)
>>>>>
>>>>>Oh good thing, I did not know this patch. Thanks.
>>>>>
>>>>>By the way, I've tried to get memblock/memory and kernel log from a
>>>>>device based on
>>>>>v6.6.17 kernel device, to see upstream patches above.
>>>>>memblok/memory does not show region for
>>>>
>>>>memblock/memory only shows ranges put in "memory".
>>>>memblock/reserved shows ranges put in "reserved".
>>>>
>>>>If we just put them in "reserved", it will not displayed in "memory".
>>>
>>>Hi
>>>Let me explain more.
>>>
>>>In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is.
>>>
>>># xxd -g 8 /proc/device-tree/memory/reg
>>>00000000: 0000000081960000 00000000000a0000 ................
>>>00000010: 0000000081a40000 00000000001c0000 ................
>>>
>>># cat sys/kernel/debug/memblock/memory
>>> 0: 0x0000000081960000..0x00000000819fffff 0 NONE
>>> 1: 0x0000000081a40000..0x0000000081bfffff 0 NONE
>>>
>>># cat sys/kernel/debug/memblock/reserved
>>> 0: 0x0000000082800000..0x00000000847fffff 0 NONE
>>>
>>>The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map.
>>>
>>>(I removed the name.)
>>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable AAA
>>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable BBB
>>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable CCC
>>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DDD
>>>
>>
>>This looks not printed by memblock_reserve(), right? It is printed by your own
>>driver?
>
>AFAIK these log came from the commit below.
>aeb9267eb6b1 of: reserved-mem: print out reserved-mem details during boot
>
>>
>>>So a smart parser should combine the krenel log and the memblock/memory log.
>>>
>>>In my memsize feature shows it like this though.
>>>
>>>0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown
>>>
>>>BR
>>>
>>
>>I am sorry, I still not catch your point. Let me try to understand your message.
>>
>>You mentioned several regions, let me put them in order.
>>
>>(1) 0x0000000080000000..0x0000000080dfffff printed by driver
>>(2) 0x0000000080e00000..0x00000000811fffff printed by driver
>>(3) 0x0000000081200000..0x00000000813fffff printed by driver
>>(4) 0x0000000081400000..0x0000000081960000 expected to print in new debugfs
>>(5) 0x0000000081960000..0x00000000819fffff listed in reg/memory
>>(6) 0x0000000081a00000..0x0000000081a3ffff printed by driver
>>(7) 0x0000000081a40000..0x0000000081bfffff listed in reg/memory
>>(8) 0x0000000082800000..0x00000000847fffff listed in reserved
>>
>>If you just want information for region (4), sound we can do it in user-space?
>>
>>BTW, are region 1, 2, 3, 6, reserved in membock?
>
>Yes correct, I though (4) case could be shown to easily catch these hidden regions.
>As I said, I think 1, 2, 3, 6 seem to be not passed to kernel, it was just tried as
>they are defined in kernel device tree.
>
As you mentioned above, 1, 2, 3, 6, is printed by "of" driver. And those
information is not shown in memblock/reserve.
I am afraid the proper way is to let memblock know those ranges. Sounds "of"
driver doesn't tell memblock about these.
>
>>
>>--
>>Wei Yang
>>Help you, Help me
--
Wei Yang
Help you, Help me
>On Fri, May 31, 2024 at 05:21:41PM +0900, Jaewon Kim wrote:
>>>On Thu, May 30, 2024 at 07:49:28PM +0900, Jaewon Kim wrote:
>>>>>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote:
>>>>>>(Sorry I might forget to change to be plain text)
>>>>>>
>>>>>>Oh good thing, I did not know this patch. Thanks.
>>>>>>
>>>>>>By the way, I've tried to get memblock/memory and kernel log from a
>>>>>>device based on
>>>>>>v6.6.17 kernel device, to see upstream patches above.
>>>>>>memblok/memory does not show region for
>>>>>
>>>>>memblock/memory only shows ranges put in "memory".
>>>>>memblock/reserved shows ranges put in "reserved".
>>>>>
>>>>>If we just put them in "reserved", it will not displayed in "memory".
>>>>
>>>>Hi
>>>>Let me explain more.
>>>>
>>>>In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is.
>>>>
>>>># xxd -g 8 /proc/device-tree/memory/reg
>>>>00000000: 0000000081960000 00000000000a0000 ................
>>>>00000010: 0000000081a40000 00000000001c0000 ................
>>>>
>>>># cat sys/kernel/debug/memblock/memory
>>>> 0: 0x0000000081960000..0x00000000819fffff 0 NONE
>>>> 1: 0x0000000081a40000..0x0000000081bfffff 0 NONE
>>>>
>>>># cat sys/kernel/debug/memblock/reserved
>>>> 0: 0x0000000082800000..0x00000000847fffff 0 NONE
>>>>
>>>>The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map.
>>>>
>>>>(I removed the name.)
>>>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable AAA
>>>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable BBB
>>>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable CCC
>>>><6>[ 0.000000][ T0] OF: reserved mem: 0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DDD
>>>>
>>>
>>>This looks not printed by memblock_reserve(), right? It is printed by your own
>>>driver?
>>
>>AFAIK these log came from the commit below.
>>aeb9267eb6b1 of: reserved-mem: print out reserved-mem details during boot
>>
>>>
>>>>So a smart parser should combine the krenel log and the memblock/memory log.
>>>>
>>>>In my memsize feature shows it like this though.
>>>>
>>>>0x0000000081400000-0x0000000081960000 0x00560000 ( 5504 KB ) nomap unusable unknown
>>>>
>>>>BR
>>>>
>>>
>>>I am sorry, I still not catch your point. Let me try to understand your message.
>>>
>>>You mentioned several regions, let me put them in order.
>>>
>>>(1) 0x0000000080000000..0x0000000080dfffff printed by driver
>>>(2) 0x0000000080e00000..0x00000000811fffff printed by driver
>>>(3) 0x0000000081200000..0x00000000813fffff printed by driver
>>>(4) 0x0000000081400000..0x0000000081960000 expected to print in new debugfs
>>>(5) 0x0000000081960000..0x00000000819fffff listed in reg/memory
>>>(6) 0x0000000081a00000..0x0000000081a3ffff printed by driver
>>>(7) 0x0000000081a40000..0x0000000081bfffff listed in reg/memory
>>>(8) 0x0000000082800000..0x00000000847fffff listed in reserved
>>>
>>>If you just want information for region (4), sound we can do it in user-space?
>>>
>>>BTW, are region 1, 2, 3, 6, reserved in membock?
>>
>>Yes correct, I though (4) case could be shown to easily catch these hidden regions.
>>As I said, I think 1, 2, 3, 6 seem to be not passed to kernel, it was just tried as
>>they are defined in kernel device tree.
>>
>
>As you mentioned above, 1, 2, 3, 6, is printed by "of" driver. And those
>information is not shown in memblock/reserve.
>
>I am afraid the proper way is to let memblock know those ranges. Sounds "of"
>driver doesn't tell memblock about these.
>
Yes that is the reason why I added some code to 'of' driver, too. As I said,
if we don't change 'of' driver and memblck, we need a smart parser looking into
kernel log and memblock info, and understand these special cases.
BR
>>
>>>
>>>--
>>>Wei Yang
>>>Help you, Help me
>