On Fri, 5 May 2000 j_clifton@aerosimulation.com wrote:
>> When I use gdb to examine mmapped memory all I see are zeros. Is this a bug
or
>> is there a workaround?
>>
>> I tried 4.17.0.4 on 2.0.36 to an area of memory reserved by lilo with an
>> append=31m, and
>> with 4.17.gnat.3.13w-18 on 2.2.5-12 to PCI memory (VMIC Reflective memory). I
>> used the Reflective Memory diagnostic to confirm that the data is getting
>> written to the memory.
>>
>> Please e-mail response as I had to drop off the mailing list.
>
>If you mean ioremap'd memory and by gdb you mean using gdb on /proc/kcore
>then won't access it. Some time ago, I added two vm_flags flags VM_IOREMAP
>and VM_ALLOC so that /proc/kcore (see fs/proc/kcore.c) can skip the area
>if VM_IOREMAP is set. Why? Because when I did not do so, my SCSI HBA was
>generating parity errors while dumping off /proc/kcore. The reason is -
>some registers may be mapped in and reading them in such an arbitrary
>manner is a no-no because of side-effects.
>
>(hmmm, you mention 2.0.36 - but ELF /proc/kcore support was only added in
>2.3.x - how do you access vmalloc/ioremap'd areas in 2.0.x - it is
>impossible (you'd probably get all zeroes)).
>
>Regards,
>Tigran.
My ADA application on 2.2.5-12 opens /dev/rmnet and mmaps the PCI memory. If I
try to print or x using the address returned from mmap, all I see is zeros yet
the application code sees the data in the mmaped area. The Reflective Memory
driver mmap fileops uses remap_page_range. The addresses mmapped show up in
/proc/<pid>/maps.
My other test case on 2.0.36 opens /dev/mem and gdb sees all zeros at the
address returned (segaddr). I would have to look at the kernel code to see how
/dev/mem does mmap .
//Stuff for RTLinux testing
#define MB31 0x01F00000L
#define K1024 0x00100000L
long physical_address = MB31;
if ((mem_fd = open( "/dev/mem", O_RDWR)) < 0) {
perror("Open /dev/mem for RTLinux shared memory failed");
exit (-1);
}
segaddr = (unsigned char *)mmap(
(caddr_t)0,
K1024,
PROT_READ|PROT_WRITE,
MAP_SHARED,
mem_fd,
physical_address);
Thanks,
Jon Clifton.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:18 EST