kernel oops messages - addresses

1
votes

In the course of kernel studying I have two questions:

1) I'd like to know if the addresses displayed in kernel Oops messages are virtual or physical? (I think those should be virtual, as long CPU operates with virtual address space and does MMU remapping?)

2) My platform is ARM based, and it supports MMU, however when I look in to addresses kernel modules load at, I see this:

# cat /sys/module/mydrv/sections/.data
0xbf00b4f4
# cat /sys/module/mydrv/sections/.text
0xbf006000

Should not those addresses be something like 0xffffffffa0110000, 0xffffffffa011b948? What I mean is in my understanding virtual memory addresses are supposed to be larger and thus provide larger virtual address space? Again I'm newbie and of course don't completely understand VM and MMU :)

Appreciate your comments, thanks.

Mark

1
debugginglinux-kernel

1 Answers

2
votes

1) I'd like to know if the addresses displayed in kernel Oops messages are virtual or physical? (I think those should be virtual, as long CPU operates with virtual address space and does MMU remapping?)

The addresses displayed in the OOPS/panic stack traces are all virtual

2) Should not those addresses be something like 0xffffffffa0110000, 0xffffffffa011b948? What I mean is in my understanding virtual memory addresses are supposed to be larger and thus provide larger virtual address space? Again I'm newbie and of course don't completely understand VM and MMU :)

No you should see only 32 bit addresses unless you are using the new 64-bit armv8 architecture :-) So the answer is it depends on what architecture you are using and whether you are using the 3G/1G vs 2G/2G kernel split. [Most linux machines are configured so that the kernel occupies the upper 1G (0xc0000000 - 0xffffffff) of the 4G address space and processes use the lower 3G (0x00000000 - 0xbfffffff). However, some machine are configured with a 2G/2G split, with the kernel occupying the upper 2G (0x80000000 - 0xffffffff) and processes using the lower 2G (0x00000000 - 0x7fffffff). I think the kernel config VMSPLIT_3G/VMSPLIT_2G sets this].