July 2016 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Questions about the LMA and VMA in a linker script
by walker lala July 16, 2016

July 16, 2016

Hi, I got some question about the AT directive in linker script. I have post this question to binutils{at}sourceware.org with no reply. Hopefully someone can help me out. After some searching and asking, I finally know that the AT directive tell the linker about LMA of a section. For example there is some linker script like this: SECTIONS { . = 0X80100000; .text : AT(0x100000) { *(.text .stub .text.* .gnu.linkonce.t.*) } ... blah blah ... } Now 0x8010000 is a VMA, and 0x100000 is a LMA. My question is, is LMA the same as the physical address in a ELF program header ? A typical ELF declaration would be something like this: typedef struct { Elf32_Word p_type; /* Segment type */ Elf32_Off p_offset; /* Segment file offset */ Elf32_Addr p_vaddr; /* Segment virtual address */ Elf32_Addr p_paddr; /* Segment physical address */ Elf32_Word p_filesz; /* Segment size in file */ Elf32_Word p_memsz; /* Segment size in memory */ Elf32_Word p_flags; /* Segment flags */ Elf32_Word p_align; /* Segment alignment */ } Elf32_Phdr; Is LMA just **p_paddr** in the program header? My understanding is, when the linker link all the object files together and then output a executable file of ELF format, those LMA declare in the linker script would be the **p_paddr** in the executable file, so the loader can correspondingly put that program on the physical address as declared by **p_paddr**. Is that correct? Please correct me if you may. I'm reading some low level code and is not really familiar with those low level stuff. Thanks in advance! Ruan.

3 4

/sys/devices/system/node/node0 and /sys/devices/system/node1
by Kevin Wilson July 14, 2016

July 14, 2016

Hello, Just wonder: I one server I see /sys/devices/system/node/node0 while on a different server I see /sys/devices/system/node/node1 Is this configurable ? what determines whether a machine has only node 0 or only node 1 or both (or more)? Regards, Kevin

1 0

Re: OS Error: 105 (Shilpa Yellapragada)
by harisha ja July 13, 2016

July 13, 2016

Hi Shilpa, #define ENOBUFS 105 /* No buffer space available */ By any chance are you hitting this issue ? On Wed, Jul 13, 2016 at 9:30 PM, <kernelnewbies-request(a)kernelnewbies.org> wrote: > Send Kernelnewbies mailing list submissions to > kernelnewbies(a)kernelnewbies.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > or, via email, send a message with subject or body 'help' to > kernelnewbies-request(a)kernelnewbies.org > > You can reach the person managing the list at > kernelnewbies-owner(a)kernelnewbies.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Kernelnewbies digest..." > > > Today's Topics: > > 1. Re: Memory pages not released by the filesystem after a > truncate (Houssem Daoud) > 2. Re: Memory pages not released by the filesystem after a > truncate (Houssem Daoud) > 3. OS Error: 105 (Shilpa Yellapragada) > 4. Re: OS Error: 105 (Rami Rosen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 12 Jul 2016 17:12:31 -0400 > From: Houssem Daoud <houssem.daoud(a)polymtl.ca> > Subject: Re: Memory pages not released by the filesystem after a > truncate > To: Mulyadi Santosa <mulyadi.santosa(a)gmail.com> > Cc: kernelnewbies <kernelnewbies(a)kernelnewbies.org> > Message-ID: <ffed6472-b7d5-64d4-3cda-e187b36d583b(a)polymtl.ca> > Content-Type: text/plain; charset="windows-1252" > > The situation is the following: Filesystem anonymous pages are consuming > all the available memory and only 100 MB is left to the system. > > The network driver, which allocates memory objects for Jumbo frames, > needs more than 100 MB to run correctly. If a burst of networks packets > arrive together, the available memory is fully consumed and the new > packets start to be dropped. > > This situation wouldn't happen if the "useless" pages of the filesystem > were released just after the truncate operation. > > What is the point of keeping truncated pages in memory ? Is that a > choice made by the kernel developers or there is something wrong in the > filesystem implementation ? > > > On 16-07-06 12:29 PM, Mulyadi Santosa wrote: > > Hi > > > > Trying to help here: > > You said you wanna do atomic allocation. But then you said you want to > > allocate around ~100 MB contiguous memory region. > > > > IIRC, if you want to do atomic allocation, usually it can not be that > > big. I am not sure how large, but surely not reaching 100 MB. For that > > size, I think you should rely on vmalloc. > > > > But, for clarification, maybe you should also post your full content > > of /proc/buddyinfo and /proc/meminfo > > > > > > -- > > regards, > > > > Mulyadi Santosa > > Freelance Linux trainer and consultant > > > > blog: the-hydra.blogspot.com <http://the-hydra.blogspot.com> > > training: mulyaditraining.blogspot.com > > <http://mulyaditraining.blogspot.com> > > > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies(a)kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >

1 0

OS Error: 105
by Shilpa Yellapragada July 13, 2016

July 13, 2016

Hi, Can someone explain me why I am encountering an OS error 105, while trying to write to a socket? Regards, Shilpa -- Shilpa Yellapragada Software Engineer Infinera India Pvt Ltd

2 1

Memory pages not released by the filesystem after a truncate
by Houssem Daoud July 12, 2016

July 12, 2016

Hi, My system experiencing problems with atomic memory allocations. Device drivers are not able to allocate contiguous memory regions due to a high fragmentation level. At the time of failure: /proc/meminfo shows the following information: MemTotal: 4021820 Kb MemFree: 121912 Kb Active: 1304396 Kb Inactive: 2377124 Kb Most of the memory is consumed by the LRU inactive list and only 121 Mb is available to the system. By using a tracer, I found that most of the pages in the inactive list are created by the ext4 journal during a truncate operation. The call stack of the allocation is: [ __alloc_pages_nodemask alloc_pages_current __page_cache_alloc find_or_create_page __getblk jbd2_journal_get_descriptor_buffer jbd2_journal_commit_transaction kjournald2 kthread ] The problem is easily reproducible using the following script: #!/bin/bash while true; do dd if=/dev/zero of=output.dat bs=100M count=1 done Is that a normal behavior ? I know that the philosophy of memory management in Linux is to use the available memory as much as possible, but what is the need of keeping truncated pages in the LRU if we know that they are not even accessible ? The problem of the inactive list growth occurs only with the journal mode of ext4, not with the write-back mode. A chart representing the utilization of memory during the test is provided in this link: http://secretaire.dorsal.polymtl.ca/~hdaoud/ext4_journal_meminfo.png Thanks, Houssem

2 3

Proper way to get device file minor number from struct file
by Matwey V. Kornilov July 10, 2016

July 10, 2016

Hello, I am looking through some legacy out of tree custom linux kernel device driver. It is full of lines like the following: iminor(fp->f_dentry->d_inode) here struct file *fp is an argument of callback of struct file_operations. Documentation/filesystems/porting says: "f_dentry is gone; use f_path.dentry, or, better yet, see if you can avoid it entirely" So, is there a proper compatible way to do the same?

2 1

Is there any good literature explaining Linux's file system ?
by Yubin Ruan July 10, 2016

July 10, 2016

Hi everybody, I'm really curious about whether there is any literature that describe Linux's file systems(e.g. ext2{3,4}, btrfs) deeply? I can't find much literature about Linux's filesystem. I have read some papers about Unix's file system. For example, **A Fast File System for UNIX**, which explain things in detail(though not so informative for me). I also read **Design and Implementation of the Second Extend Filesystem** by Remy, Theodore, et al. But those papers and blogs can't make thing clear for me, because there are so many things that they have not explained. I wonder is there any book that explain one of the Linux filesystem(design, implementation) in detail, like what Mal Gorman explain about Linux Memory Management in his books **Understand The Linux Memory Manager** and **Code Commentary On The Linux Virtual Memory Manager** ? Thanks in advance, Ruan.

2 1

Re: Setting inode during lookup
by Bruce D. Wilner July 8, 2016

July 8, 2016

<petkov <at> uni-muenster.de> writes: > > On Tuesday 31 August 2004 20:00, Shehjar Tikoo wrote: > > Hi all. > Hi there, > > > > I have a query regarding lookups in VFS.Im using > > version 2.6.7. > > > > open_namei calls path_lookup, in case of a plain open, > > which in turn calls __emul_lookup_dentry, > > if the path is an absolute path. > > In __emul_lookup_dentry theres a call to path_walk > > which calls link_path_walk, Funny how they call this forum .*newbies. You wanna talk newbies, look at the Linux kernel code. Something as simple as namei() had to be split nito umpteen pieces, each of which is less organized than the next. The comments appear to have been written by children and are peppered with "in joke"-style wisecracks that only point to their authors' immaturity and lack of technical seniority. NEVER have I seen more disorganized code. Funny, the CAPTCHA word to enter was "exhumed." This sad sack replacement for namei() looks like it was exhumed from God-knows-where.

1 0

CMA failure
by Ronit Halder July 8, 2016

July 8, 2016

Hi, I am going through CMA (Contiguous Memory Allocator) code. In, What situation CMA unable to allocate memory from a CMA area? regards, Ronit

1 0

spi can't read more than 64 bytes
by Moti Cohen July 7, 2016

July 7, 2016

Hi all, I'm trying to write a kernel device driver for a Freescale imx6 processor based board. This driver is using spi to communicate with a radio module (using linux spi.c). I managed to wr/rd from the module, however once I'm trying to read more than 64 bytes I'm getting coruppted data. here are some details: The SPI reading process goes as follows: 1. Interrupt function is invoked from SPI device via dedicated GPIO line. 2. The interrupt function performs asynchronous SPI read in the following order: 2.1 radio_trx_end_callback is called, as it is the registered call back function. 2.2 radio_trx_end_callback calls hal_frame_read function which prepares spi_message and spi_transfer structures and fill them with relevant data: spi_device , data tx, transfer len , complete handler , … 3. The read itself is done by calling to function spi_async 4. The completion handler function is called and prints the read message, but trying to read more than 64 bytes in one transaction causes the read data to be corrupted. Any idea why am I seeing this behavior ? Is there (in Linux) any definition for the size to be read via the SPI ? The relevant variables and functions can be seen below: Thanks in advance for helping.. __________________________ uint8_t rx_buf[200]; uint8_t reg[200] = {HAL_TRX_CMD_FR, 0xff, 0xff}; struct spi_transfer transfer; struct spi_message spi_msg; // interrupt function //----------------------------------------------------------------------------------------------------------------------- static irq_handler_t radio_trx_end_callback(unsigned int irq, void *dev_id, struct pt_regs *regs) { hal_frame_read(irq, dev_id); return (irq_handler_t) IRQ_HANDLED; // Announce that the IRQ has been handled correctly } //read function //----------------------------------------------------------------------------------------------------------------------- void hal_frame_read(unsigned int irq, void *dev_id) { int status; spi_device->irq = irq; spi_message_init(&spi_msg); spi_msg.spi = spi_device; spi_msg.complete = rf_rx_completion_handler; spi_msg.context = NULL; memset((uint8_t*)&transfer, 0, sizeof(transfer)); memset(rx_buf, 0xFF, sizeof(rx_buf)); memset(reg, 0xFF, sizeof(reg)); reg[0] = HAL_TRX_CMD_FR; transfer.tx_buf = reg; transfer.len =64; transfer.rx_buf = rx_buf; spi_message_add_tail(&transfer, &spi_msg); memset(rx_buf, 0x0, sizeof(rx_buf)); status = spi_async(spi_device, &spi_msg); return; } //read completion handler //----------------------------------------------------------------------------------------------------------------------- static void rf_rx_completion_handler(void *arg) { int ii; //print the received message printk("\npure message: rx_buf [1]-2=%02X\n ", rx_buf [1]-2); for (ii=0; ii< rx_buf [1]-2; ii++) printk("%02X ", rx_buf [2+ii]); printk("\nframe len=%X actual len=%X status=%i\n",spi_msg.frame_length, spi_msg.actual_length, spi_msg.status); send_up_rf_event_to_workque(TRX_END_EVENT); }

2 2