Bug 167795 - Physical address of high_memory sometimes too low when "mem=" kernel parameter is used.
Physical address of high_memory sometimes too low when "mem=" kernel paramete...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-08 05:41 EDT by Jure Skvarc
Modified: 2015-01-04 17:21 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-12 22:51:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test program which helps confirming bug 167795. (911 bytes, text/plain)
2005-09-08 05:45 EDT, Jure Skvarc
no flags Details

  None (edit)
Description Jure Skvarc 2005-09-08 05:41:29 EDT
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):
kernel-2.6.11-1.1369_FC4smp

How reproducible:
Always

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.


Additional info:

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
7c17020)
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
Comment 1 Jure Skvarc 2005-09-08 05:45:37 EDT
Created attachment 118585 [details]
Test program which helps confirming bug 167795.
Comment 2 Dave Jones 2005-09-30 02:32:19 EDT
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). 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.

Thanks.
Comment 3 Jure Skvarc 2005-09-30 09:38:27 EDT
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
of 0x3D400000.
Comment 4 Dave Jones 2005-11-10 14:31:59 EST
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.

Thank you.
Comment 5 Dave Jones 2005-12-12 22:51:42 EST
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.

Note You need to log in before you can comment on or make changes to this bug.