Why we need LDT at all in 2.2 kernels ??
Hi, In 2.2 kernel do we really need its own LDT (not default_ldt) for every process (no mm sharing) ?? In what circumstances a process may need its own LDT ?? -- Amol - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel memory leak: freeing pagetables in vmfree_area_pages in vmalloc.c
I was talking about this leak 2 days back but my mail ot lost.. we have in vfree --> vmfree_area_pages (calling) free_area_pmd (calling) free_area_pte (calling) free_page. The final free_page frees all the pages that are allocated to a memory region in vmalloc. Now where are we freeing pages that are allocated to page table themselves. For simplicity we can assume 2 level page tables (pgd == pmd) Regards Amol - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel memory leak: freeing pagetables in vmfree_area_pages in vmalloc.c
I was talking about this leak 2 days back but my mail ot lost.. we have in vfree -- vmfree_area_pages (calling) free_area_pmd (calling) free_area_pte (calling) free_page. The final free_page frees all the pages that are allocated to a memory region in vmalloc. Now where are we freeing pages that are allocated to page table themselves. For simplicity we can assume 2 level page tables (pgd == pmd) Regards Amol - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Why we need LDT at all in 2.2 kernels ??
Hi, In 2.2 kernel do we really need its own LDT (not default_ldt) for every process (no mm sharing) ?? In what circumstances a process may need its own LDT ?? -- Amol - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
freeing pagetables in vmfree_area_pages in vmalloc.c
we have in vfree --> vmfree_area_pages (calling) free_area_pmd (calling) free_area_pte (calling) free_page. The final free_page frees all the pages that are allocated to a memory region in vmalloc. Now where are we freeing pages that are allocated to page table themselves. For simplicity we can assume 2 level page tables (pgd == pmd) Regards Amol - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
freeing pagetables in vmfree_area_pages in vmalloc.c
we have in vfree -- vmfree_area_pages (calling) free_area_pmd (calling) free_area_pte (calling) free_page. The final free_page frees all the pages that are allocated to a memory region in vmalloc. Now where are we freeing pages that are allocated to page table themselves. For simplicity we can assume 2 level page tables (pgd == pmd) Regards Amol - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Buddy System bitmaps
well... I doubt whether buddy allocator would take u to a situation where pages 0 and 2 are used and 1 and 3 are free... try reading __get_free_pages in mm/page_alloc.c [EMAIL PROTECTED] on 06/15/2001 12:39:20 AM To: [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Buddy System bitmaps Hi, For this scenario consider a set of 4 page frames. Frames 0 and 2 are used while frames 1 and 3 are free. The question is would the bitmap for order 1 be a 1 or 0 for this scenario. I am not on the list so please cc me on your response. Thanks in advance. Ramil J.Santamaria Toshiba America Information Systems (949) 461-4379 (949) 206-3439 - fax [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Buddy System bitmaps
well... I doubt whether buddy allocator would take u to a situation where pages 0 and 2 are used and 1 and 3 are free... try reading __get_free_pages in mm/page_alloc.c [EMAIL PROTECTED] on 06/15/2001 12:39:20 AM To: [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Buddy System bitmaps Hi, For this scenario consider a set of 4 page frames. Frames 0 and 2 are used while frames 1 and 3 are free. The question is would the bitmap for order 1 be a 1 or 0 for this scenario. I am not on the list so please cc me on your response. Thanks in advance. Ramil J.Santamaria Toshiba America Information Systems (949) 461-4379 (949) 206-3439 - fax [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kmem_cache_init ()
Hi,
I was unable to understand the logic of the following sanity checks in
slab.c/kmem_cache_init ().
if (kmem_cache_diff(c_firstp,c_magic) != kmem_slab_diff(s_nextp,s_magic) ||
kmem_cache_diff(c_firstp,c_inuse) != kmem_slab_diff(s_nextp,s_inuse) ||
kmem_cache_offset(c_lastp) - ((unsigned long) kmem_slab_end((kmem_cache_t
*)NULL)) != kmem_slab_offset(s_prevp) || kmem_cache_diff(c_lastp,c_firstp) !=
kmem_slab_diff(s_prevp,s_nextp)) {
/** offsets to the magic are incorrect **/
}
can someone throw some light behind the above logic
Thanks
Amol
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
kmem_cache_init ()
Hi,
I was unable to understand the logic of the following sanity checks in
slab.c/kmem_cache_init ().
if (kmem_cache_diff(c_firstp,c_magic) != kmem_slab_diff(s_nextp,s_magic) ||
kmem_cache_diff(c_firstp,c_inuse) != kmem_slab_diff(s_nextp,s_inuse) ||
kmem_cache_offset(c_lastp) - ((unsigned long) kmem_slab_end((kmem_cache_t
*)NULL)) != kmem_slab_offset(s_prevp) || kmem_cache_diff(c_lastp,c_firstp) !=
kmem_slab_diff(s_prevp,s_nextp)) {
/** offsets to the magic are incorrect **/
}
can someone throw some light behind the above logic
Thanks
Amol
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Compiling kernel
Hi, The question may sound very stupid... But I have following doubt. suppose I am making some change in sched.c and now I want to build my kernel that reflects the change.. Is there any way I can avoid answering all the questions when I do make zImage ? In short how should I compile the kernel (in very small time) to see my changes. Thanks (for not flaming me) Amol - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Compiling kernel
Hi, The question may sound very stupid... But I have following doubt. suppose I am making some change in sched.c and now I want to build my kernel that reflects the change.. Is there any way I can avoid answering all the questions when I do make zImage ? In short how should I compile the kernel (in very small time) to see my changes. Thanks (for not flaming me) Amol - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel newbie question
Hi Xiong, you can get a lot of books on kernel internals... But my experience says... reading code is the best solutionall the intricacies can only be cleared when u hack the code btw a new "understanding the linux kernel" by O'reilly pub. can be helpful in 'code reading'. Amol "Xiong Zhao" <[EMAIL PROTECTED]> on 04/28/2001 01:46:34 PM To: majordomo linux kernel list <[EMAIL PROTECTED]> cc:(bcc: Amol Lad/HSS) Subject: kernel newbie question hello. i read linux kernel internal. are there other books/papers like that which dwell with linux kernel in detail,especially on process mechanism,for example,how pthread and fork are implemented, how clone actually work.are there other materials on these topics on internet that can be downloaded freely. thanks james - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Greetings!
well... the book sounds good... but... I am still thinking... what it has to do with linux kernel ?? [EMAIL PROTECTED] on 04/24/2001 04:27:56 PM To: [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Greetings! 1 in 6 children are victimized before the age of 16. Hello, my name is Jason Colgan and I am writing to you about my father's unique book on child safety. I hope you don't mind me emailing you, but I found your email address on a website that was related to children, so I figured you would definitely be interested in this. My father, a retired police Captain, authored a children's book using his unique experience with child safety. My father has investigated, arrested and taken confessions from child molesters, kidnappers, murderers and some of the most dangerous people in the world. He often spoke and interacted with them before they had the chance to speak with lawyers or others, so he was able to gain an honest understanding of the way they think and the manner in which they victimize children. My father put his 23 years of experience to work for a good cause and developed a children's book, written in a storybook fashion starring a small family of bunnies. The book has already caused quite a stir and has been featured in local newspapers and even the news. Even more important, the people who have purchased the book love it and so do their children. It truly presents a simplified way to educate your child on matters that are difficult for parents, grandparents, or guardians to discuss. I would like you to learn more about my father's book by visiting www.SafeStory.com If you are curious to see what others think, there is a link on that web site which has some customer opinions and even shows you the write-ups the book has received on Amazon.com. Thank you so much for your time and if you have any questions at all, please email me or call and I would love to answer them! My sincerest thanks, Jason http://www.SafeStory.com P.S. Please email me at [EMAIL PROTECTED] or call me anytime. My home phone number is 401-463-2856. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Delay Function
It may be possible that this is not the good choice... but u can try ... schedule_timeout(timeout) function see kernel/sched.c for more details about this function Amol Rajeev Nigam <[EMAIL PROTECTED]> on 04/24/2001 03:29:04 PM To: [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Delay Function What function i have to use to put a delay in a driver at kernel mode between reading from and writing to com port. Looking forward for ur help. Thanx & Regards Rajeev Nigam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
Hi,
I want to look into this problem. Its seems to be very interesting. But I
was not following the thread from the beginning (and I mistakely deleted all
these mails :( .. ).. I hope you won't mind answering following questions...
1) you are doing this on an MP or a uniprocessor ?
2) I want to know how are you calling sys_ptrace(Attach) and
sys_ptrace(detach).. i.e is it something linke following
for(;;){
sys_ptrace(attach to process);
sys_wait4();
sys_ptrace(detach from process);
}
In short the sequence of system calls you are using for attaching and detaching
to the process
3) Have you tried doing attach and detach only once ? If not.. can you please
try this and let me know whether by doing attach and detach one time also
results in global FPU corruption. Please do not fork in the above process.
-
Whenever process A calls sys_ptrace(Attach) to Process B, sys_ptrace sends
SIGSTOP to process B.
Now process B in do_signal, checks that it is being traced and then it does the
following
current->state = TASK_STOPPED;
notify_parent(current,SIGCHLD);
schedule();
so now in schedule() --> __switch_to --> unlazy_fpu() function we do following
if (current->flags & PF_USEDFPU)
save_fpu();
In save_fpu() we do following
fnsave current->tss.i387
fwait;
I want to ask a question... is it possible if 'somehow' we were not able to
save the complete floating point state with fnsave i.e. current->tss.i387 is
'invalid' after
fnsave current->tss.i387
fwait;
Thanks
Amol
David Konerding <[EMAIL PROTECTED]> on 04/23/2001 01:09:27 AM
To: Ulrich Drepper <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Amol Lad/HSS)
Subject: Re: BUG: Global FPU corruption in 2.2
Ulrich Drepper wrote:
> "Richard B. Johnson" <[EMAIL PROTECTED]> writes:
>
> > The kernel doesn't know if a process is going to use the FPU when
> > a new process is created. Only the user's code, i.e., the 'C' runtime
> > library knows.
>
> Maybe you should try to understand the kernel code and the features of
> the processor first. The kernel can detect when the FPU is used for
> the first time.
OK, regardless of how the linux kernel actually manages the FPU for user-space
programs, does anybody have any comments on the original bugreport?
>We have found that one of our programs can cause system-wide
>corruption of the x86 FPU under 2.2.16 and 2.2.17. That is, after we
>run this program, the FPU gives bad results to all subsequent
>processes.
>We see this problem on dual 550MHz Xeons with 1GB RAM. We have 64 of
>these things, and we see the problem on every node we try (dozens).
>We don't have other SMPs handy. Uniprocessors, including other PIIIs,
>don't seem to be affected.
>Below are two programs we use to produce the behavior. The first
>program, pi, repeatedly spawns 10 parallel computations of pi. When
>all is well, each process prints pi as it completes.
>The second program, pt, repeatedly attaches to and detaches from
>another process. Run pt against the root pi process until the output
>of pi begins to look wrong. Then kill everything and run pi by itself
>again. It will no longer produce good results. We find that the FPU
>persistently gives bad results until we reboot.
I tried this on my dual PIII-600 runnng 2.2.19 and got exactly the behavior
described.
If it is a bug in the linux kernel (I can see nothing wrong with the source
code provided),
I would suspect probems with SMP and ptrace, somehow causing the wrong FP
registers
to be returned to a process after the scheduler restarted it. It's very
interesting that the
PI program works fine until you run PT, but after you run PT, PI is screwed
until reboot.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Delay Function
Rajeev Nigam <[EMAIL PROTECTED]> on 04/24/2001 03:29:04 PM To: [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Delay Function What function i have to use to put a delay in a driver at kernel mode between reading from and writing to com port. Looking forward for ur help. Thanx & Regards Rajeev Nigam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
Hi,
I want to look into this problem. Its seems to be very interesting. But I
was not following the thread from the beginning (and I mistakely deleted all
these mails :( .. ).. I hope you won't mind answering following questions...
1) you are doing this on an MP or a uniprocessor ?
2) I want to know how are you calling sys_ptrace(Attach) and
sys_ptrace(detach).. i.e is it something linke following
for(;;){
sys_ptrace(attach to process);
sys_wait4();
sys_ptrace(detach from process);
}
In short the sequence of system calls you are using for attaching and detaching
to the process
3) Have you tried doing attach and detach only once ? If not.. can you please
try this and let me know whether by doing attach and detach one time also
results in global FPU corruption. Please do not fork in the above process.
-
Whenever process A calls sys_ptrace(Attach) to Process B, sys_ptrace sends
SIGSTOP to process B.
Now process B in do_signal, checks that it is being traced and then it does the
following
current->state = TASK_STOPPED;
notify_parent(current,SIGCHLD);
schedule();
so now in schedule() --> __switch_to --> unlazy_fpu() function we do following
if (current->flags & PF_USEDFPU)
save_fpu();
In save_fpu() we do following
fnsave current->tss.i387
fwait;
I want to ask a question... is it possible if 'somehow' we were not able to
save the complete floating point state with fnsave i.e. current->tss.i387 is
'invalid' after
fnsave current->tss.i387
fwait;
Thanks
Amol
David Konerding <[EMAIL PROTECTED]> on 04/23/2001 01:09:27 AM
To: Ulrich Drepper <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Amol Lad/HSS)
Subject: Re: BUG: Global FPU corruption in 2.2
Ulrich Drepper wrote:
> "Richard B. Johnson" <[EMAIL PROTECTED]> writes:
>
> > The kernel doesn't know if a process is going to use the FPU when
> > a new process is created. Only the user's code, i.e., the 'C' runtime
> > library knows.
>
> Maybe you should try to understand the kernel code and the features of
> the processor first. The kernel can detect when the FPU is used for
> the first time.
OK, regardless of how the linux kernel actually manages the FPU for user-space
programs, does anybody have any comments on the original bugreport?
>We have found that one of our programs can cause system-wide
>corruption of the x86 FPU under 2.2.16 and 2.2.17. That is, after we
>run this program, the FPU gives bad results to all subsequent
>processes.
>We see this problem on dual 550MHz Xeons with 1GB RAM. We have 64 of
>these things, and we see the problem on every node we try (dozens).
>We don't have other SMPs handy. Uniprocessors, including other PIIIs,
>don't seem to be affected.
>Below are two programs we use to produce the behavior. The first
>program, pi, repeatedly spawns 10 parallel computations of pi. When
>all is well, each process prints pi as it completes.
>The second program, pt, repeatedly attaches to and detaches from
>another process. Run pt against the root pi process until the output
>of pi begins to look wrong. Then kill everything and run pi by itself
>again. It will no longer produce good results. We find that the FPU
>persistently gives bad results until we reboot.
I tried this on my dual PIII-600 runnng 2.2.19 and got exactly the behavior
described.
If it is a bug in the linux kernel (I can see nothing wrong with the source
code provided),
I would suspect probems with SMP and ptrace, somehow causing the wrong FP
registers
to be returned to a process after the scheduler restarted it. It's very
interesting that the
PI program works fine until you run PT, but after you run PT, PI is screwed
until reboot.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
Hi,
I want to look into this problem. Its seems to be very interesting. But I
was not following the thread from the beginning (and I mistakely deleted all
these mails :( .. ).. I hope you won't mind answering following questions...
1) you are doing this on an MP or a uniprocessor ?
2) I want to know how are you calling sys_ptrace(Attach) and
sys_ptrace(detach).. i.e is it something linke following
for(;;){
sys_ptrace(attach to process);
sys_wait4();
sys_ptrace(detach from process);
}
In short the sequence of system calls you are using for attaching and detaching
to the process
3) Have you tried doing attach and detach only once ? If not.. can you please
try this and let me know whether by doing attach and detach one time also
results in global FPU corruption. Please do not fork in the above process.
-
Whenever process A calls sys_ptrace(Attach) to Process B, sys_ptrace sends
SIGSTOP to process B.
Now process B in do_signal, checks that it is being traced and then it does the
following
current-state = TASK_STOPPED;
notify_parent(current,SIGCHLD);
schedule();
so now in schedule() -- __switch_to -- unlazy_fpu() function we do following
if (current-flags PF_USEDFPU)
save_fpu();
In save_fpu() we do following
fnsave current-tss.i387
fwait;
I want to ask a question... is it possible if 'somehow' we were not able to
save the complete floating point state with fnsave i.e. current-tss.i387 is
'invalid' after
fnsave current-tss.i387
fwait;
Thanks
Amol
David Konerding [EMAIL PROTECTED] on 04/23/2001 01:09:27 AM
To: Ulrich Drepper [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Amol Lad/HSS)
Subject: Re: BUG: Global FPU corruption in 2.2
Ulrich Drepper wrote:
Richard B. Johnson [EMAIL PROTECTED] writes:
The kernel doesn't know if a process is going to use the FPU when
a new process is created. Only the user's code, i.e., the 'C' runtime
library knows.
Maybe you should try to understand the kernel code and the features of
the processor first. The kernel can detect when the FPU is used for
the first time.
OK, regardless of how the linux kernel actually manages the FPU for user-space
programs, does anybody have any comments on the original bugreport?
We have found that one of our programs can cause system-wide
corruption of the x86 FPU under 2.2.16 and 2.2.17. That is, after we
run this program, the FPU gives bad results to all subsequent
processes.
We see this problem on dual 550MHz Xeons with 1GB RAM. We have 64 of
these things, and we see the problem on every node we try (dozens).
We don't have other SMPs handy. Uniprocessors, including other PIIIs,
don't seem to be affected.
Below are two programs we use to produce the behavior. The first
program, pi, repeatedly spawns 10 parallel computations of pi. When
all is well, each process prints pi as it completes.
The second program, pt, repeatedly attaches to and detaches from
another process. Run pt against the root pi process until the output
of pi begins to look wrong. Then kill everything and run pi by itself
again. It will no longer produce good results. We find that the FPU
persistently gives bad results until we reboot.
I tried this on my dual PIII-600 runnng 2.2.19 and got exactly the behavior
described.
If it is a bug in the linux kernel (I can see nothing wrong with the source
code provided),
I would suspect probems with SMP and ptrace, somehow causing the wrong FP
registers
to be returned to a process after the scheduler restarted it. It's very
interesting that the
PI program works fine until you run PT, but after you run PT, PI is screwed
until reboot.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Delay Function
Rajeev Nigam [EMAIL PROTECTED] on 04/24/2001 03:29:04 PM To: [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Delay Function What function i have to use to put a delay in a driver at kernel mode between reading from and writing to com port. Looking forward for ur help. Thanx Regards Rajeev Nigam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Delay Function
It may be possible that this is not the good choice... but u can try ... schedule_timeout(timeout) function see kernel/sched.c for more details about this function Amol Rajeev Nigam [EMAIL PROTECTED] on 04/24/2001 03:29:04 PM To: [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Delay Function What function i have to use to put a delay in a driver at kernel mode between reading from and writing to com port. Looking forward for ur help. Thanx Regards Rajeev Nigam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
Hi,
I want to look into this problem. Its seems to be very interesting. But I
was not following the thread from the beginning (and I mistakely deleted all
these mails :( .. ).. I hope you won't mind answering following questions...
1) you are doing this on an MP or a uniprocessor ?
2) I want to know how are you calling sys_ptrace(Attach) and
sys_ptrace(detach).. i.e is it something linke following
for(;;){
sys_ptrace(attach to process);
sys_wait4();
sys_ptrace(detach from process);
}
In short the sequence of system calls you are using for attaching and detaching
to the process
3) Have you tried doing attach and detach only once ? If not.. can you please
try this and let me know whether by doing attach and detach one time also
results in global FPU corruption. Please do not fork in the above process.
-
Whenever process A calls sys_ptrace(Attach) to Process B, sys_ptrace sends
SIGSTOP to process B.
Now process B in do_signal, checks that it is being traced and then it does the
following
current-state = TASK_STOPPED;
notify_parent(current,SIGCHLD);
schedule();
so now in schedule() -- __switch_to -- unlazy_fpu() function we do following
if (current-flags PF_USEDFPU)
save_fpu();
In save_fpu() we do following
fnsave current-tss.i387
fwait;
I want to ask a question... is it possible if 'somehow' we were not able to
save the complete floating point state with fnsave i.e. current-tss.i387 is
'invalid' after
fnsave current-tss.i387
fwait;
Thanks
Amol
David Konerding [EMAIL PROTECTED] on 04/23/2001 01:09:27 AM
To: Ulrich Drepper [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Amol Lad/HSS)
Subject: Re: BUG: Global FPU corruption in 2.2
Ulrich Drepper wrote:
Richard B. Johnson [EMAIL PROTECTED] writes:
The kernel doesn't know if a process is going to use the FPU when
a new process is created. Only the user's code, i.e., the 'C' runtime
library knows.
Maybe you should try to understand the kernel code and the features of
the processor first. The kernel can detect when the FPU is used for
the first time.
OK, regardless of how the linux kernel actually manages the FPU for user-space
programs, does anybody have any comments on the original bugreport?
We have found that one of our programs can cause system-wide
corruption of the x86 FPU under 2.2.16 and 2.2.17. That is, after we
run this program, the FPU gives bad results to all subsequent
processes.
We see this problem on dual 550MHz Xeons with 1GB RAM. We have 64 of
these things, and we see the problem on every node we try (dozens).
We don't have other SMPs handy. Uniprocessors, including other PIIIs,
don't seem to be affected.
Below are two programs we use to produce the behavior. The first
program, pi, repeatedly spawns 10 parallel computations of pi. When
all is well, each process prints pi as it completes.
The second program, pt, repeatedly attaches to and detaches from
another process. Run pt against the root pi process until the output
of pi begins to look wrong. Then kill everything and run pi by itself
again. It will no longer produce good results. We find that the FPU
persistently gives bad results until we reboot.
I tried this on my dual PIII-600 runnng 2.2.19 and got exactly the behavior
described.
If it is a bug in the linux kernel (I can see nothing wrong with the source
code provided),
I would suspect probems with SMP and ptrace, somehow causing the wrong FP
registers
to be returned to a process after the scheduler restarted it. It's very
interesting that the
PI program works fine until you run PT, but after you run PT, PI is screwed
until reboot.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Greetings!
well... the book sounds good... but... I am still thinking... what it has to do with linux kernel ?? [EMAIL PROTECTED] on 04/24/2001 04:27:56 PM To: [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Greetings! 1 in 6 children are victimized before the age of 16. Hello, my name is Jason Colgan and I am writing to you about my father's unique book on child safety. I hope you don't mind me emailing you, but I found your email address on a website that was related to children, so I figured you would definitely be interested in this. My father, a retired police Captain, authored a children's book using his unique experience with child safety. My father has investigated, arrested and taken confessions from child molesters, kidnappers, murderers and some of the most dangerous people in the world. He often spoke and interacted with them before they had the chance to speak with lawyers or others, so he was able to gain an honest understanding of the way they think and the manner in which they victimize children. My father put his 23 years of experience to work for a good cause and developed a children's book, written in a storybook fashion starring a small family of bunnies. The book has already caused quite a stir and has been featured in local newspapers and even the news. Even more important, the people who have purchased the book love it and so do their children. It truly presents a simplified way to educate your child on matters that are difficult for parents, grandparents, or guardians to discuss. I would like you to learn more about my father's book by visiting www.SafeStory.com If you are curious to see what others think, there is a link on that web site which has some customer opinions and even shows you the write-ups the book has received on Amazon.com. Thank you so much for your time and if you have any questions at all, please email me or call and I would love to answer them! My sincerest thanks, Jason http://www.SafeStory.com P.S. Please email me at [EMAIL PROTECTED] or call me anytime. My home phone number is 401-463-2856. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
Erik Paulson <[EMAIL PROTECTED]> on 04/24/2001 01:14:27 AM To: Christian Ehrhardt <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Amol Lad/HSS) Subject: Re: BUG: Global FPU corruption in 2.2 On 23 Apr 2001 18:11:48 +0200, Christian Ehrhardt wrote: > On Thu, Apr 19, 2001 at 11:05:03AM -0500, Victor Zandy wrote: > > > > We have found that one of our programs can cause system-wide > > corruption of the x86 FPU under 2.2.16 and 2.2.17. That is, after we > > run this program, the FPU gives bad results to all subsequent > > processes. > <...> > > 3.) It might be interesting to know if the problem can be triggered: > a) If pi doesn't fork, i.e. just one process calculating pi and > another one doing the attach/detach. Yes, we are still able to reproduce it without calling fork (the new program just calls do_pi() a bunch of times, and then we attach and detach to that process) > b) If pi doesn't do FPU Operations, i.e. only the children call do_pi. > You seem to need to attach and detach to a program using the fpu - running pt on a process that is just busy-looping over and over some integer adds does not seem to while running pi on the machine at the same time, but not attaching to it does not seem to affect the floating point state. well... during context switching.. call to unlazy_fpu() does the following if (current->flags & PF_USEDFPU) save_fpu(); somebody earlier pointed out, for the possible race when in sys_ptrace, at the time of attach we modify child->flags. It really looks again strange that it is software that is causing the problem as the code to handle FPU looks pretty clean. still can we check current->flags when the problem occurs ? Amol -Erik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Test mail.. pls ignore & delete
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
xtime.tv_usec update in timer interrupt
Hi, In update_wall_one_tick() function, we have following xtime.tv_usec += tick + time_adjust_step. where tick = (100 + hz/2)/hz. In systems where we have TSC why we cannot use that to update xtime.tv_usec. It should give better time estimate. and the values that are retured in sys_gettimeofday would also be more accurate . Amol - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
xtime.tv_usec update in timer interrupt
Hi, In update_wall_one_tick() function, we have following xtime.tv_usec += tick + time_adjust_step. where tick = (100 + hz/2)/hz. In systems where we have TSC why we cannot use that to update xtime.tv_usec. It should give better time estimate. and the values that are retured in sys_gettimeofday would also be more accurate . Amol - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Test mail.. pls ignore delete
- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
Erik Paulson [EMAIL PROTECTED] on 04/24/2001 01:14:27 AM To: Christian Ehrhardt [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Amol Lad/HSS) Subject: Re: BUG: Global FPU corruption in 2.2 On 23 Apr 2001 18:11:48 +0200, Christian Ehrhardt wrote: On Thu, Apr 19, 2001 at 11:05:03AM -0500, Victor Zandy wrote: We have found that one of our programs can cause system-wide corruption of the x86 FPU under 2.2.16 and 2.2.17. That is, after we run this program, the FPU gives bad results to all subsequent processes. ... 3.) It might be interesting to know if the problem can be triggered: a) If pi doesn't fork, i.e. just one process calculating pi and another one doing the attach/detach. Yes, we are still able to reproduce it without calling fork (the new program just calls do_pi() a bunch of times, and then we attach and detach to that process) b) If pi doesn't do FPU Operations, i.e. only the children call do_pi. You seem to need to attach and detach to a program using the fpu - running pt on a process that is just busy-looping over and over some integer adds does not seem to while running pi on the machine at the same time, but not attaching to it does not seem to affect the floating point state. well... during context switching.. call to unlazy_fpu() does the following if (current-flags PF_USEDFPU) save_fpu(); somebody earlier pointed out, for the possible race when in sys_ptrace, at the time of attach we modify child-flags. It really looks again strange that it is software that is causing the problem as the code to handle FPU looks pretty clean. still can we check current-flags when the problem occurs ? Amol -Erik - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Kurt Roeckx <[EMAIL PROTECTED]> on 04/11/2001 06:16:52 AM
To: Miquel van Smoorenburg <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED] (bcc: Amol Lad/HSS)
Subject: Re: Let init know user wants to shutdown
On Wed, Apr 11, 2001 at 01:38:30AM +0200, Kurt Roeckx wrote:
> On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
> >
> > the shutdown scripts
> > include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> > "all processes except me". That means init will get hit with
> > SIGTERM occasionally during shutdown, and that might cause
> > weird things to happen.
>
> -1 mean everything but init.
>>> well. don't fight.. here is something from kernel/signal.c
asmlinkage int sys_kill(int pid, int sig){
...
...
return kill_something_info(sig,,pid)
}
int
kill_something_info(int sig, struct siginfo *info, int pid){
...
...
...
if (pid == -1){
for_each_task(p){(int
if (p->pid >1 && p != current){
err = send_sig_info(sig,info,p);
...
...
}
}
}
Amol
Oh, maybe you mean killall5 -TERM?
Which would send a SIGTERM to all processes but the one in his
own session.
(Hey look, you wrote that manpage.)
Kurt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Kurt Roeckx [EMAIL PROTECTED] on 04/11/2001 06:16:52 AM
To: Miquel van Smoorenburg [EMAIL PROTECTED]
cc: [EMAIL PROTECTED] (bcc: Amol Lad/HSS)
Subject: Re: Let init know user wants to shutdown
On Wed, Apr 11, 2001 at 01:38:30AM +0200, Kurt Roeckx wrote:
On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
the shutdown scripts
include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
"all processes except me". That means init will get hit with
SIGTERM occasionally during shutdown, and that might cause
weird things to happen.
-1 mean everything but init.
well. don't fight.. here is something from kernel/signal.c
asmlinkage int sys_kill(int pid, int sig){
...
...
return kill_something_info(sig,info,pid)
}
int
kill_something_info(int sig, struct siginfo *info, int pid){
...
...
...
if (pid == -1){
for_each_task(p){(int
if (p-pid 1 p != current){
err = send_sig_info(sig,info,p);
...
...
}
}
}
Amol
Oh, maybe you mean killall5 -TERM?
Which would send a SIGTERM to all processes but the one in his
own session.
(Hey look, you wrote that manpage.)
Kurt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: __switch_to macro
Jamie Lokier <[EMAIL PROTECTED]> on 04/06/2001 03:18:13 PM
To: Amol Lad/HSS@HSS
cc: [EMAIL PROTECTED]
Subject: Re: __switch_to macro
[EMAIL PROTECTED] wrote:
> 1) What exactly is meant by ' stale segment register values' in the note.
> 2) In the above macro, I think we recover gracefully from error
>condition while recovering fs and gs segment registers . The
>loadsegment(fs,next->tss.fs) and loadsegment(gs,next->tss.gs) does
>it. I am not able to understand loadsegment macro. The macro is as under
>
> /** Load a segment. Fall back on loading a zero segment if something goes
wrong
> **/
> #define loadsegment(seg,value) \
> asm volatile("\n" \
> "1:\t" \
> "movl %0,%%" #seg "\n" \
> "2:\n" \
> "3:\t" \
> "pushl $0\n\t" \
> "jmp 2b\n" \
> ".previous\n"\
> ".section __ex_table,\"a\"\n\t \
> "/align 4\n\t" \
> ".long 1b,3b\n" \
> ".previous" \
> : :"m" (*(unsigned int *)&(value)))
>
> I also want to know what is 'something' in the comment above the macro
The answers to 1. and 'something' are the same: stale segment values.
You can't load any value into %ss, %ds, %es, %fs or %gs. They must be
valid references into the GDT or LDT, with the appropriote protection
level, or 0.
Usually the values stored in tss are ok, as they were valid values when
they were stored. However for programs that use modify_ldt, it's
possible for a valid LDT entry to be made invalid while some tss still
refers to that segment.
>>> Thanks a lot.. good explanation..
At the next attempt to load the segment value into a segment register,
you get a fault. The code in loadsegment traps this fault and loads
zero into the segment register instead when this happens. Zero is
always allowed. If the user program then tries to access data
referenced by that segment register, user space will get a
general_protection fault. As it's only user space that calls modify_ldt
to invalidate an LDT entry, that's reasonable.
There's one thing that confuses me: don't you get a segment_not_present
fault? If so, traps.c's do_segment_not_present doesn't appear to search
the exception table, and the code in loadsegment would not work.
>>> well.. I peeked into traps.c.. I do seem a call to die_if_no_fixup
in this function. And I think loadsegment is already making an entry in
exception table.
Amol
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
__switch_to macro
Hi,
The note above __switch_to macro in i386/kernel/process.c says that we no
more use hardware context switching as some problems in recovering from
saved state that is no longer valid. (I am peeking into 2.2 kernel). Now I have
following questions
1) What exactly is meant by ' stale segment register values' in the note.
2) In the above macro, I think we recover gracefully from error condition while
recovering fs and gs segment registers . The loadsegment(fs,next->tss.fs) and
loadsegment(gs,next->tss.gs) does it. I am not able to understand loadsegment
macro. The macro is as under
/** Load a segment. Fall back on loading a zero segment if something goes wrong
**/
#define loadsegment(seg,value) \
asm volatile("\n" \
"1:\t" \
"movl %0,%%" #seg "\n" \
"2:\n" \
"3:\t" \
"pushl $0\n\t" \
"jmp 2b\n" \
".previous\n"\
".section __ex_table,\"a\"\n\t \
"/align 4\n\t" \
".long 1b,3b\n" \
".previous" \
: :"m" (*(unsigned int *)&(value)))
I also want to know what is 'something' in the comment above the macro
Thanks in advance
Amol
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
__switch_to macro
Hi,
The note above __switch_to macro in i386/kernel/process.c says that we no
more use hardware context switching as some problems in recovering from
saved state that is no longer valid. (I am peeking into 2.2 kernel). Now I have
following questions
1) What exactly is meant by ' stale segment register values' in the note.
2) In the above macro, I think we recover gracefully from error condition while
recovering fs and gs segment registers . The loadsegment(fs,next-tss.fs) and
loadsegment(gs,next-tss.gs) does it. I am not able to understand loadsegment
macro. The macro is as under
/** Load a segment. Fall back on loading a zero segment if something goes wrong
**/
#define loadsegment(seg,value) \
asm volatile("\n" \
"1:\t" \
"movl %0,%%" #seg "\n" \
"2:\n" \
"3:\t" \
"pushl $0\n\t" \
"jmp 2b\n" \
".previous\n"\
".section __ex_table,\"a\"\n\t \
"/align 4\n\t" \
".long 1b,3b\n" \
".previous" \
: :"m" (*(unsigned int *)(value)))
I also want to know what is 'something' in the comment above the macro
Thanks in advance
Amol
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: __switch_to macro
Jamie Lokier [EMAIL PROTECTED] on 04/06/2001 03:18:13 PM
To: Amol Lad/HSS@HSS
cc: [EMAIL PROTECTED]
Subject: Re: __switch_to macro
[EMAIL PROTECTED] wrote:
1) What exactly is meant by ' stale segment register values' in the note.
2) In the above macro, I think we recover gracefully from error
condition while recovering fs and gs segment registers . The
loadsegment(fs,next-tss.fs) and loadsegment(gs,next-tss.gs) does
it. I am not able to understand loadsegment macro. The macro is as under
/** Load a segment. Fall back on loading a zero segment if something goes
wrong
**/
#define loadsegment(seg,value) \
asm volatile("\n" \
"1:\t" \
"movl %0,%%" #seg "\n" \
"2:\n" \
"3:\t" \
"pushl $0\n\t" \
"jmp 2b\n" \
".previous\n"\
".section __ex_table,\"a\"\n\t \
"/align 4\n\t" \
".long 1b,3b\n" \
".previous" \
: :"m" (*(unsigned int *)(value)))
I also want to know what is 'something' in the comment above the macro
The answers to 1. and 'something' are the same: stale segment values.
You can't load any value into %ss, %ds, %es, %fs or %gs. They must be
valid references into the GDT or LDT, with the appropriote protection
level, or 0.
Usually the values stored in tss are ok, as they were valid values when
they were stored. However for programs that use modify_ldt, it's
possible for a valid LDT entry to be made invalid while some tss still
refers to that segment.
Thanks a lot.. good explanation..
At the next attempt to load the segment value into a segment register,
you get a fault. The code in loadsegment traps this fault and loads
zero into the segment register instead when this happens. Zero is
always allowed. If the user program then tries to access data
referenced by that segment register, user space will get a
general_protection fault. As it's only user space that calls modify_ldt
to invalidate an LDT entry, that's reasonable.
There's one thing that confuses me: don't you get a segment_not_present
fault? If so, traps.c's do_segment_not_present doesn't appear to search
the exception table, and the code in loadsegment would not work.
well.. I peeked into traps.c.. I do seem a call to die_if_no_fixup
in this function. And I think loadsegment is already making an entry in
exception table.
Amol
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: a quest for a better scheduler
This concept I think is used in Solaris .. as they have dynamic loadable schedulers.. Zdenek Kabelac <[EMAIL PROTECTED]> on 04/05/2001 05:43:15 PM To: Andrea Arcangeli <[EMAIL PROTECTED]> cc:(bcc: Amol Lad/HSS) Subject: Re: [Lse-tech] Re: a quest for a better scheduler Hello Just dump idea - why not make scheduler switchable with modules - so users could select any scheduler they want ? This should not be that hard and would make it easy to replace scheduler at runtime so everyone could easily try what's the best for him/her. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: random PIDs
"Heusden, Folkert van" <[EMAIL PROTECTED]> on 04/05/2001 03:45:13 PM To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Amol Lad/HSS) Subject: RE: random PIDs > Finished & tested my random PID kernel/fork.c:get_pid() replacement. > > This one keeps track of the last N (default is 64) pids who have exited. > > These are then not used. So, one cannot have more then 32767 - (64 + 1 > > (init) + 1 (idle)) = 32761 processes :o) > DW> Huh, should be 32701, right?! > You're absolutely right. It must've been the victory trance :o) M> Have you actually tried to create lots of threads? No M> IIRC get_pid will loop forever if it doesn't find a free pid, and in the M> worst case you can trigger that with ~11000 running threads. Ah, ok. But why would you have 11.000 running threads? M> And the current code can create multiple threads with the same pid (I M> never tried to trigger that bug, but it seems to be possible) mine will do that too: if (flags & CLONE_PID) return current->pid; As far as my knowledge reaches, threads are cloned which triggers the code I quoted above. cloning of threads never means that all the clome flags are set.. AFAIK CLONE_PID flag is used only by swpapper process (pid- 0) during boot-up and then never used again - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Release naming conventions
well..don't fire me for asking such a stupid question... I am new to linux kernel world... I want to know the release naming conventions in linux.. I know the following... 2.1.xx --> means developmet release 2.2.xx --> means stable release... Now what 2.2.xx-pre6 or 2.2.xx-ac3 means ?? Amol - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: random PIDs
"Heusden, Folkert van" [EMAIL PROTECTED] on 04/05/2001 03:45:13 PM To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Amol Lad/HSS) Subject: RE: random PIDs Finished tested my random PID kernel/fork.c:get_pid() replacement. This one keeps track of the last N (default is 64) pids who have exited. These are then not used. So, one cannot have more then 32767 - (64 + 1 (init) + 1 (idle)) = 32761 processes :o) DW Huh, should be 32701, right?! You're absolutely right. It must've been the victory trance :o) M Have you actually tried to create lots of threads? No M IIRC get_pid will loop forever if it doesn't find a free pid, and in the M worst case you can trigger that with ~11000 running threads. Ah, ok. But why would you have 11.000 running threads? M And the current code can create multiple threads with the same pid (I M never tried to trigger that bug, but it seems to be possible) mine will do that too: if (flags CLONE_PID) return current-pid; As far as my knowledge reaches, threads are cloned which triggers the code I quoted above. cloning of threads never means that all the clome flags are set.. AFAIK CLONE_PID flag is used only by swpapper process (pid- 0) during boot-up and then never used again - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: a quest for a better scheduler
This concept I think is used in Solaris .. as they have dynamic loadable schedulers.. Zdenek Kabelac [EMAIL PROTECTED] on 04/05/2001 05:43:15 PM To: Andrea Arcangeli [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Re: [Lse-tech] Re: a quest for a better scheduler Hello Just dump idea - why not make scheduler switchable with modules - so users could select any scheduler they want ? This should not be that hard and would make it easy to replace scheduler at runtime so everyone could easily try what's the best for him/her. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
get_pid() : enahancement
In 2.4 kernel we now have no limit on the number of tasks running on a system (no NR_TASKS anymore)... I was just wondering on the efficiency of get_pid() implemetation... Although 'next_safe' concept in this function seems useful but I think we now need a robust PID allocator.. We can have a discussion so that get_pid() can be made more effecient in future kernel. Amol - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a quest for a better scheduler
If we are facing these problems for "normal case" then hope the Solaris is handling it !! Amol Fabio Riccardi <[EMAIL PROTECTED]> on 04/04/2001 07:03:57 AM To: Alan Cox <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] (bcc: Amol Lad/HSS) Subject: Re: a quest for a better scheduler Alan, for the "normal case" performance see my other message. I agree that a better threading model would surely help in a web server, but to me this is not an excuse to live up with a broken scheduler. The X15 server I'm working on now is a sort of user-space TUX, it uses only 8 threads per CPU and it achieves the same level of performance of the kernel space TUX. Even in this case the performance advantage of the multiqueue scheduler is remarkable, especially on a multi-CPU (> 2) architecture. To achieve some decent disk/CPU/network overlapping with the current linux blocking disk IO limitations there is no way to avoid a "bunch of server threads". I've (experimentally) figured out that 8-16 threads per CPU can assure some reasonable overlapping, depending on the memory size and disk subsystem speed. On a 8-way machine this means 64-128 active tasks, a total disaster with the current scheduler. Unless we want to maintain the position tha the only way to achieve good performance is to embed server applications in the kernel, some minimal help should be provided to goodwilling user applications :) TIA, ciao, - Fabio Alan Cox wrote: > > Is there any special reason why any of those patches didn't make it to > > the mainstream kernel code? > > All of them are worse for the normal case. Also 1500 running apache's isnt > a remotely useful situation, you are thrashing the cache even if you are now > not thrashing the scheduler. Use an httpd designed for that situation. Then > you can also downgrade to a cheap pentium class box for the task ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a quest for a better scheduler
If we are facing these problems for "normal case" then hope the Solaris is handling it !! Amol Fabio Riccardi [EMAIL PROTECTED] on 04/04/2001 07:03:57 AM To: Alan Cox [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Amol Lad/HSS) Subject: Re: a quest for a better scheduler Alan, for the "normal case" performance see my other message. I agree that a better threading model would surely help in a web server, but to me this is not an excuse to live up with a broken scheduler. The X15 server I'm working on now is a sort of user-space TUX, it uses only 8 threads per CPU and it achieves the same level of performance of the kernel space TUX. Even in this case the performance advantage of the multiqueue scheduler is remarkable, especially on a multi-CPU ( 2) architecture. To achieve some decent disk/CPU/network overlapping with the current linux blocking disk IO limitations there is no way to avoid a "bunch of server threads". I've (experimentally) figured out that 8-16 threads per CPU can assure some reasonable overlapping, depending on the memory size and disk subsystem speed. On a 8-way machine this means 64-128 active tasks, a total disaster with the current scheduler. Unless we want to maintain the position tha the only way to achieve good performance is to embed server applications in the kernel, some minimal help should be provided to goodwilling user applications :) TIA, ciao, - Fabio Alan Cox wrote: Is there any special reason why any of those patches didn't make it to the mainstream kernel code? All of them are worse for the normal case. Also 1500 running apache's isnt a remotely useful situation, you are thrashing the cache even if you are now not thrashing the scheduler. Use an httpd designed for that situation. Then you can also downgrade to a cheap pentium class box for the task ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
get_pid() : enahancement
In 2.4 kernel we now have no limit on the number of tasks running on a system (no NR_TASKS anymore)... I was just wondering on the efficiency of get_pid() implemetation... Although 'next_safe' concept in this function seems useful but I think we now need a robust PID allocator.. We can have a discussion so that get_pid() can be made more effecient in future kernel. Amol - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
