Red Hat Bugzilla – Bug 167795
Physical address of high_memory sometimes too low when "mem=" kernel parameter is used.
Last modified: 2015-01-04 17:21:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Description of problem:
When the amount of memory available for OS is reduced using the "mem=" keyword in the GRUB command line, the physical address corresponding to the value of high_memory variable sometimes points lower than it should. Eg. when mem=900M is used on a machine with 1 GB ram, the __pa(high_memory) corresponds to 896M. If this address is used by as a starting point for a DMA transfer, the system freeezes. The problem became apparent when trying to use a PCI based controller for an astronomical CCD camera what freezes the system. It evident from the output of the test program supplied here that the high_memory variable corresponds to 896 M (0x38000000) while it should to 900 M (0x38400000). The latter value is reported by /proc/iomem.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. On a 1 GB RAM machine, add mem=900M in the grub.conf file.
2. Compile the attached test program.
3. Install as a module.
4. Check the output in /var/log/messages
Actual Results: The test case reports the physical value of high_memory variable of 0x38000000 while it should be 0x38400000. If the physical address is then used eg. in DMA transfer, the system will freeze.
Note that this error does not happen eg. if we set mem=800M, the value reported is correctly 32000000. On the other hand, if we set mem=980M, the value is still 0x38000000 instead of 0x3D400000.
Expected Results: Physical value of high_memory should be equivalent to that supplied in "mem=" parameter and certainly not lower.
When trying to write to address high_memory, the following appears /var/log/messages before the system dies:
Sep 7 15:50:40 localhost kernel: Unable to handle kernel paging request at virtual address aa1c4000
Sep 7 15:50:40 localhost kernel: printing eip:
Sep 7 15:50:40 localhost kernel: f89e9d59
Sep 7 15:50:40 localhost kernel: *pde = 00006f7d
Sep 7 15:50:40 localhost kernel: Oops: 0002 [#1]
Sep 7 15:50:40 localhost kernel: SMP
Sep 7 15:50:40 localhost kernel: Modules linked in: astropci(U) parport_pc lp parport autofs4 rfcomm l2cap bluetooth sunrpc ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables dm_mod video button battery ac md5 ipv6 uhci_hcd ehci_hcd hw_random i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc tg3 floppy ext3 jbd raid1 raid0 ata_piix libata sd_mod scsi_mod
Sep 7 15:50:40 localhost kernel: CPU: 1
Sep 7 15:50:40 localhost kernel: EIP: 0060:[<f89e9d59>] Not tainted VLI
Sep 7 15:50:40 localhost kernel: EFLAGS: 00210286 (2.6.11-1.1369_FC4smp)
Sep 7 15:50:40 localhost kernel: EIP is at astropci_mmap+0x1b3/0x289 [astropci]
Sep 7 15:50:40 localhost kernel: eax: 00000034 ebx: aa1c4000 ecx: c035ea4c edx: 00200282
Sep 7 15:50:40 localhost kernel: esi: 00000000 edi: 00000000 ebp: e6550adc esp: e94aef04
Sep 7 15:50:40 localhost kernel: ds: 007b es: 007b ss: 0068
Sep 7 15:50:40 localhost kernel: Process java (pid: 3432, threadinfo=e94ae000 task=f
Sep 7 15:50:40 localhost kernel: Stack: f89ea710 0093c000 aa1c4000 aab00000 38000000 3893c000 f89ecfa8 f89ecfac
Sep 7 15:50:40 localhost kernel: 00000000 e6550adc e9e39680 ffffffea 0093c000 c0155c86 e94aef7c e94aef78
Sep 7 15:50:40 localhost kernel: 00000004 f62ef000 f62ef000 f62ef000 f72aca80 ef5b689c 001000ff 00000000
Sep 7 15:50:40 localhost kernel: Call Trace:
Sep 7 15:50:40 localhost kernel: [<c0155c86>] do_mmap_pgoff+0x458/0x76c
Sep 7 15:50:40 localhost kernel: [<c0109e29>] sys_mmap2+0x75/0xbf
Sep 7 15:50:40 localhost kernel: [<c0104025>] syscall_call+0x7/0xb
Sep 7 15:50:40 localhost kernel: Code: 25 7e 73 c7 8b 5c 24 20 81 c3 a0 cf 9e f8 8b
45 04 89 43 60 c7 04 24 10 a7 9e f8 e8 09 7e 73 c7 8b 5b 60 85 db 0f 84 c8 00 00 00 <
c7> 03 11 11 11 11 c7 43 04 22 22 22 22 c7 43 08 33 33 33 33 c7
Sep 7 15:50:40 localhost kernel: <0>Fatal exception: panic in 5 seconds
Created attachment 118585 [details]
Test program which helps confirming bug 167795.
Mass update to all FC4 bugs:
An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (188.8.131.52). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.
Please retest with this update, and update this bug if necessary.
The bug is exactly the same after installing kernel 2.6.13-1.1526_FC4. If
mem=980M, the physical_address of high_memory value is still 0x38000000 instead
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
high_memory defines the end of directly mapped memory (896MB), anything after
this address is in ZONE_HIGHMEM, and may not be directly mapped.
by booting with mem=900, you're creating a 4MB highmem zone, which the kernel is
free to use. Your driver is then stomping over this.