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
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 (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.
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.
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.
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.