Re: git pull fails on linux-next (out of memory)
Hi, On Sat, Mar 31, 2012 at 3:40 AM, Arvid Brodin wrote: > Arvid Brodin wrote: > > On 2012-03-06, I cloned linux-next: > > > > $ git clone git:// > git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.gitlinux-next-20120306 > > > > > > I now want to update this repository before posting patches, to make sure > > they still apply cleanly. I first tried this on 20120328: > Tracking linux-next is a little bit different from usual trees. In particular, since Stephen Rothwell rebases it quite frequently, you shouldn't do a git pull on linux-next. See these articles for details on how to work with linux-next: http://linux.f-seidel.de/linux-next/pmwiki/pmwiki.php?n=Linux-next.FAQ http://lists.kernelnewbies.org/pipermail/kernelnewbies/2012-February/004498.html Regards, Srivatsa S. Bhat ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: git pull fails on linux-next (out of memory)
Arvid Brodin wrote: > On 2012-03-06, I cloned linux-next: > > $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > linux-next-20120306 > > > I now want to update this repository before posting patches, to make sure > they still apply cleanly. I first tried this on 20120328: > > $ git pull > remote: Counting objects: 63784, done. > remote: Compressing objects: 100% (13595/13595), done. > remote: Total 45829 (delta 38421), reused 38448 (delta 31414) > Receiving objects: 100% (45829/45829), 9.87 MiB | 209 KiB/s, done. > Resolving deltas: 100% (38421/38421), completed with 5695 local objects. >>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next > + 5a377dc...bc6f15c akpm-end -> origin/akpm-end (forced update) >055bf38..de8856d akpm-start -> origin/akpm-start > + a568b5f...7734592 master -> origin/master (forced update) >055bf38..de8856d stable -> origin/stable > * [new tag] next-20120328 -> next-20120328 >>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next > * [new tag] v3.3 -> v3.3 > * [new tag] v3.3-rc7 -> v3.3-rc7 > warning: too many files (created: 1625 deleted: 423), skipping inexact rename > detection > warning: too many files (created: 5127 deleted: 1509), skipping inexact > rename detection > warning: too many files (created: 1134 deleted: 655), skipping inexact rename > detection > warning: too many files (created: 4816 deleted: 3510), skipping inexact > rename detection > warning: too many files (created: 1004 deleted: 544), skipping inexact rename > detection > warning: too many files (created: 1734 deleted: 1778), skipping inexact > rename detection > warning: too many files (created: 1069 deleted: 608), skipping inexact rename > detection > warning: too many files (created: 1070 deleted: 764), skipping inexact rename > detection > warning: too many files (created: 757 deleted: 405), skipping inexact rename > detection > warning: too many files (created: 980 deleted: 542), skipping inexact rename > detection > fatal: inflateInit: out of memory (no message) > > > I then "forgot" about it for a little while, doing other stuff. Tried it > again today: > > > $ git pull > remote: Counting objects: 16816, done. > remote: Compressing objects: 100% (1595/1595), done. > remote: Total 9491 (delta 7901), reused 9254 (delta 7678) > Receiving objects: 100% (9491/9491), 2.53 MiB | 299 KiB/s, done. > Resolving deltas: 100% (7901/7901), completed with 3010 local objects. >>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next > + bc6f15c...73bd151 akpm-end -> origin/akpm-end (forced update) > de8856d..1c03658 akpm-start -> origin/akpm-start > + 7734592...1dc85fe master -> origin/master (forced update) >de8856d..1c03658 stable -> origin/stable > * [new tag] next-20120330 -> next-20120330 > warning: too many files (created: 1625 deleted: 423), skipping inexact rename > detection > warning: too many files (created: 5127 deleted: 1509), skipping inexact > rename detection > warning: too many files (created: 1134 deleted: 655), skipping inexact rename > detection > warning: too many files (created: 4816 deleted: 3510), skipping inexact > rename detection > warning: too many files (created: 1004 deleted: 544), skipping inexact rename > detection > warning: too many files (created: 1734 deleted: 1778), skipping inexact > rename detection > warning: too many files (created: 1069 deleted: 608), skipping inexact rename > detection > warning: too many files (created: 1070 deleted: 764), skipping inexact rename > detection > warning: too many files (created: 757 deleted: 405), skipping inexact rename > detection > warning: too many files (created: 1084 deleted: 773), skipping inexact rename > detection > warning: too many files (created: 980 deleted: 542), skipping inexact rename > detection > fatal: Out of memory? mmap failed: Cannot allocate memory > > $ git gc > Counting objects: 2609985, done. > Delta compression using up to 2 threads. > Compressing objects: 100% (392553/392553), done. > Writing objects: 100% (2609985/2609985), done. > Total 2609985 (delta 2197683), reused 2602739 (delta 2190459) > > $ git pull > warning: too many files (created: 1625 deleted: 423), skipping inexact rename > detection > warning: too many files (created: 5127 deleted: 1509), skipping inexact > rename detection > warning: too many files (created: 1134 deleted: 655), skipping inexact rename > detection > warning: too many files (created: 4816 deleted: 3510), skipping inexact > renam
Re: Translate keysyms to ASCII
Anyway, does not work... I just would like to know if the kernel offers me a conversion table. As I said, I did it already by myself, but was just looking for a more stylish way to do... On Thu, Mar 29, 2012 at 7:42 PM, Jeff Haran wrote: > From: kernelnewbies-boun...@kernelnewbies.org [mailto: > kernelnewbies-boun...@kernelnewbies.org] On Behalf Of Gabriel Duarte > Sent: Thursday, March 29, 2012 4:14 AM > To: kernelnewbies@kernelnewbies.org > Subject: Translate keysyms to ASCII > > Hello people, > > > I working on a small proof of concept keylogger that works on kernel mode. > It's parte of my studies of kernel development. > I'm using the struct "keyboard_notifier_param" to get the keys pressed on > the keyboard(s) attached to the system. > > At the end, I print the value, like this: > > printk(KERN_DEBUG "KEY== %i", param->value); > > > According to the definition of the struct "keyboard_notifier_param" at > http://lxr.free-electrons.com/source/include/linux/keyboard.h#L37, the > field value is a "keycode, unicode value or keysym". > > For example, when I press the key a, I get the value 30, but I would like > tranlate it to the ASCII. I managed to create a translation table by > myself, but I think there is another way more stylish to do this, or not? I > googled a lot but could not find a consistent answer. > > Any help is appreciated, > > Gabriel. > > -- > Gabriel Duarte > Linux User #471185 > France / Grenoble - Rhône Alpes > http://genericdev.wordpress.com/ > > The term I think you want to search for is "PC keyboard scan code". This > link seems to cover it pretty well: > > http://www.quadibloc.com/comp/scan.htm > > Jeff Haran > > > -- Gabriel Duarte Linux User #471185 France / Grenoble - Rhône Alpes http://genericdev.wordpress.com/ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
git pull fails on linux-next (out of memory)
On 2012-03-06, I cloned linux-next: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git linux-next-20120306 I now want to update this repository before posting patches, to make sure they still apply cleanly. I first tried this on 20120328: $ git pull remote: Counting objects: 63784, done. remote: Compressing objects: 100% (13595/13595), done. remote: Total 45829 (delta 38421), reused 38448 (delta 31414) Receiving objects: 100% (45829/45829), 9.87 MiB | 209 KiB/s, done. Resolving deltas: 100% (38421/38421), completed with 5695 local objects. >From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next + 5a377dc...bc6f15c akpm-end -> origin/akpm-end (forced update) 055bf38..de8856d akpm-start -> origin/akpm-start + a568b5f...7734592 master -> origin/master (forced update) 055bf38..de8856d stable -> origin/stable * [new tag] next-20120328 -> next-20120328 >From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next * [new tag] v3.3 -> v3.3 * [new tag] v3.3-rc7 -> v3.3-rc7 warning: too many files (created: 1625 deleted: 423), skipping inexact rename detection warning: too many files (created: 5127 deleted: 1509), skipping inexact rename detection warning: too many files (created: 1134 deleted: 655), skipping inexact rename detection warning: too many files (created: 4816 deleted: 3510), skipping inexact rename detection warning: too many files (created: 1004 deleted: 544), skipping inexact rename detection warning: too many files (created: 1734 deleted: 1778), skipping inexact rename detection warning: too many files (created: 1069 deleted: 608), skipping inexact rename detection warning: too many files (created: 1070 deleted: 764), skipping inexact rename detection warning: too many files (created: 757 deleted: 405), skipping inexact rename detection warning: too many files (created: 980 deleted: 542), skipping inexact rename detection fatal: inflateInit: out of memory (no message) I then "forgot" about it for a little while, doing other stuff. Tried it again today: $ git pull remote: Counting objects: 16816, done. remote: Compressing objects: 100% (1595/1595), done. remote: Total 9491 (delta 7901), reused 9254 (delta 7678) Receiving objects: 100% (9491/9491), 2.53 MiB | 299 KiB/s, done. Resolving deltas: 100% (7901/7901), completed with 3010 local objects. >From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next + bc6f15c...73bd151 akpm-end -> origin/akpm-end (forced update) de8856d..1c03658 akpm-start -> origin/akpm-start + 7734592...1dc85fe master -> origin/master (forced update) de8856d..1c03658 stable -> origin/stable * [new tag] next-20120330 -> next-20120330 warning: too many files (created: 1625 deleted: 423), skipping inexact rename detection warning: too many files (created: 5127 deleted: 1509), skipping inexact rename detection warning: too many files (created: 1134 deleted: 655), skipping inexact rename detection warning: too many files (created: 4816 deleted: 3510), skipping inexact rename detection warning: too many files (created: 1004 deleted: 544), skipping inexact rename detection warning: too many files (created: 1734 deleted: 1778), skipping inexact rename detection warning: too many files (created: 1069 deleted: 608), skipping inexact rename detection warning: too many files (created: 1070 deleted: 764), skipping inexact rename detection warning: too many files (created: 757 deleted: 405), skipping inexact rename detection warning: too many files (created: 1084 deleted: 773), skipping inexact rename detection warning: too many files (created: 980 deleted: 542), skipping inexact rename detection fatal: Out of memory? mmap failed: Cannot allocate memory $ git gc Counting objects: 2609985, done. Delta compression using up to 2 threads. Compressing objects: 100% (392553/392553), done. Writing objects: 100% (2609985/2609985), done. Total 2609985 (delta 2197683), reused 2602739 (delta 2190459) $ git pull warning: too many files (created: 1625 deleted: 423), skipping inexact rename detection warning: too many files (created: 5127 deleted: 1509), skipping inexact rename detection warning: too many files (created: 1134 deleted: 655), skipping inexact rename detection warning: too many files (created: 4816 deleted: 3510), skipping inexact rename detection warning: too many files (created: 1004 deleted: 544), skipping inexact rename detection warning: too many files (created: 1734 deleted: 1778), skipping inexact rename detection warning: too many files (created: 1069 deleted: 608), skipping inexact rename detection warning: too many files (created: 1070 deleted: 764), skipping inexact rename detection warning: too many files (created: 757 deleted: 405), skipping inexact rename detection warning: too many files (created: 1084 deleted: 773), skipping inexact rename
Re: How to debug a kernel thread?
Hi Parmenides.. On Fri, Mar 30, 2012 at 19:00, Parmenides wrote: > > In the guest, 'mymodule.ko' is inserted again > > insmod mymodule.ko > > I found that the breakpoint set at mymodule.c:37 is triggered this > time surprisingly, and the 'insmod' didn't return immediately until > the gdb is given with another 'continue' command. > > (gdb) continue > > Then, the breakpoint doesn't triggered anymore as usual, Reading your above explanation, assuming that you inserted the symbol file into the right offset, I think you might found a bug in Qemu's gdb stub itself. I highly suggest you report this problem directly to qemu-devel list to get quick fix. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
How to debug a kernel thread?
Hi, It is said that the kernel can be debugged in qemu and I take a try. First, I started the qemu with qemu -m 64M -kernel arch/x86/boot/bzImage -initrd ~/image.cpio.gz -net nic -net tap,ifname=tap0 -s In another console gdb vmlinux (gdb) target remote localhost:1234 (gdb) continue A LKM (mymodule.ko) which starts a kernel thread is made with debug info, and was 'scp' to the guest. In guest, it is inserted by insmod mymodule.ko Then, back to gdb (gdb) add-symbol-file mymodule.ko 0xc482e000 (gdb) break mymodules.c:37 (gdb) continue The 37th line of mymodules.c is in a loop of kernel thread, which ensures the breakpoint should be triggered every time the loop go through. But, the breakpoint doesn't triggered as expected. Instead, the kernel thread is running over and over indicated by its repeated output messages. So, I think a kernel thread can not be break by any breakpoint. However, I think maybe the gdb want to attach to the kernel thread. Then, I checked the kernel thread's PID with ps and got 62. (gdb) control+C (gdb) attach 62 The gdb promted me it will kill the program being debugged. I answered with 'yes', the gdb told me ptrace: No such process. then the debug session is terminated and the guest is closed. I started the qemu with the above command again qemu -m 64M -kernel arch/x86/boot/bzImage -initrd ~/image.cpio.gz -net nic -net tap,ifname=tap0 -s And, without quitting the gdb (gdb) target remote localhost:1234 (gdb) continue In the guest, 'mymodule.ko' is inserted again insmod mymodule.ko I found that the breakpoint set at mymodule.c:37 is triggered this time surprisingly, and the 'insmod' didn't return immediately until the gdb is given with another 'continue' command. (gdb) continue Then, the breakpoint doesn't triggered anymore as usual, There is two questions: 1. Why the kernel thread can not be break? 2. Why is the breakpoint triggered just when the 'mymodule.ko' is loaded? Thanks. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: PER-CPU data
On 03/30/2012 12:05 PM, Dave Hylands wrote: > Hi Rajasekhar, > > On Thu, Mar 29, 2012 at 11:00 PM, Rajasekhar Pulluru > wrote: >> Hi, >> >> I would like to know how per-cpu data are stored internally? >> And how are they protected from other cores? > To put it in very simplistic terms, per-cpu data is nothing but having NR_CPUS copies of the data, like an array, something like: int data[NR_CPUS]; And accessing this per-cpu data will essentially boil down to finding out the id of the processor you are running on, and indexing this array using that, something like: int val, cpu; cpu = smp_processor_id(); val = data[cpu]; So you automatically read/write the copy that belongs to your processor. That's it. However, this is an over-simplified view of per-cpu data, but you get the general idea... > I believe that they're just kmalloc'd like other kernel data. At the > kernel level there is no protection, just like all the rest of the > memory accessible to the kernel. > http://lxr.linux.no/#linux+v3.3/include/asm-generic/percpu.h#L8 > http://lxr.linux.no/#linux+v3.3/mm/percpu.c > > When you declare a per-cpu variable, it goes into a special section, > and what you're really doing is figuring out the offset within a > per_cpu region of memory. > Regards, Srivatsa S. Bhat ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
