LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
LinkBack Search this Thread
Old 09-23-2005, 01:08 PM   #1
dcfnef
LQ Newbie
 
Registered: Mar 2004
Posts: 25

Rep: Reputation: 15
gdb and mmap


Hi All,
Hopefully this is the right forum for my question. In my application I have an mmap'd virtual address to a reserved portion of memory that was carved out using the mem= command in /etc/grub.conf. Everything works fine at run time, however when I step through the code with gdb and try to examine the address the system hangs.
Running Redhat:
"Linux version 2.6.9-prep (root@mymachine) (gcc version 3.4.3) #1 SMP"

Thanks,
dc
 
Old 09-26-2005, 04:45 PM   #2
cyent
Member
 
Registered: Aug 2001
Location: ChristChurch New Zealand
Distribution: Ubuntu
Posts: 234

Rep: Reputation: 41
First off..

Please tell us why you are doing this. I cannot imagine a good reason, and I can come up with many better alternatives.

Please also give more info...

a) The relevant portion of the grub.conf

b) Are you running from root?

c) The mmap command you are using.

d) What precisely you mean by "system hangs". All process stop? Kernel panic? Just the gdb and your program stops?
 
Old 09-27-2005, 07:34 AM   #3
dcfnef
LQ Newbie
 
Registered: Mar 2004
Posts: 25

Original Poster
Rep: Reputation: 15
Hi Cyent,
Here's some answers to your questions

a) grub.conf

title Fedora Core (2.6.9-prep) mem=3000M

b) I am running from user mode

c) Here's the mmap call:

char *buf;
buf = mmap(NULL, len, PROT_READ | PROT_WRITE,
MAP_SHARED, fd, 0);

d) The system hangs as far as user mode activity. I cannot telnet in, the console window does not respond. I can however ping the machine. So there is activity.
In the application I reserve memory that is not managed by the os and will not be swapped out. These are DMA buffers that must be easily accessible and contiguous. The memory space is managed by a driver and set of application routines. This has worked fine for quite a while, I only noticed this irritating phenomenon while stepping through the code last week and trying to examine the buffer address and contents that was returned from mmap().
It's not a show stopper, however it's irritating to have a user app (gdb) be able to bring the machine to its knees.

Thanks,
dc
 
Old 09-27-2005, 03:41 PM   #4
cyent
Member
 
Registered: Aug 2001
Location: ChristChurch New Zealand
Distribution: Ubuntu
Posts: 234

Rep: Reputation: 41
That's weird. As far as I understand it that reserved memory and the space returned by the mmap call should have nothing to do with each other.

The driver may copy stuff from the DMA buffers into the mmap area and keep it synced, but it is not the same physical memory. Hmm. Unless the driver is the "other" process with which it is "MAP_SHARE"ing the memory with.

Either way, you are right, a user level process should never be able to kill a machine. If it can, its a kernel level bug, probably in this weird driver you are using.

I see in linux 2.6... there is a dma_ API which is possibly the way to go. Look in /usr/src/linux/Documentation/DMA*
 
Old 09-28-2005, 06:32 AM   #5
dcfnef
LQ Newbie
 
Registered: Mar 2004
Posts: 25

Original Poster
Rep: Reputation: 15
The driver is there mainly for the mmap call. It is shared memory but my app is the only one using it as this stage. The buffers are used by another driver that handles the DMA but I'm not using that either. Since it works fine outside the debugger, I'll have to chase down and see what gdb is doing that's funky.
Just wondering if anyone else had seen this anomally.

Thanks,
dc
 
Old 09-28-2005, 03:20 PM   #6
cyent
Member
 
Registered: Aug 2001
Location: ChristChurch New Zealand
Distribution: Ubuntu
Posts: 234

Rep: Reputation: 41
I still doubt that it is any problem with the kernel / gdb / mmap. That stuff all just works and works fine together,

Therefore it is either you hardware or the "interesting" driver you have. Do you have the source for it? It sounds like something is causing it to lock up in kernel mode. Probably a race condition and the presence of gdb in the mix is just triggering the race.
 
Old 09-29-2005, 06:37 AM   #7
dcfnef
LQ Newbie
 
Registered: Mar 2004
Posts: 25

Original Poster
Rep: Reputation: 15
mmap routine

Here's the mmap routine. Pretty boiler plate. I agree, the mmap works and has been working. I recall having this problem a long time ago with memory mapped i/o, but the system would panic. Maybe I'll try just mapping to a memory region within the o/s and see if I get the same results.


static int mmap(struct file *fp, struct vm_area_struct *vma)
{
unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
unsigned long length = (vma->vm_end - vma->vm_start);
int minor, exten;

exten = MINOR(fp->f_dentry->d_inode->i_rdev);
minor = exten & MMASK;
if(minor >= N_MINORS) {
return(-EINVAL);
}

if((offset + length) > info->res[minor].ram_len) {
return(-EAGAIN);
}
if(remap_page_range(
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)
vma,
#endif
vma->vm_start, info->res[minor].ram+offset,
length,
vma->vm_page_prot)) {

printk("mapping failed \n");
return(-EAGAIN);
}

vma->vm_flags |= VM_RESERVED;
return(0);
}

Thanks,
dc
 
Old 09-29-2005, 05:59 PM   #8
cyent
Member
 
Registered: Aug 2001
Location: ChristChurch New Zealand
Distribution: Ubuntu
Posts: 234

Rep: Reputation: 41
Hmm.

grepping around in the kernel source on my box I couldn't find remap_page_range at all.

So googling about on the subject I find it seems to be a depreciated API which was replaced by io_remap_page_range. Digging in the source I find this is just a #define around remap_pfn_range.

ie. I'm wondering if the boiler plate you are using comes from a older version of the kernel and the kernel has perhaps moved on to other things, possibly for the very reason you are encountering.

The kernel source I'm using is a bit non-standard 2.6.12-rc3-mm2 so your milage may vary.
 
Old 09-30-2005, 10:25 AM   #9
dcfnef
LQ Newbie
 
Registered: Mar 2004
Posts: 25

Original Poster
Rep: Reputation: 15
There are some differances but they appear to be pre 2.6.9 and it looks like they're already in there. Make I'll step back and look at what exactly gdb is doing.

thanks,
dc
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
normal gdb and spec gdb for kgdb Igor007 Programming 1 09-23-2005 04:15 PM
normal gdb and spec gdb for kgdb Igor007 Linux - Newbie 1 09-23-2005 01:41 PM
using mmap AngryLlama Programming 1 02-09-2005 08:53 AM
gdb .. looking for 32 bit gdb.. for ia64 suse.. nkshirsagar Suse/Novell 0 12-09-2004 03:02 AM
mmap problem os2 Programming 4 06-21-2004 05:24 PM


All times are GMT -5. The time now is 11:48 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration