11:32 a.m.
Hi,
I used crash-4.0-3.18 and found a problem.
When I used kmem command to get information of
virtual address e000000105090000, which is page ptr,
segmentation fault occurred.
-----------------------------------------------------------------------
KERNEL: /usr/lib/debug/lib/modules/2.6.18-8.el5/vmlinux
DUMPFILE: /dev/mem
CPUS: 4
DATE: Tue Feb 6 15:53:25 2007
UPTIME: 01:12:05
LOAD AVERAGE: 0.55, 0.56, 0.30
TASKS: 185
NODENAME: build.fujitsu.com
RELEASE: 2.6.18-8.el5
VERSION: #1 SMP Fri Jan 26 14:16:09 EST 2007
MACHINE: ia64 (1600 Mhz)
MEMORY: 31.2 GB
PID: 16173
COMMAND: "crash"
TASK: e0000040b2660000 [THREAD_INFO: e0000040b2661040]
CPU: 1
STATE: TASK_RUNNING (ACTIVE)
crash> kmem -p | grep e000000105090000
e000000105090000 180000000 ------- ----- 0 600200080000
crash> kmem -p e000000105090000
Segmentation fault (core dumped)
-----------------------------------------------------------------------
This is a backtrace.
#0 0x40000000000faa20 in nr_to_section (nr=15032385540) at memory.c:11897
#1 0x40000000000fb360 in valid_section_nr (nr=15032385540) at memory.c:11966
#2 0x40000000000ab000 in dump_mem_map_SPARSEMEM (mi=0x60000fffffd88370)
at memory.c:3754
#3 0x40000000000b00c0 in dump_mem_map (mi=0x60000fffffd88370) at memory.c:4120
#4 0x40000000000a7b70 in cmd_kmem () at memory.c:3345
#5 0x400000000005ad20 in exec_command () at main.c:528
#6 0x400000000005a900 in main_loop () at main.c:487
It seems that there is a problem in dump_mem_map_SPARSEMEM.
Here is a part of it.
switch (mi->flags)
{
case ADDRESS_SPECIFIED:
switch (mi->memtype)
{
case KVADDR:
1) if (is_page_ptr(mi->spec_addr, NULL))
pg_spec = TRUE;
else {
if (kvtop(NULL, mi->spec_addr, &phys, 0)) {
2) mi->spec_addr = phys;
phys_spec = TRUE;
}
else
return;
}
break;
(snipped)
if (mi->flags & ADDRESS_SPECIFIED) {
3) ulong pfn = mi->spec_addr >> PAGESHIFT();
section_nr = pfn_to_section_nr(pfn);
}
4) if (!(section = valid_section_nr(section_nr))) {
1) e000000105090000 is a page pointer, so is_page_ptr returns TRUE.
2) mi->spec_addr is converted to physical addr here, but, this
code does not be executed in this case.
3) mi->spec_addr is converted to pfn, but mi->spec_addr has
virtual address in this case, so this conversion fails.
4) section_nr has invalid section number and it causes fault.
I have yet to find how to fix it.
Any idea?
Takao Indoh
12:52 p.m.
New subject: kmem command problem (bug ofdump_mem_map_SPARSEMEM?)
Takao Indoh wrote:
Hi,
I used crash-4.0-3.18 and found a problem.
When I used kmem command to get information of
virtual address e000000105090000, which is page ptr,
segmentation fault occurred.
-----------------------------------------------------------------------
KERNEL: /usr/lib/debug/lib/modules/2.6.18-8.el5/vmlinux
DUMPFILE: /dev/mem
CPUS: 4
DATE: Tue Feb 6 15:53:25 2007
UPTIME: 01:12:05
LOAD AVERAGE: 0.55, 0.56, 0.30
TASKS: 185
NODENAME: build.fujitsu.com
RELEASE: 2.6.18-8.el5
VERSION: #1 SMP Fri Jan 26 14:16:09 EST 2007
MACHINE: ia64 (1600 Mhz)
MEMORY: 31.2 GB
PID: 16173
COMMAND: "crash"
TASK: e0000040b2660000 [THREAD_INFO: e0000040b2661040]
CPU: 1
STATE: TASK_RUNNING (ACTIVE)
crash> kmem -p | grep e000000105090000
e000000105090000 180000000 ------- ----- 0 600200080000
crash> kmem -p e000000105090000
Segmentation fault (core dumped)
-----------------------------------------------------------------------
This is a backtrace.
#0 0x40000000000faa20 in nr_to_section (nr=15032385540) at memory.c:11897
#1 0x40000000000fb360 in valid_section_nr (nr=15032385540) at memory.c:11966
#2 0x40000000000ab000 in dump_mem_map_SPARSEMEM (mi=0x60000fffffd88370)
at memory.c:3754
#3 0x40000000000b00c0 in dump_mem_map (mi=0x60000fffffd88370) at memory.c:4120
#4 0x40000000000a7b70 in cmd_kmem () at memory.c:3345
#5 0x400000000005ad20 in exec_command () at main.c:528
#6 0x400000000005a900 in main_loop () at main.c:487
It seems that there is a problem in dump_mem_map_SPARSEMEM.
Here is a part of it.
switch (mi->flags)
{
case ADDRESS_SPECIFIED:
switch (mi->memtype)
{
case KVADDR:
1) if (is_page_ptr(mi->spec_addr, NULL))
pg_spec = TRUE;
else {
if (kvtop(NULL, mi->spec_addr, &phys, 0)) {
2) mi->spec_addr = phys;
phys_spec = TRUE;
}
else
return;
}
break;
(snipped)
if (mi->flags & ADDRESS_SPECIFIED) {
3) ulong pfn = mi->spec_addr >> PAGESHIFT();
section_nr = pfn_to_section_nr(pfn);
}
4) if (!(section = valid_section_nr(section_nr))) {
1) e000000105090000 is a page pointer, so is_page_ptr returns TRUE.
2) mi->spec_addr is converted to physical addr here, but, this
code does not be executed in this case.
3) mi->spec_addr is converted to pfn, but mi->spec_addr has
virtual address in this case, so this conversion fails.
4) section_nr has invalid section number and it causes fault.
I have yet to find how to fix it.
Any idea?
Takao Indoh
How about changing section #3 above to something like this?:
* to the section with that page
*/
if (mi->flags & ADDRESS_SPECIFIED) {
- ulong pfn = mi->spec_addr >> PAGESHIFT();
+ ulong pfn;
+ physaddr_t tmp;
+
+ if (pg_spec) {
+ if (!page_to_phys(mi->spec_addr, &tmp))
+ return;
+ pfn = tmp >> PAGESHIFT();
+ } else
+ pfn = mi->spec_addr >> PAGESHIFT();
section_nr = pfn_to_section_nr(pfn);
}
Dave
1:37 p.m.
New subject: kmem command problem (bug ofdump_mem_map_SPARSEMEM?)
On Tue, 06 Feb 2007 13:52:37 -0500, Dave Anderson wrote:
How about changing section #3 above to something like this?:
* to the section with that page
*/
if (mi->flags & ADDRESS_SPECIFIED) {
- ulong pfn = mi->spec_addr >> PAGESHIFT();
+ ulong pfn;
+ physaddr_t tmp;
+
+ if (pg_spec) {
+ if (!page_to_phys(mi->spec_addr, &tmp))
+ return;
+ pfn = tmp >> PAGESHIFT();
+ } else
+ pfn = mi->spec_addr >> PAGESHIFT();
section_nr = pfn_to_section_nr(pfn);
}
Thanks, it looks good, but I found another problem.
I applied your patch and tested kmem command.
crash> kmem -p e000000105090000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
It seems kmem command entered infinite loop. It is another problem.
I found page_to_phys did not return correct physical address.
When mi->spec_addr is 0xe000000105090000, corresponding physical address
is 0x180000000.
crash> kmem -p | grep e000000105090000
e000000105090000 180000000 ------- ----- 0 600200080000
However, page_to_phys returns 0x100000000. I think page_to_phys does not
support sparsemem system.
Takao Indoh
2:15 p.m.
New subject: kmem command problem (bug ofdump_mem_map_SPARSEMEM?)
Takao Indoh wrote:
On Tue, 06 Feb 2007 13:52:37 -0500, Dave Anderson wrote:
>How about changing section #3 above to something like this?:
>
> * to the section with that page
> */
> if (mi->flags & ADDRESS_SPECIFIED) {
>- ulong pfn = mi->spec_addr >> PAGESHIFT();
>+ ulong pfn;
>+ physaddr_t tmp;
>+
>+ if (pg_spec) {
>+ if (!page_to_phys(mi->spec_addr, &tmp))
>+ return;
>+ pfn = tmp >> PAGESHIFT();
>+ } else
>+ pfn = mi->spec_addr >> PAGESHIFT();
> section_nr = pfn_to_section_nr(pfn);
> }
>
Thanks, it looks good, but I found another problem.
I applied your patch and tested kmem command.
crash> kmem -p e000000105090000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
It seems kmem command entered infinite loop. It is another problem.
I found page_to_phys did not return correct physical address.
When mi->spec_addr is 0xe000000105090000, corresponding physical address
is 0x180000000.
> crash> kmem -p | grep e000000105090000
> e000000105090000 180000000 ------- ----- 0 600200080000
However, page_to_phys returns 0x100000000. I think page_to_phys does not
support sparsemem system.
Takao Indoh
Yeah, something's not right. I tested the patch on an x86_64,
and passed it the page addresses of the first page struct in each
sparsmem section, and it looks like it works OK:
crash> hex
output radix: 16 (hex)
crash> kmem -n
NODE SIZE PGLIST_DATA BOOTMEM_DATA NODE_ZONES
0 262080 ffff81000000b000 ffffffff804a2e00 ffff81000000b000
ffff81000000bb00
ffff81000000c600
ffff81000000d100
MEM_MAP START_PADDR START_MAPNR
ffff810009001000 0 0
ZONE NAME SIZE MEM_MAP START_PADDR START_MAPNR
0 DMA 4096 ffff810009001000 0 0
1 DMA32 257984 ffff810009039000 1000000 4096
2 Normal 0 0 0 0
3 HighMem 0 0 0 0
-------------------------------------------------------------------
NR SECTION CODED_MEM_MAP MEM_MAP PFN
0 ffff810009000000 ffff810009001000 ffff810009001000 0
1 ffff810009000008 ffff810009001000 ffff8100091c1000 8000
2 ffff810009000010 ffff810009001000 ffff810009381000 10000
3 ffff810009000018 ffff810009001000 ffff810009541000 18000
4 ffff810009000020 ffff810009001000 ffff810009701000 20000
5 ffff810009000028 ffff810009001000 ffff8100098c1000 28000
6 ffff810009000030 ffff810009001000 ffff810009a81000 30000
7 ffff810009000038 ffff810009001000 ffff810009c41000 38000
crash>
So for each "MEM_MAP" address above, it should show its physical
address as the "PFN" value shifted into a physical address.
And that seems to work OK:
crash> kmem -p ffff810009001000 ffff8100091c1000 ffff810009381000 ffff810009541000
ffff810009701000 ffff8100098c1000
ffff810009a81000 ffff810009c41000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff810009001000 0 ------- ----- 1 400
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff8100091c1000 8000000 ------- ----- 1 8080000000400
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff810009381000 10000000 ------- ----- 0 10080000080000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff810009541000 18000000 ------- ----- 2 18080000000824
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff810009701000 20000000 ------- ----- 0 20080000080000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff8100098c1000 28000000 ------- ----- 0 28080000080000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff810009a81000 30000000 ------- ----- 1 30080000000060
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff810009c41000 38000000 ------- ----- 1 38080000000000
crash>
But then if I take the last physical address on the machine,
for example:
crash> kmem -p | tail
ffff810009e00dd0 3fff6000 ------- ----- 0 0
ffff810009e00e08 3fff7000 ------- ----- 0 0
ffff810009e00e40 3fff8000 ------- ----- 0 0
ffff810009e00e78 3fff9000 ------- ----- 0 0
ffff810009e00eb0 3fffa000 ------- ----- 0 0
ffff810009e00ee8 3fffb000 ------- ----- 0 0
ffff810009e00f20 3fffc000 ------- ----- 0 0
ffff810009e00f58 3fffd000 ------- ----- 0 0
ffff810009e00f90 3fffe000 ------- ----- 0 0
ffff810009e00fc8 3ffff000 ------- ----- 0 0
crash> kmem -p ffff810009e00fc8
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff81000922a000 9e00000 ------- ----- 1 8080000000400
crash>
...it's incorrect. I don't see any infinite loops though.
But something's out of whack here. I'll take a look and
see what I can find.
Thanks,
Dave
3 p.m.
New subject: kmem command problem (bug ofdump_mem_map_SPARSEMEM?)
Takao Indoh wrote:
However, page_to_phys returns 0x100000000. I think page_to_phys does not
support sparsemem system.
Yeah -- the is_page_ptr() function needs to be enhanced
to support SPARSEMEM kernels...
I made a bunch of updates to the original SPARSEMEM patch
in 4.0-3.3, but missed this one.
Dave
4:18 p.m.
New subject: kmem command problem (bug ofdump_mem_map_SPARSEMEM?)
Dave Anderson wrote:
Takao Indoh wrote:
>
> However, page_to_phys returns 0x100000000. I think page_to_phys does not
> support sparsemem system.
>
>
Yeah -- the is_page_ptr() function needs to be enhanced
to support SPARSEMEM kernels...
I made a bunch of updates to the original SPARSEMEM patch
in 4.0-3.3, but missed this one.
Dave
In addition to the previous patch to dump_mem_map_SPARSEMEM(),
this update to is_page_ptr() should do the trick:
is_page_ptr(ulong addr, physaddr_t *phys)
{
int n;
ulong ppstart, ppend;
struct node_table *nt;
ulong pgnum, node_size;
+ ulong nr, sec_addr;
+ ulong nr_mem_sections;
+ ulong coded_mem_map, mem_map, end_mem_map;
+ physaddr_t section_paddr;
+
+ if (IS_SPARSEMEM()) {
+ nr_mem_sections = NR_MEM_SECTIONS();
+ for (nr = 0; nr <= nr_mem_sections ; nr++) {
+ if ((sec_addr = valid_section_nr(nr))) {
+ coded_mem_map = section_mem_map_addr(sec_addr);
+ mem_map = sparse_decode_mem_map(coded_mem_map, nr);
+ end_mem_map = mem_map + (PAGES_PER_SECTION() *
SIZE(page));
+
+ if ((addr >= mem_map) && (addr <
end_mem_map)) {
+ if ((addr - mem_map) % SIZE(page))
+ return FALSE;
+ if (phys) {
+ section_paddr =
PTOB(section_nr_to_pfn(nr));
+ pgnum = (addr - mem_map) / SIZE(page);
+ *phys = section_paddr + (pgnum *
PAGESIZE());
+ }
+ return TRUE;
+ }
+ }
+ }
+ return FALSE;
+ }
for (n = 0; n < vt->numnodes; n++) {
nt = &vt->node_table[n];
Thanks,
Dave
7:21 p.m.
New subject: kmem command problem (bug ofdump_mem_map_SPARSEMEM?)
On Tue, 06 Feb 2007 17:18:04 -0500, Dave Anderson wrote:
Dave Anderson wrote:
> Takao Indoh wrote:
>
> >
> > However, page_to_phys returns 0x100000000. I think page_to_phys does not
> > support sparsemem system.
> >
> >
>
> Yeah -- the is_page_ptr() function needs to be enhanced
> to support SPARSEMEM kernels...
>
> I made a bunch of updates to the original SPARSEMEM patch
> in 4.0-3.3, but missed this one.
>
> Dave
In addition to the previous patch to dump_mem_map_SPARSEMEM(),
this update to is_page_ptr() should do the trick:
is_page_ptr(ulong addr, physaddr_t *phys)
{
int n;
ulong ppstart, ppend;
struct node_table *nt;
ulong pgnum, node_size;
+ ulong nr, sec_addr;
+ ulong nr_mem_sections;
+ ulong coded_mem_map, mem_map, end_mem_map;
+ physaddr_t section_paddr;
+
+ if (IS_SPARSEMEM()) {
+ nr_mem_sections = NR_MEM_SECTIONS();
+ for (nr = 0; nr <= nr_mem_sections ; nr++) {
+ if ((sec_addr = valid_section_nr(nr))) {
+ coded_mem_map = section_mem_map_addr
(sec_addr);
+ mem_map = sparse_decode_mem_map
(coded_mem_map, nr);
+ end_mem_map = mem_map + (PAGES_PER_SECTION()
* SIZE(page));
+
+ if ((addr >= mem_map) && (addr <
end_mem_map)) {
+ if ((addr - mem_map) % SIZE(page))
+ return FALSE;
+ if (phys) {
+ section_paddr = PTOB
(section_nr_to_pfn(nr));
+ pgnum = (addr - mem_map) /
SIZE(page);
+ *phys = section_paddr +
(pgnum * PAGESIZE());
+ }
+ return TRUE;
+ }
+ }
+ }
+ return FALSE;
+ }
for (n = 0; n < vt->numnodes; n++) {
nt = &vt->node_table[n];
Thanks,
Dave
I applied this patch and confirmed this problem was fixed. Thanks!
crash> kmem -p e000000105090000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
e000000105090000 180000000 ------- ----- 0 600200080000
Takao Indoh
6501
days inactive
6502
days old
devel@lists.crash-utility.osci.io
6 comments
2 participants
participants (2)
-
Dave Anderson -
Takao Indoh