May 2011 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

trouble locating code that increments jiffies (arm)
by chris＠basementcode.com May 11, 2011

May 11, 2011

Hi list, I've been looking for the code that increments the jiffies variable as well as the code that connects a timer interrupt to the function that increments the variable. I'm working with the ARM architecture in case that makes a difference. I was also wondering, how many jiffies are there? Right now I'm finding that if I disable the local timer for the boot CPU (during boot) the jiffies variable stop incrementing. I always assumed the global timer was supposed to increment a single jiffies variable. I'm working with an old, modified, version of QEMU so I'm leaning towards a QEMU bug for this problem. Thanks, -C

2 1

Seeing symbols of modules in kgdb setup
by Spiro Trikaliotis May 11, 2011

May 11, 2011

Hello, I have a question on setting up kgdb. I searched the web and found some tutorials. Unfortunately, it seems many are out of date, especially taking into account that kgdb has been (partially?) integrated into the main kernel. For example, I had to find out that the parameter for kgdb are not called kgdb8250 anymore, but kgdboc. The fact that the tutorials do not mention the version they refer to does not help much, either. Now, to my problem: I think the tutorial on Linsyssoft helped me a lot (but only after combining it with other resources): http://kgdb.linsyssoft.com/quickstart.htm. I have built a custom kernel with kgdb. kgdboc and kgdbwait are set up, I can break into my machine over serial. I can single step through the kernel, as long as no modules are involved. As soon as I have a module, I do not see its symbols or source anymore. http://kgdb.linsyssoft.com/downloads.htm mentions a modified "gdbmod", which has additional functionality to allow this. Unfortunately, the patch and the gdbmod version given there are rather outdated (gdb 6.4), while my Debian system has a much newer one: 7.0.1. I do not know how to apply the patches, they do not. I have not found any information if the patch (or something similar) has been included into the main gdb. So, what do I have to do in order to get kgdb with modules to run? Any help is appreciated, and if its just a "RTFM" (as long as you tell me WHICH manual, that is ;)) Any help is appreciated. Thanks for your time. Best regards Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/

2 2

module loading order
by Simon Leung May 11, 2011

May 11, 2011

Hi all, This is a question that arose from a older kernel ( 2.6.21 ) but I think it's generic to all kernels. Actually this might not a question on the kernel itself at all. So here it goes, I'm using a USB 3G modem with this kernel. The system loads three modules for it: pl2303, option and usbserial. Problem is, it looks like the order or loading is different ( I'm judging this by the order they appear in lsmod output): Sometimes, lsmod says: pl2303 18628 0 option 9664 0 usbserial 28296 2 pl2303,option And sometimes, it says: option 9664 0 pl2303 18628 0 usbserial 28296 2 option,pl2303 Problem is, if option is before pl2303, the device won't work properly. So my question is: who decides which is loaded first, or, why does lsmod give different order? Thanks a lot!

2 1

rationale for sysfs attr store/show accepting kobj_attribute?
by Robert P. J. Day May 11, 2011

May 11, 2011

more just a curiosity than anything else, but i'm perusing the kobject sample programs in the kernel source directory and in kobject-example.c, there's one thing about which i'm a bit puzzled. the kernel header file sysfs.h defines the basic attribute structure as: struct attribute { const char *name; mode_t mode; #ifdef CONFIG_DEBUG_LOCK_ALLOC struct lock_class_key *key; struct lock_class_key skey; #endif }; in other words, simply the attribute name and mode. no problem. however, the header file kobject.h defines a more informative kobj_attribute structure thusly: struct kobj_attribute { struct attribute attr; ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr, char *buf); ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr, const char *buf, size_t count); }; as you can see, it's just a regular sysfs attribute, bundled with the respective show and store routines. what puzzles me is why those show() and store() routines are defined as being passed the larger kobj_attribute structure, rather than the simpler sysfs attribute structure. it doesn't seem as if there's much value in having the show() and store() callbacks getting those two extra pieces of information. in fact, in the sample program kobject-example.c, in the more general example, the callback routine needs to check the name of the attribute to know how to process it properly so it has to use "attr->attr.name" to access the field of the simpler "struct attribute" anyway. long question short -- even though it's clearly an arbitrary decision, was there some rationale for having those callback show() and store() routines be passed a pointer to the larger attribute structure containing the show() and store() routine addresses themselves (in this case, kobj_attribute)? or is everything those callback routines might be interested in available in the simpler "struct attribute"? and, of course, if one wanted to get the enclosing attribute structure, there's always "container_of", but i'd just like to know if there was a reason for the choice that was made. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 2

How does the kernel chooses the 'vfat' module for fat32 partitions?
by Sudheer Divakaran May 10, 2011

May 10, 2011

Hi List, I have one doubt regarding the component which determines that 'vfat' module is the correct module to be used for accessing fat32 file systems and how does vfat.ko became the ideal candidate for accessing fat32 partition? For example, even though my /etc/fstab doesn't contain any entry for my usbstick, which is having a fat32 partition, when I issued the command 'mount /dev/sdb1 /mnt/usb' after inserting the usbstick, I could see the following events in udevadm monitor --kernel --udev' s output. Pls note the lines "KERNEL[1304999552.510965] add /module/fat (module) KERNEL[1304999552.516633] add /module/vfat (module)" [Questions] 1. Who makes the decision that vfat.ko is to be used for fat32 partitions? Is it kernel/udev or some other component? 2. How does the kernel or the module loader determines that 'vfat' is the correct module to be used for accessing fat32 partition? AFAIK, there is nothing similar to 'MODULE_DEVICE_TABLE' in vfat.ko's sources, which maps partition type 'c' (partition type id for W95 FAT32) to vfat.ko (CMIIW) as in pci/usb drivers. [udevadm monitor output] KERNEL[1304999552.510965] add /module/fat (module) KERNEL[1304999552.512169] add /kernel/slab/fat_cache (slab) UDEV [1304999552.512212] add /module/fat (module) KERNEL[1304999552.512239] add /kernel/slab/fat_inode_cache (slab) UDEV [1304999552.512263] add /kernel/slab/fat_cache (slab) UDEV [1304999552.512289] add /kernel/slab/fat_inode_cache (slab) KERNEL[1304999552.516633] add /module/vfat (module) UDEV [1304999552.516861] add /module/vfat (module) KERNEL[1304999552.542026] add /module/nls_cp437 (module) UDEV [1304999552.542267] add /module/nls_cp437 (module) KERNEL[1304999552.545320] add /module/nls_iso8859_1 (module) UDEV [1304999552.545566] add /module/nls_iso8859_1 (module) [more entries...] TIA, -- Thanks Sudheer

2 4

do all kobjects in a kset need to be the same ktype?
by Robert P. J. Day May 10, 2011

May 10, 2011

in the current version of the header file kobject.h, there's this comment: /** * struct kset - a set of kobjects of a specific type, belonging to a specific subsystem. * * A kset defines a group of kobjects. They can be individually * different "types" but overall these kobjects all want to be grouped * together and operated on in the same manner. ksets are used to * define the attribute callbacks and other common events that happen to * a kobject. ... snip ... that seems contradictory. the first line suggests that all the kobjects in a kset are of a specific type, yet that comment goes on to suggest that they can be "individually" different types. can someone clarify this? rday p.s. and i'm thinking that the reference to a "subsystem" could be amended since actual subsystems don't exist anymore. i may have another question about that shortly. -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 2

BUG: scheduling while atomic
by sandeep kumar May 10, 2011

May 10, 2011

Here is the following logs i got when i collected ramdump from my development mobile after going to kernel panic Kernel version is 2.6.35.7, Android version GingerBread. BUG: scheduling while atomic: pppd/675/0x00000203 <4>[ 85.745849] Modules linked in: dhd hotspot_event_monitoring bthid cmc7xx_sdio <4>[ 85.746032] [<c003f7dc>] (unwind_backtrace+0x0/0x168) from [<c05aa808>] (dump_stack+0x18/0x1c) <4>[ 85.746154] [<c05aa808>] (dump_stack+0x18/0x1c) from [<c00d86a4>] (__schedule_bug+0x54/0x68) <4>[ 85.746246] [<c00d86a4>] (__schedule_bug+0x54/0x68) from [<c05aab3c>] (schedule+0x78/0x48c) <4>[ 85.746337] [<c05aab3c>] (schedule+0x78/0x48c) from [<c05ab604>] (schedule_timeout+0x24/0x23c) <4>[ 85.746429] [<c05ab604>] (schedule_timeout+0x24/0x23c) from [<c05aced0>] (__down+0x88/0xc4) <4>[ 85.746520] [<c05aced0>] (__down+0x88/0xc4) from [<c00fd654>] (down+0x44/0x84) <4>[ 85.746643] [<c00fd654>] (down+0x44/0x84) from [<c0440bac>] (dpram_write+0x64/0x884) <4>[ 85.746734] [<c0440bac>] (dpram_write+0x64/0x884) from [<c04414f0>] (vs_write+0x104/0x154) <4>[ 85.746826] [<c04414f0>] (vs_write+0x104/0x154) from [<c034328c>] (ppp_async_push+0x110/0x584) <4>[ 85.746917] [<c034328c>] (ppp_async_push+0x110/0x584) from [<c0343750>] (ppp_async_send+0x50/0x58) <4>[ 85.747009] [<c0343750>] (ppp_async_send+0x50/0x58) from [<c0341360>] (ppp_channel_push+0x60/0x100) <4>[ 85.747100] [<c0341360>] (ppp_channel_push+0x60/0x100) from [<c0341500>] (ppp_write+0x100/0x108) <4>[ 85.747192] [<c0341500>] (ppp_write+0x100/0x108) from [<c015a428>] (vfs_write+0xb8/0x164) <4>[ 85.747283] [<c015a428>] (vfs_write+0xb8/0x164) from [<c015a598>] (sys_write+0x44/0x70) <4>[ 85.747375] [<c015a598>] (sys_write+0x44/0x70) from [<c00390c0>] (ret_fast_syscall+0x0/0x30) <1>[ 85.747436] Unable to handle kernel NULL pointer dereference at virtual address 00000000 <1>[ 85.747497] pgd = db338000 <1>[ 85.747528] [00000000] *pgd=4a7d9031, *pte=00000000, *ppte=00000000 <0>[ 85.747619]I[ pppd: 675] Internal error: Oops: 817 [#1] PREEMPT <0>[ 85.747650]I[ pppd: 675] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state <4>[ 85.747711]I[ pppd: 675] Modules linked in: dhd hotspot_event_monitoring bthid cmc7xx_sdio <4>[ 85.747833]I[ pppd: 675] CPU: 0 Tainted: G W (2.6.35.7-perf #2) <4>[ 85.747894]I[ pppd: 675] PC is at __schedule_bug+0x58/0x68 <4>[ 85.747955]I[ pppd: 675] LR is at unwind_frame+0xe8/0x628 <4>[ 85.748016]I[ pppd: 675] pc : [<c00d86a8>] lr : [<c003f29c>] psr: a0000013 <4>[ 85.748077]I[ pppd: 675] sp : dab59d00 ip : dab59c28 fp : dab59d14 <4>[ 85.748138]I[ pppd: 675] r10: c08546b0 r9 : 0000007d r8 : 00000428 <4>[ 85.748199]I[ pppd: 675] r7 : dcbca8c0 r6 : dab58000 r5 : c080c748 r4 : 00000000 <4>[ 85.748260]I[ pppd: 675] r3 : 00000000 r2 : dab59fa8 r1 : 00000001 r0 : c00390c0 <4>[ 85.748321]I[ pppd: 675] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user <4>[ 85.748382]I[ pppd: 675] Control: 10c57c7d Table: 4b338059 DAC: 00000015 [<c00d86a8>] (__schedule_bug+0x58/0x68) from [<c05aab3c>] (schedule+0x78/0x48c) <4>[ 85.762084]I[ pppd: 675] [<c05aab3c>] (schedule+0x78/0x48c) from [<c05ab604>] (schedule_timeout+0x24/0x23c) <4>[ 85.762176]I[ pppd: 675] [<c05ab604>] (schedule_timeout+0x24/0x23c) from [<c05aced0>] (__down+0x88/0xc4) <4>[ 85.762268]I[ pppd: 675] [<c05aced0>] (__down+0x88/0xc4) from [<c00fd654>] (down+0x44/0x84) <4>[ 85.762390]I[ pppd: 675] [<c00fd654>] (down+0x44/0x84) from [<c0440bac>] (dpram_write+0x64/0x884) <4>[ 85.762481]I[ pppd: 675] [<c0440bac>] (dpram_write+0x64/0x884) from [<c04414f0>] (vs_write+0x104/0x154) <4>[ 85.762603]I[ pppd: 675] [<c04414f0>] (vs_write+0x104/0x154) from [<c034328c>] (ppp_async_push+0x110/0x584) <4>[ 85.762695]I[ pppd: 675] [<c034328c>] (ppp_async_push+0x110/0x584) from [<c0343750>] (ppp_async_send+0x50/0x58) <4>[ 85.762786]I[ pppd: 675] [<c0343750>] (ppp_async_send+0x50/0x58) from [<c0341360>] (ppp_channel_push+0x60/0x100) <4>[ 85.762908]I[ pppd: 675] [<c0341360>] (ppp_channel_push+0x60/0x100) from [<c0341500>] (ppp_write+0x100/0x108) <4>[ 85.763000]I[ pppd: 675] [<c0341500>] (ppp_write+0x100/0x108) from [<c015a428>] (vfs_write+0xb8/0x164) <4>[ 85.763092]I[ pppd: 675] [<c015a428>] (vfs_write+0xb8/0x164) from [<c015a598>] (sys_write+0x44/0x70) <4>[ 85.763214]I[ pppd: 675] [<c015a598>] (sys_write+0x44/0x70) from [<c00390c0>] (ret_fast_syscall+0x0/0x30) <0>[ 85.763305]I[ pppd: 675] Code: ebfd894a ea000000 eb134852 e3a03000 (e5833000) <4>[ 85.763458]I[ pppd: 675] ---[ end trace 1b75b31a2719ed20 ]--- <0>[ 85.763519]I[ pppd: 675] Kernel panic - not syncing: Fatal exception in interrupt <4>[ 85.763641]I[ pppd: 675] [<c003f7dc>] (unwind_backtrace+0x0/0x168) from [<c05aa808>] (dump_stack+0x18/0x1c) <4>[ 85.763732]I[ pppd: 675] [<c05aa808>] (dump_stack+0x18/0x1c) from [<c05aa884>] (panic+0x78/0x16c) <4>[ 85.763824]I[ pppd: 675] [<c05aa884>] (panic+0x78/0x16c) from [<c003d5bc>] (die+0x248/0x288) <4>[ 85.763946]I[ pppd: 675] [<c003d5bc>] (die+0x248/0x288) from [<c00437b8>] (__do_kernel_fault+0x6c/0x8c) <4>[ 85.764038]I[ pppd: 675] [<c00437b8>] (__do_kernel_fault+0x6c/0x8c) from [<c0043a70>] (do_page_fault+0x298/0x2b8) <4>[ 85.764160]I[ pppd: 675] [<c0043a70>] (do_page_fault+0x298/0x2b8) from [<c0038408>] (do_DataAbort+0x3c/0xa0) <4>[ 85.764251]I[ pppd: 675] [<c0038408>] (do_DataAbort+0x3c/0xa0) from [<c0038bec>] (__dabt_svc+0x4c/0x60) <4>[ 85.764312]I[ pppd: 675] Exception stack(0xdab59cb8 to 0xdab59d00) <4>[ 85.764373]I[ pppd: 675] 9ca0: c00390c0 00000001 <4>[ 85.764465]I[ pppd: 675] 9cc0: dab59fa8 00000000 00000000 c080c748 dab58000 dcbca8c0 00000428 0000007d <4>[ 85.764587]I[ pppd: 675] 9ce0: c08546b0 dab59d14 dab59c28 dab59d00 c003f29c c00d86a8 a0000013 ffffffff <4>[ 85.764678]I[ pppd: 675] [<c0038bec>] (__dabt_svc+0x4c/0x60) from [<c00d86a8>] (__schedule_bug+0x58/0x68) <4>[ 85.764801]I[ pppd: 675] [<c00d86a8>] (__schedule_bug+0x58/0x68) from [<c05aab3c>] (schedule+0x78/0x48c) <4>[ 85.764892]I[ pppd: 675] [<c05aab3c>] (schedule+0x78/0x48c) from [<c05ab604>] (schedule_timeout+0x24/0x23c) <4>[ 85.765014]I[ pppd: 675] [<c05ab604>] (schedule_timeout+0x24/0x23c) from [<c05aced0>] (__down+0x88/0xc4) <4>[ 85.765106]I[ pppd: 675] [<c05aced0>] (__down+0x88/0xc4) from [<c00fd654>] (down+0x44/0x84) <4>[ 85.765197]I[ pppd: 675] [<c00fd654>] (down+0x44/0x84) from [<c0440bac>] (dpram_write+0x64/0x884) <4>[ 85.765319]I[ pppd: 675] [<c0440bac>] (dpram_write+0x64/0x884) from [<c04414f0>] (vs_write+0x104/0x154) <4>[ 85.765411]I[ pppd: 675] [<c04414f0>] (vs_write+0x104/0x154) from [<c034328c>] (ppp_async_push+0x110/0x584) <4>[ 85.765502]I[ pppd: 675] [<c034328c>] (ppp_async_push+0x110/0x584) from [<c0343750>] (ppp_async_send+0x50/0x58) <4>[ 85.765624]I[ pppd: 675] [<c0343750>] (ppp_async_send+0x50/0x58) from [<c0341360>] (ppp_channel_push+0x60/0x100) <4>[ 85.765716]I[ pppd: 675] [<c0341360>] (ppp_channel_push+0x60/0x100) from [<c0341500>] (ppp_write+0x100/0x108) <4>[ 85.765838]I[ pppd: 675] [<c0341500>] (ppp_write+0x100/0x108) from [<c015a428>] (vfs_write+0xb8/0x164) <4>[ 85.765930]I[ pppd: 675] [<c015a428>] (vfs_write+0xb8/0x164) from [<c015a598>] (sys_write+0x44/0x70) <4>[ 85.766021]I[ pppd: 675] [<c015a598>] (sys_write+0x44/0x70) from [<c00390c0>] (ret_fast_syscall+0x0/0x30) <0>[ 86.776214]I[ pppd: 675] (kernel_sec_save_final_context) Final context was saved before the system reset. <0>[ 86.776306]I[ pppd: 675] (kernel_sec_set_upload_cause) : upload_cause set c8 <0>[ 86.776367]I[ pppd: 675] (kernel_sec_reset) BUILD_INFO: HWREV: b Date:May 2 2011 Time:22:27:11 <0>[ 86.776428]I[ pppd: 675] (kernel_sec_reset) Kernel panic. The system will be reset !! In the logs which error message is causing this kernel panic. BUG: scheduling while atomic: pppd/675/0x00000203 or Unable to handle kernel NULL pointer dereference at virtual address 00000000 or Kernel panic - not syncing: Fatal exception in interrupt Please help me here... Thanks in advance..

2 1

Sleep and Wake up
by Abu Rasheda May 10, 2011

May 10, 2011

I am testing my driver on much faster host processor and facing following issues: My host is too powerful and it can fill up device buffer queue very fast. I get best performance when I do busy wait, but this is not desirable and is bad design. I need to sleep and wake up quickly and predictability. Indication from device that queue has space, is coming in form of memory write (device writes to a memory location of i86 processor). I tried using wait_event_interruptible_timeout, I am depending on 2nd parameter of the function but it wake up is too slow, even tried using value of 1. Any suggestions ?

6 8

How to find SCSI device to USB device association.
by StephanT May 9, 2011

May 9, 2011

Hi all, System description: disk-less ARM, 32M, Linux 2.6.30, 4 USB ports. I plug in two USB flash sticks and I get: % df -h /dev/sda1 3.7G 32.1M 3.5G 1% /media/sda1 /dev/sdb1 7.4G 32.1M 7.0G 0% /media/sdb1 The sysfs shows: % ls /sys/bus/scsi/devices/ 25:0:0:0 26:0:0:0 (25 being the sda1 and 26 sdb1) % ls /sys/bus/usb/devices/ 1-0:1.0 1-1 1-1.1 1-1.1:1.0 1-1.4 1-1.4:1.0 1-1:1.0 usb1 and: % ls -l /sys/devices/dw_otg/usb1/1-1 drwxr-xr-x 4 root root 0 Jan 1 14:10 1-1.1 drwxr-xr-x 4 root root 0 Jan 1 14:18 1-1.4 ... >From all this information: how can I find out the association USB device number(1|4) to SCSI device (sda1|sdb1) Thanks for your help, Stephan.

2 3

Re: char driver error
by Daniel Baluta May 9, 2011

May 9, 2011

OK. See how write and read works. > $strace echo -n "abcd" > /dev/memory(/home/aravind/me > write(1, "abcd", 4) = 1 > write(1, "bcd", 3) = 1 > write(1, "cd", 2) = 1 > write(1, "d", 1) = 1 >$ strace cat /dev/memory(/home/aravind/memory) > read(3, "d", 32768) = 1 > write(1, "d", 1d) = 1 Please allocate space for more than 1 char, and also correct memory_write tmp=buf+count-1; -> tmp=buf+*f_ps-1; thanks, Daniel.

1 0