January 2017 - kernelnewbies@kernelnewbies.org

How to identify the cause of " BUG: Bad page map in process python ..." kernel errors?
by Muni Sekhar Jan. 18, 2017

Jan. 18, 2017

Hi All, I am observing the following statements in the kernel log while running driver soak tests and monitoring MIPS and memory usage: [ 8350.824403] BUG: Bad page map in process python pte:000000c0 pmd:950a5067 [ 8351.457234] BUG: Bad page map in process python pte:3400000000000c0 pmd:950a5067 [ 8351.458469] BUG: Bad page map in process python pte:406486b3be206e97 pmd:950a5067 …. [ 8353.266053] BUG: Bad page map in process python pte:406486b3fb696e97 pmd:950a5067 [ 8353.305982] BUG: Bad page map in process python pte:000000c0 pmd:950a5067 [ 8355.738440] BUG: Bad rss-counter state mm:ffff880138fa7100 idx:1 val:259 [ 8374.905314] general protection fault: 0000 [#1] SMP In the kernel log, I observed that kernel reported 60 " BUG: Bad page map in process python ..." reports and 1 “BUG: Bad rss-counter state” and finally it crashed with “general protection fault”. I would like to know what does it mean by “BUG: Bad page map in process python ...” and how to identify the cause of it? To debug this, do I need to consider the “general protection fault” stack trace or the first “BUG: Bad page map in process …” stack trace? -- Thanks, Sekhar

1 0

ioremap of large space has any cost ?
by Ran Shalit Jan. 18, 2017

Jan. 18, 2017

Hello, In case where we have large space (like in fpga), we thought of using ioremap_nocache() giving the complete area space for simplicity. But does it has any cost (performance, memory or other) , or is it better to use just chunk of the required space ? Thank you, Ran

1 0

Tracing changes to mm->nr_ptes
by Paddie O'Brien Jan. 15, 2017

Jan. 15, 2017

Hi, As a learning exercise I'm using systemtap to trace all calls to pte_alloc() in the context of a particular process. pte_alloc() allocates a page table and increments mm->nr_ptes. However, the first time pte_alloc() is called (and the first time I can intercept it) mm->nr_ptes is already equal to 1. I cannot find the initial increment of mm->nr_ptes. Anyone know where I should look?! Thanks.

1 0

Is it illegal to have kernel virtual address == 0 ?
by Ran Shalit Jan. 15, 2017

Jan. 15, 2017

Hello, I've seen some modules where it is tested if virtual address is 0, and if yes, it is acted as if it is an error. But can't virtual address be zero too ? For example, in the following module: https://github.com/khilman/omap-test-dmatest/blob/master/main.c it is checked the returned value of dma_alloc_coherent as following: dma_test[i].src_buf = (unsigned long) dma_alloc_coherent(NULL, buf_size (dma_addr_t *)&dma_test[i].src_buf_phys, GFP_KERNEL | GFP_DMA); if (!dma_test[i].src_buf) { printk("dmatest_init(): get_zeroed_page() failed.\n"); r = -ENOMEM; goto cleanup; } As you can see , when dma_alloc_coherent returns 0 , it is acted as if it is an error. Thank you, Ran

2 2

Re: __vdso_gettimeofday on x86 32bit app on 64bit kernel
by Sharath Jan. 13, 2017

Jan. 13, 2017

hi, yes, I have fixed both parts of the commit "37c975545ec63320789962bf307f000f08fabd48". Actually the changes under "LINUX_2.5 {" was not needed in my case cause those symbols were not there in base kernel. These changes seems to be not enough. Well this is a production env & hence moving to newer version will be little late. Thanks SB On Sat, Jan 14, 2017 at 3:19 AM, <Valdis.Kletnieks(a)vt.edu> wrote: > On Sat, 14 Jan 2017 03:04:48 +0530, Sharath said: > > > I am trying to get __vdso_gettimeofday() for 32bit applications on a > 64bit > > kernel. The changes I have tried is below, with these changes I am not > able > > to get this working. what am I missing.? on the same kernel > > __vdso_gettimeofday for 64bit apps is able to use it. > > > > My kernel version is :- 3.4.91 > > You might want to do a 'git show 37c975545ec63320789962bf307f000f08fabd48' > and make sure you include *both* parts of the patch. You only did half > the job. > > Also, you may want to upgrade to a kernel that's not a half-decade old, so > you don't have to keep re-fixing stuff that was fixed 5 years ago. > > commit 37c975545ec63320789962bf307f000f08fabd48 > Author: Andy Lutomirski <luto(a)amacapital.net> > Date: Sat Mar 29 13:15:35 2014 -0700 > > x86, vdso: Fix the symbol versions on the 32-bit vDSO > > The new symbols provide the same API as the 64-bit variants, so they > should have the same symbol version name. This can't break > userspace, since these symbols are new for 32-bit Linux. > > >

1 0

__vdso_gettimeofday on x86 32bit app on 64bit kernel
by Sharath Jan. 13, 2017

Jan. 13, 2017

I am trying to get __vdso_gettimeofday() for 32bit applications on a 64bit kernel. The changes I have tried is below, with these changes I am not able to get this working. what am I missing.? on the same kernel __vdso_gettimeofday for 64bit apps is able to use it. My kernel version is :- 3.4.91 diff --git a/arch/x86/vdso/vdso32/vdso32.lds.S b/arch/x86/vdso/vdso32/vdso32.lds.S index 976124b..2ee34b3 100644 --- a/arch/x86/vdso/vdso32/vdso32.lds.S +++ b/arch/x86/vdso/vdso32/vdso32.lds.S @@ -19,11 +19,21 @@ ENTRY(__kernel_vsyscall); */ VERSION { + LINUX_2.6 { + global: + __vdso_clock_gettime; + __vdso_gettimeofday; + __vdso_time; + }; + LINUX_2.5 { global: __kernel_vsyscall; __kernel_sigreturn;

1 0

CMA patch
by Johannes Thoma Jan. 8, 2017

Jan. 8, 2017

Dear Kernel hackers, I've just sent out a patch for a proposal of an improvement of the cma allocator. Since I am not an experienced patch submitter, could someone maybe have a look at it before I submit it to the maintainers? I might have done formal errors (I've ran checkpatch and used git send-email but maybe I forgot something). Thanks a lot, - Johannes

3 2

AW:dma direction
by Johannes Thoma Jan. 7, 2017

Jan. 7, 2017

1 0

dma direction
by Ran Shalit Jan. 7, 2017

Jan. 7, 2017

Hello, I read the DMA-API-HOWTO https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt Which mainly talks about dma mapping APIs. But I don't understand what's the meaning of DMA direction in context of mapping. As I understand this documentation talks about mapping of dma buffers - NOT about triggering dma copy. In order to do a dma copy, we should use sometlink like dmaengine, Right ? So if dma mapping is not concerned with copying dma from cpu to device (or vice versa), why does it talks about dma direction ? Thanks, Ran

1 0

Re: [PATCH] mm: cma: Retry from the beginning of cma area if all blocks are busy
by Johannes Thoma Jan. 6, 2017

Jan. 6, 2017

Am 06.01.17 um 18:30 schrieb Valdis.Kletnieks(a)vt.edu: > On Fri, 06 Jan 2017 18:12:41 +0100, Johannes Thoma said: > >> Am 06.01.17 um 17:54 schrieb Valdis.Kletnieks(a)vt.edu: >>> On Fri, 06 Jan 2017 17:16:11 +0100, johannes(a)johannesthoma.com said: > >>>> + if (start != 0 && retries--) { >>> >>> Do we have any guarantee, or even good reason to believe, that this >>> will eventually make forward progress, or can the goto hang everything? >>> I'm not thrilled by a potentially unbounded loop inside a mutex_lock(), >>> especially when you holding the mutex may be preventing something else >>> from changing things so forward progress can be made.... >>> >> Good point. That is what the retries variable is good for. To make this >> more obvious, I should write: > > No, you missed my point. > > We're inside a mutex_lock() region. We hit the goto, and drive > bitmap_find_next_zero_are_off() again. How do we know that we're not > just going to spin our wheels 10 times and fall out? What will change > the bitmap_find_next_zero_area_offset() result? > Correct me if I am wrong but setting start from a high value where no more memory is free back to zero should change the result. The scenario I had is: start is 0 -> bitmap_find_next_zero_off succeeds alloc_contig_range fails with -EBUSY start is incremented by the size of the requested block start is near the end of the area, hence bitmap_find_next_zero_off fails (new) now we set start again back to 0, so bitmap_find_next_zero_off succeeds again (it might also fail if someone else just allocated memory in which case we have to (and do) fail). alloc_contig_range succeeds. > Remember - there's a mutex_lock() around that call for a *reason*. And > I suspect the reason is specifically so nobody else *can* monkey with > the cma area. > > How is this better than just dropping the mutex, doing an mdelay(), and > then re-taking it? > That would be probably the best way to do it. I suspect you mean something like: if (start != 0) { retries--; if (retries > 0) { mutex_unlock(&cma->lock); mdelay(1); start = 0; mutex_lock(&cma->lock); goto scan_again; } } Hmm..it seems that that would require more work. Thank you for your input, - Johannes

1 0