Re: Fwd: mmap /dev/mem in python

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



It's good to at least know that this doesn't seem to be a kernel
issue, and thanks for the strace advice (I am new to this level of
linux development). Here is the truncated output for devmem and the
minimal example:

--- devmem ---
open("/dev/mem", O_RDWR|O_SYNC)         = 3
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x4001f000
write(1, "/dev/mem opened.\n", 17)      = 17
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x48088) = 0x40020000
write(1, "Memory mapped at address 0x40020"..., 37) = 37
write(1, "Value at address 0x48088024 (0x4"..., 46) = 46
munmap(0x40020000, 4096)                = 0
close(3)                                = 0
io_submit(0, 0, 0xfbad2088 <unfinished ... exit status 0>
Process 1635 detached


--minimal python example--
open("/dev/mem", O_RDWR|O_SYNC|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFCHR|0640, st_rdev=makedev(1, 1), ...}) = 0
dup(3)                                  = 4
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x48088) = 0x40020000
--- SIGBUS (Bus error) @ 0 (0) ---
+++ killed by SIGBUS +++
Process 1633 detached

It looks like python decided to add a O_LARGEFILE and duplicate the
file descriptor. I'm still not sure what's going on here that's
causing the problem as both mmap2 calls are identical.

I don't mean to bombard this list with a problem that isn't related to
the kernel, so I'll post this to a python list somewhere. Thanks a
million for your help so far, this is driving me nutty! Also if any
more info would help just let me know.

On Tue, Oct 20, 2009 at 7:26 PM, Paul Walmsley <paul@xxxxxxxxx> wrote:
> On Tue, 20 Oct 2009, Brett Graham wrote:
>
>> If I run the following commads:
>> devmem2 0x48004a40 w 0x0000038a # select 32kHz clock
>> devmem2 0x48004a10 w 0x03007052 # enable iclk for gpt11
>> devmem2 0x48004a00 w 0x03007000 # enable fclk for gpt11
>>
>> which all run sensibly and alter the registers, then I try to previous
>> minimum example on address 0x48088024 (TCLK for gpt11) I get the
>> following error:
>> Unhandled fault: external abort on non-linefetch (0x1018) at 0x40020024
>> Bus error
>>
>> What puzzles me is that when I use devmem2 to read or write to the
>> same register, everything works fine.
>
> Consider running strace on devmem2 and comparing it to the strace of your
> Python code?  That should show you any differences.  If devmem2 works,
> it's unlikely to be a kernel problem.
>
>
> - Paul
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux