Re: kernel hangs within kernel_fpu_begin()...kernel_fpu_end()
On Thu, 01 Nov 2012, Digant wrote:
Hello ,
I am developing a feature in a X86-64 machine running kernel 3.5.5. I am
exporting this symbol to test FPU and kernel compiles fine if I call this
symbol from my module it works great. But when I used this symbol from
scheduler particularly *enqueue_fair()* (few times per second)
in/kernel/sched/fair.c it behaves weirdly. During boot kernel hangs
abruptly after few hundreds correct prints in this function after 1st
print.
Have a look at the comment above arch/x86/kernel/i387.c:irq_fpu_usable()
which states that it is sometimes awry to use the FPU from interrupt
context. Seems not unlikely to me that you run into one of these situations
regularly from within the timer interrupt. Maybe you should just print the
return value of that function, too, to see if you are messing up anything.
Am I missing any rule, because I looked it up on internet they says nothing
else than this way to use fpu. Any help is appreciated. I tried 10-20 boots
and each time it hangs.
*Code snippet for reference:*
1 /*test FPU*/
2 #include asm/i387.h
3 #include linux/time.h
4
5
6 void my_symbol(void){
7 unsigned long i = get_seconds();
8
9 printk(KERN_DEBUG i:%lu,,i);
10 kernel_fpu_begin();
11 float d = 3.123456*(i%3);
12 i=(unsigned long)(d*100);
13 kernel_fpu_end();
14 printk(KERN_DEBUG %lu\n,i);
15 }
16 EXPORT_SYMBOL_GPL(my_symbol);
Regards,
Tobi
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: linux segment
On Tue, 30 Oct 2012, Fan Yang wrote: 2012/10/29 Mulyadi Santosa mulyadi.sant...@gmail.com Hi Fan... On Sun, Oct 28, 2012 at 9:02 PM, Fan Yang lljyang...@gmail.com wrote: [root@shell--box kernel_mod]# dmesg -c ** cs 60 96 ds 7b 123 ss 68 104 es 7b 123 fs d8 216 gs e0 224 ** The cs and ds in the kernel space is 60 and 7b. But the kernel define the KERNEL_CS as 60 and the KERNEL_DS as 7b. Where am I wrong? you print CS and DS twice, once during init and once during exit of your kernel module. So, which one do you want to confirm? All in all, I have a guess that you see such number (DS belongs to user space in kernel module) because IIRC kernel module loading is done using syscall and with the help of modprobe helper. Thus, it is important to access user space during that stage, hence DS still using user space data segment. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com Hi Mulyadi Santosa I get the same result during the kernel module init and exit. Then I try to add a syscall to print these registers, and nothing changed. It is strange. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies (Weird, this is the third time, I have to send this. If anybody gets this message multiple times, I apologise but my mail is not in the archives.) If Mulyadi is right and we need DS to be USER_DS to access user space (I really don't know, sorry, but maybe there is something in your uaccess.h?) then your attempt to try with a syscall couldn't yield other values because one trait of syscalls is that they can access user space. This means you would get DS = USER_DS precisely _because_ you are in a syscall. Module init and exit are, too, just some stack frames above one and thus fall into this category as well. But shouldn't it be possible to register a timer and then print the segment registers? Timers are fired in softirq context and, hence, have no connection to user space. Regards, Tobi ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re:
Hi :) On Fri, Nov 2, 2012 at 5:46 PM, Pritam Bankar pritambankar1...@gmail.com wrote: But I have some questions, 1. How is memory split up on 64-bit architecture in this URL: http://unix.stackexchange.com/questions/32244/user-kernel-split-in-64bit-linux it says user space get 128 TiB...the rest you can read there :) 2. Can we override this 3:1 split ? sure just change PAGE_OFFSET if I remember correctly...however, the effects might be harmful, for example for certain virtualization since they assume certain address for memory allocation 3. If yes, who can do that user or kernel? kernel..for sure.. -- 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
Generating list of config options present in source tree
How can I get the list of config present in a given src snapshot? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Fwd: Memory split in 64-bit environment
On Fri, Nov 02, 2012 at 07:40:11PM +0530, Pritam Bankar wrote: On Fri, Nov 2, 2012 at 4:26 PM, Mulyadi Santosa mulyadi.sant...@gmail.com wrote: Hi :) On Fri, Nov 2, 2012 at 5:46 PM, Pritam Bankar pritambankar1...@gmail.com wrote: But I have some questions, 1. How is memory split up on 64-bit architecture in this URL: http://unix.stackexchange.com/questions/32244/user-kernel-split-in-64bit-linux it says user space get 128 TiB...the rest you can read there :) 2. Can we override this 3:1 split ? sure just change PAGE_OFFSET if I remember correctly...however, the effects might be harmful, for example for certain virtualization since they assume certain address for memory allocation 3. If yes, who can do that user or kernel? kernel..for sure.. Thanks Mulyadi. I gone through link but there is no explanation. What can be the logic behind kernel space of only 512 MB for 64-bit machines. We have 1GB kernel space in 32-bit architecture so 64-bit should ideally have much more than that. 1, that 512MB is kernel text mapping(kernel image), not kernel space. 2, kernel space under x86_64 is 128TB _now_, same as user space. 3, _now_, the split is 1:1, because address space is large enough. 4, change PAGE_OFFSET is not enough, _now_, under x86_64, PAGE_OFFSET is 0x8800, the beginning of direct mapping of all phys memory, but the beginning of kernel space is 0x8000, there is a guard hole between them. Please check https://en.wikipedia.org/wiki/X86-64, and the reasons I underline _now_ are kernel's current design and https://en.wikipedia.org/wiki/X86-64#Canonical_form_addresses PS, if you can read Chinese(hopeless), check my blog: http://adam8157.info/blog/2012/07/linux-x86-64-vm/ -- Regards, Adam Lee http://adam8157.info ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Generating list of config options present in source tree
Hi On Fri, Nov 2, 2012 at 6:45 PM, Aft nix aft...@gmail.com wrote: How can I get the list of config present in a given src snapshot? not sure if this is what you want, but why not simply use : make defconfig and check the resulting .config file? -- 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
