- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

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

ptrace() behaviour when doing PTRACE_KILL
by Pablo Antonio Aug. 29, 2011

Aug. 29, 2011

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. So, here's the code: http://codepad.org/TJ7Lua4Q Basically, 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. If the child process tried to create a new process via fork() or clone(), then it was immediately killed and no process was created. 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, then I don't understand why this code doesn't work as expected. If the signal is delivered after the system call is completely executed, then I don't understand why this was working for the fork() and clone() case. I'd really appreciate if someone told me what's happening here, or what I'm not seeing. Thanks, -- Pablo Antonio (AKA crazy2k) http://www.pablo-a.com.ar/

2 1

Can not free irq 0
by Parmenides Aug. 29, 2011

Aug. 29, 2011

Hi, I wonder how an interrupt handler work, and so try to make one by myself. The first problem is which irq number should I select to hook an interrupt handler on it. In terms of the following messages, I think irq 0 can be adopted because the number of interrupts raised remains 145 and does not increase any more. This case may imply the interrupt handler of rtc clock is not working and can be replaced by another one. Furthermore, I also notice that the Local timer interrupts is increasing, and guess that the clock ticks are driven by this clock chip. That means the irq 0 may be deprecated and its handler can be replaced safely. root [ ~/work/moduleprog ]# cat /proc/interrupts CPU0 0: 145 XT-PIC-XT timer <---- is not working 1: 8 XT-PIC-XT i8042 2: 0 XT-PIC-XT cascade 5: 402 XT-PIC-XT eth0 6: 3 XT-PIC-XT floppy 9: 0 XT-PIC-XT acpi 10: 0 XT-PIC-XT uhci_hcd:usb2 11: 45 XT-PIC-XT ioc0, ehci_hcd:usb1 12: 116 XT-PIC-XT i8042 14: 750 XT-PIC-XT ide0 15: 48 XT-PIC-XT ide1 NMI: 0 Non-maskable interrupts LOC: 4932 Local timer interrupts <---- is working really SPU: 0 Spurious interrupts ... ... ... ... ... The kernel module code: #include <linux/module.h> #include <linux/kernel.h> #include <linux/interrupt.h> static irqreturn_t my_interrupt(int irq, void *dev) { return IRQ_HANDLED; } int init_module(void) { free_irq(0, NULL); if (request_irq(0, my_interrupt, IRQF_SHARED, "myinterrupt", (void *)my_interrupt)){ printk(KERN_ALERT "Can not install interrupt handler of irq 0.\n"); } return 0; } void cleanup_module(void) { } MODULE_LICENSE("GPL"); MODULE_AUTHOR("parmenides"); MODULE_SUPPORTED_DEVICE("mydevice"); Compile it and then invork insmod, I get these messages: Aug 27 23:18:35 lfs kernel: ------------[ cut here ]------------ Aug 27 23:18:35 lfs kernel: kernel BUG at mm/slab.c:521! Aug 27 23:18:35 lfs kernel: invalid opcode: 0000 [#1] SMP Aug 27 23:18:35 lfs kernel: last sysfs file: /sys/kernel/uevent_seqnum Aug 27 23:18:35 lfs kernel: Modules linked in: mydevice(+) Aug 27 23:18:35 lfs kernel: Aug 27 23:18:35 lfs kernel: Pid: 1688, comm: insmod Not tainted 2.6.34 #1 440BX Desktop Reference Platform/VMware Virtual Platform Aug 27 23:18:35 lfs kernel: EIP: 0060:[<c108a835>] EFLAGS: 00010046 CPU: 0 Aug 27 23:18:35 lfs kernel: EIP is at kfree+0x67/0x96 Aug 27 23:18:35 lfs kernel: EAX: 00000000 EBX: c155eb40 ECX: 00000000 EDX: c16cdde0 Aug 27 23:18:35 lfs kernel: ESI: 00000282 EDI: c156fc80 EBP: 00000000 ESP: cf323f70 Aug 27 23:18:35 lfs kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Aug 27 23:18:35 lfs kernel: Process insmod (pid: 1688, ti=cf322000 task=cfbaa030 task.ti=cf322000) Aug 27 23:18:35 lfs kernel: Stack: Aug 27 23:18:35 lfs kernel: c155eb40 00000000 00000000 c1054076 d0846080 00000000 d0846007 d0846010 Aug 27 23:18:35 lfs kernel: <0> c100112d d0846080 00000000 f63d4e2e cf322000 c10517ce 0804b018 080488f0 Aug 27 23:18:35 lfs kernel: <0> c138ba4d 0804b018 00000826 0804b008 080488f0 f63d4e2e bfddbfb8 00000080 Aug 27 23:18:35 lfs kernel: Call Trace: Aug 27 23:18:35 lfs kernel: [<c1054076>] ? free_irq+0x2e/0x40 Aug 27 23:18:35 lfs kernel: [<d0846007>] ? init_module+0x0/0x3d [mydevice] Aug 27 23:18:35 lfs kernel: [<d0846010>] ? init_module+0x9/0x3d [mydevice] Aug 27 23:18:35 lfs kernel: [<c100112d>] ? do_one_initcall+0x44/0x120 Aug 27 23:18:35 lfs kernel: [<c10517ce>] ? sys_init_module+0xa7/0x1d9 Aug 27 23:18:35 lfs kernel: [<c138ba4d>] ? syscall_call+0x7/0xb Aug 27 23:18:35 lfs kernel: Code: e2 05 03 15 c0 65 68 c1 8b 02 25 00 80 00 00 66 85 c0 74 03 8b 52 0c 8b 02 25 00 80 00 00 66 85 c0 74 03 8b 52 0c 80 3a 00 78 04 <0f> 0b eb fe 8b 4a 18 64 a1 e8 5d 5f c1 8b 1c 81 8b 03 3b 43 04 Aug 27 23:18:35 lfs kernel: EIP: [<c108a835>] kfree+0x67/0x96 SS:ESP 0068:cf323f70 Aug 27 23:18:35 lfs kernel: ---[ end trace 00973d9f77f0e389 ]--- The problem is likely caused by free_irq(), but I don't know why and how to resolve it.

2 6

question about oops and panic
by Parmenides Aug. 29, 2011

Aug. 29, 2011

Hi, 1. I think oops and panic are both some way to deal with errors occurs in kernel space. Is there any relationship between them? 2. I make a NULL pointer reference deliberately in a kernel module and get an oops like: ... ... ... Aug 29 00:58:45 lfs kernel: Call Trace: Aug 29 00:58:45 lfs kernel: [<c100112d>] ? do_one_initcall+0x44/0x120 Aug 29 00:58:45 lfs kernel: [<c10517ce>] ? sys_init_module+0xa7/0x1d9 Aug 29 00:58:45 lfs kernel: [<c138d49d>] ? syscall_call+0x7/0xb ... ... ... I wonder what is the meaning of the tow numbers after a function name.

6 6

BlueTooth: HCI: Error message
by Pradeep Kumar Aug. 29, 2011

Aug. 29, 2011

Hi, I am seeing following error in dmesg log while I am trying to receive data(to my HTC mobile phone running Android Froyo) over BT from some external device. >> hci_acldata_packet: hci0 ACL packet for unknown connection handle can some one help me in decoding it? when would we see such message.? thanks Pradeep

1 0