August 2011 - kernelnewbies@kernelnewbies.org

Changes in block layer for IOScheduler Insertion selection
by mani Feb. 6, 2012

Feb. 6, 2012

Dear All, I am working on linux kernel 2.6.32.9 tegra NVIDIA board. I am getting ~8MBps speed of the Nand disk if i use hdparm hdparm -t /dev/mtdblock3 i made changes in block layer of kernel as below:- block/blk-core.c static inline void add_request(struct request_queue *q, struct request *req) { drive_stat_acct(req, 1); /* * elevator indicated where it wants this request to be * inserted at elevator_merge time */ __elv_add_request(q, req, ELEVATOR_INSERT_BACK, 0); //__elv_add_request(q, req, ELEVATOR_INSERT_SORT, 0); } changed ELEVATOR_INSERT_SORT to ELEVATOR_INSERT_BACK it improves my NAND speed to 10MBps. I am using "noop" I/O scheduler. Will this change have any adverse effect in kernel ? or any other side effect as far as i am using only Nand no Hard disk. Thanks Mani

3 4

Purpose of using __be16 inside a data structure?
by 陳國成 Oct. 25, 2011

Oct. 25, 2011

Hi all, Please tell me the difference between using unsigned short and __be16 to declear a variable in a data structure. For example, in include/net/inet_sock.h, struct inet_sock is decleared as struct inet_sock { __be16 inet_dport; }; not struct inet_sock { unsigned short inet_dport; }; I think it has something to do with endianness. But I see that both __le16 and __be16 are unsigned short when using gcc with -E option for little-endian and big-endian platform. Can someone give me more information? * little-endian typedef unsigned short __u16; typedef __u16 __le16; typedef __u16 __be16; * big-endian typedef unsigned short __u16; typedef __u16 __le16; typedef __u16 __be16; Regards, GC

4 4

Compile a Single Kernel Module
by Nestor Waldyd Sept. 1, 2011

Sept. 1, 2011

Hello, I am a Fedora 15 user and i would like to compile only certain kernel drivers (rt2x000) that are modules for the linux kernel. How can this be done? Any documents recommendations? Beforehand Thanks. Best Regards, -- -------------------------------------------------------------- Nestor Waldyd Alvarez Villa Ingeniero Electrónico. MSc. C. Telecomunicaciones. Universidad Pontificia Bolivariana mailto:nestor.alvarez@upb.edu.co Medellín - Antioquía. COLOMBIA -------------------------------------------------------------- Using Opera's revolutionary email client: http://www.opera.com/mail/

2 1

Kernel Lock Debugging
by Venkatram Tummala Aug. 31, 2011

Aug. 31, 2011

Hi, i wrote a linux kernel module which uses mmap_sem in lots of places. I grab mmap_sem for both reads & writes. And, i also use page_table_lock spinlock under them. The problem i have is that there is a hard to reproduce a race condition bug in which a thread doesn't release the semaphore at all. Hence, ps hangs as ps needs to grab mmap_sem for the processes. The question is how do i find the thread that is holding the semaphore forever. It will help me figure out the part of the code the race is in. So, the question is : I have some number of threads grabbing the semaphore for read/write. One of them grabs it & doesn't release at all. How do i find the thread that is holding it. This is not a soft lockup & i dont get any hung_task_timeout messages. Any help is appreciated. Thanks. Venkatram

3 3

how to configure printk() in 2.6 kernel
by Vaibhav Jain Aug. 31, 2011

Aug. 31, 2011

Hi, Can somebody please tell me how to configure printk() in fedora 15 ? All the articles I have seen on web refer to the file /etc/syslog.conf. But there is no such file on my system. I guess this has changed in the 2.6 kernel. Thanks Vaibhav Jain

6 8

pci_set_consistent_dma_mask explanation
by Christopher Harvey Aug. 31, 2011

Aug. 31, 2011

Could somebody explain the difference between pci_set_consistent_dma_mask and pci_set_dma_mask? So far what I gather is that pci_set_dma_mask tells the PCI layer that some hardware can only use DMA on addresses denoted by the mask that is passed in. As for what the "consistent" means, I haven't been able to find out. thanks.

1 0

Re: BUG: sleeping function called from invalid context
by sandeep kumar Aug. 31, 2011

Aug. 31, 2011

Hi Dave, >Maybe try calling might_sleep() instead. >> Dont know why, might_sleep() is not helping. i put might_sleep in between spin_lock & spin_unlock, it did not work. msleep worked. >> i found the issue though, as you said they called preempt_disable and forgot to enable it. >> Thanks for the response. On Wed, Aug 31, 2011 at 10:53 AM, Dave Hylands <dhylands(a)gmail.com> wrote: > Hi sandeep, > > On Tue, Aug 30, 2011 at 8:40 AM, sandeep kumar > <coolsandyforyou(a)gmail.com> wrote: > > Hi Dave, > >>>Maybe the device that was added before this one entered the atomic > >>>context and forgot to leave it. > >>>>>by this you mean to say that, the earlier device which was created, in > >>>>> its probe... > > it took some spin_lock and forgot to release the lock? > > > > > >>>You said that you called in_atomic() from msm_bus_fabric_probe and > >>>that it returned zero. Did you do this immediately before the > >>>mutex_lock call that's complaining? > >>>>> yes,i tested the in_atomic() just before the call of clk_get() which > >>>>> inturn > > calls clk_sys_get() which takes the mutex_lock(). > > Maybe try calling might_sleep() instead. > > > My another qn is.. > > The message"BUG: sleepin func called ....." is a warning message. it is > not > > called by BUG handler. > > So can i neglect it? i mean it is coming only once while in the probe, > > shall this > > lead to lock up s in future?? > > It's hard to say. It means that there is a bug somewhere. How > significant it is depends on exactly what the bug is. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.davehylands.com > -- With regards, Sandeep Kumar Anantapalli,

1 0

Re: ptrace() behaviour when doing PTRACE_KILL
by Pablo Antonio Aug. 30, 2011

Aug. 30, 2011

Hi Oleg, On Tue, Aug 30, 2011 at 10:30 AM, Oleg Nesterov <oleg(a)redhat.com> wrote: > Pablo Antonio wrote: >> >> Hello, >> I was writing some user code that uses the ptrace() system call >> and found it wasn't behaving as I expected. Maybe this is simply >> because I don't know enough about ptrace()'s behaviour, so I'd like >> someone to enlighten me with some information. > > First of all, please never use PTRACE_KILL. it is more or less > equivalent to ptrace(PTRACE_CONT, pid, 0, SIGKILL) but doesn't return > the error. > >> So, here's the code: http://codepad.org/TJ7Lua4Q Basically, > > I assume you run it on 32bit machine... otherwise you need > "8 * ORIG_RAX" and "8 * RAX". Yes, x86-32. > >> I was >> expecting the parent process to kill the child when the later >> attempted to use the kill() system call, not letting it send signals >> to other processes. I had done this before with pretty much the same >> code, but instead of killing when kill() was called, I was doing it >> when a fork() or clone() was attempted. And it worked. > > Because do_fork() checks signal_pending() and aborts if the process > is killed (actually it aborts if any signal is pending). > >> But now that I'm doing the same thing with kill(), I'm seeing that the >> child process ends up killed, as expected, but the signal is sent >> nonetheless. I understand that when I do the PTRACE_KILL, a SIGKILL >> signal is sent to the child. And PTRACE_KILL is used on syscall >> entrance in that code. If the SIGKILL signal is delivered to the >> process before it continues executing the system call in kernelspace, > > In this particular case SIGKILL was already delivered, yes. > >> then I don't understand why this code doesn't work as expected. > > Because you didn't abort this syscall. The tracee calls sys_kill() > which doesn't check the signals, the pending SIGKILL will be noticed > later, when the tracee attampts to return to the user-mode. > > This is correct. Most of non-blocking syscalls do not check the > signals, this is pointless. Thanks for your answer, Oleg. What you are saying makes sense to me, but I must say that I talked with some people (one of them was a GDB developer, the other was Denys Vlasenko) and they tested the code I you saw with different kernels and the signal was inhibited. Both of them, I think, were using redhat/fedora kernels. Maybe there's a race condition happening, maybe redhat/fedora kernels have different behaviour, I don't know. But I guess that if there's a difference in behaviour between vanilla and fedora/redhat kernels, that should be fixed. Thanks for your time, -- Pablo Antonio (AKA crazy2k) http://www.pablo-a.com.ar/

1 0

BUG: sleeping function called from invalid context
by sandeep kumar Aug. 30, 2011

Aug. 30, 2011

Hi all, I am working on android, linux kernel version: 2.6.35.11 I am getting this following error message. I know it occurs when u call a sleeping function in atomic context. As far as i knew the entire stack of functions,nothing is atomic context(these are standard platform dev add functions...) Now i want to know these things.. 1) Is there any method to know, when and where this atomic context started? (i put a log in the "msm_bus_fabric_probe" function, to check whether it is atomic or not using "in_atomic()"..it is giving '0', and also i read that in_atomic wont always work well in all cases in the header file) 2) Can we neglect this warning, is it very important? because lot of similer cases,(where "clk_get_sys" is called) are working fine. only this thing is showing warning message. can we overlook this? pls tell me [ 0.267394] BUG: sleeping function called from invalid context at /home/sandeep_CELOX_NTT/android/kernel/kernel/mutex.c:94 <3>[ 0.267455] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper <4>[ 0.267517] [<c01076a0>] (unwind_backtrace+0x0/0x164) from [<c07233f0>] (mutex_lock+0x18/0x38) <4>[ 0.267578] [<c07233f0>] (mutex_lock+0x18/0x38) from [<c010e5dc>] (clk_get_sys+0x2c/0xe4) <4>[ 0.267608] [<c010e5dc>] (clk_get_sys+0x2c/0xe4) from [<c01869b4>] (msm_bus_fabric_probe+0x630/0x818) <4>[ 0.267639] [<c01869b4>] (msm_bus_fabric_probe+0x630/0x818) from [<c0417b2c>] (platform_drv_probe+0x18/0x1c) <4>[ 0.267669] [<c0417b2c>] (platform_drv_probe+0x18/0x1c) from [<c0416788>] (driver_probe_device+0x19c/0x34c) <4>[ 0.267730] [<c0416788>] (driver_probe_device+0x19c/0x34c) from [<c04159c0>] (bus_for_each_drv+0x48/0x84) <4>[ 0.267761] [<c04159c0>] (bus_for_each_drv+0x48/0x84) from [<c0416a84>] (device_attach+0x64/0x88) <4>[ 0.267791] [<c0416a84>] (device_attach+0x64/0x88) from [<c0415788>] (bus_probe_device+0x24/0x40) <4>[ 0.267822] [<c0415788>] (bus_probe_device+0x24/0x40) from [<c04139a0>] (device_add+0x39c/0x52c) <4>[ 0.267852] [<c04139a0>] (device_add+0x39c/0x52c) from [<c0418158>] (platform_device_add+0x16c/0x1e8) <4>[ 0.267883] [<c0418158>] (platform_device_add+0x16c/0x1e8) from [<c0418498>] (platform_add_devices+0x1c/0x60) <4>[ 0.267913] [<c0418498>] (platform_add_devices+0x1c/0x60) from [<c00147d4>] (msm8x60_init+0x378/0x14a4) -- With regards, Sandeep Kumar Anantapalli,

2 1

Unknown symbol usb_register_driver
by Prajosh Premdas Aug. 30, 2011

Aug. 30, 2011

Hi I am using Linux-2.6.31-14 based on Ubuntu karmic. I am developing a proprietary usb driver and was doing my study . I have hit upon a problem, when i insert my driver using lsmod, i get an error *Unknown symbol usb_register_driver* *Unknown symbol usb_deregister* I have used these function in my init and exit. I searched through the Linux source code 2.6.35 and 2.6.31. I find that these routines are present but has not been used in even a single driver. My questions 1. Are these some obsolete technique of registering the drivers. If yes then what is the correct method. 2. Are there any code which i have to include before compiling the kernel itself. 3. Are these functions part of any modules which i have to insert using modprobe etc technique -- Regards, Prajosh Premdas

4 5