Re: [osol-discuss] kernel threads
Hi, ramana polamarasetti wrote: On Fri, 25 Jan 2008, ramana polamarasetti wrote: Hi, Can anyone tell me what are all the differences between the threads created with thread_create() and those created with lwp_create()? And is there any way to get an lwp, but using thread_create()? Thanks for any help, Ramana Where do you want to create threads ? In you application ? In a kernel driver of yours ? In my kernel module. If the former, i.e. you want to use threads in your application, then you're way along the wrong path, check thr_create() resp. pthread_create() instead. If the latter, i.e. you want to create a thread from within your kernel driver, then please consider first whether other asynchronous mechanisms (taskq or timeout) would do instead. The use of threads breaks power management interfaces, and creates difficult-to-deal-with races on driver unloading. In any case, if you have to it's thread_create(). Calling lwp_create from a kernel driver will get you into trouble. Why would you want to create an LWP from within a kernel driver ? My present code uses thread_create(). I am seeing kernel panics due to an ASSERT fail in the sfmmu_tsbmiss_exception(). If you're looking for something entirely different, the way how to find out which LWP is executing your kernel driver code, use: klwp_t *curlwp = ttolwp(threadp()); Can you clarify what you want to achieve ? If I do this in my thread, I am getting curlwp as NULL. because there is no LWP created when I do a thread_create(). And this sfmmu_tsbmiss_exception() is doing the same thing. 11824 /* 11825 * Must set lwp state to LWP_SYS before 11826 * trying to acquire any adaptive lock 11827 */ 11828 lwp = ttolwp(curthread); 11829 ASSERT(lwp); // this is causing kernel panic So, to avoid this I was just trying to see if it is possible to use lwp_create(). Creating a kernel thread does not imply that a klwp_t is created. What information from an lwp do you need? If there is no user level, you should not need an lwp. So, why do you think you need one? max thanks, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org Thanks for the reply. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel threads
On Mon, 28 Jan 2008, [EMAIL PROTECTED] wrote: Hi, [ ... ] Calling lwp_create from a kernel driver will get you into trouble. Why would you want to create an LWP from within a kernel driver ? My present code uses thread_create(). I am seeing kernel panics due to an ASSERT fail in the sfmmu_tsbmiss_exception(). And why do you think that would have anything to do with each other ? If you're looking for something entirely different, the way how to find out which LWP is executing your kernel driver code, use: klwp_t *curlwp = ttolwp(threadp()); Can you clarify what you want to achieve ? If I do this in my thread, I am getting curlwp as NULL. because there is no LWP created when I do a thread_create(). And this sfmmu_tsbmiss_exception() is doing the same thing. 11824 /* 11825 * Must set lwp state to LWP_SYS before 11826 * trying to acquire any adaptive lock 11827 */ Can you explain that sourcecode comment ? It's wrong, but why you think this should be so might give more insight as to what your expectations actually are ? 11828 lwp = ttolwp(curthread); 11829 ASSERT(lwp); // this is causing kernel panic And what is unusual by that ? Not every thread has an LWP, it's pretty normal to see ttolwp(curthread) being NULL. The only thing that tells you is that the currently running thread is not part of any userland process but has been created by the kernel itself, or by some kernel driver. So, to avoid this I was just trying to see if it is possible to use lwp_create(). Creating a kernel thread does not imply that a klwp_t is created. What information from an lwp do you need? If there is no user level, you should not need an lwp. So, why do you think you need one? Seconding Max here - why do you think you need one ? Thx, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel threads
On Mon, 28 Jan 2008, [EMAIL PROTECTED] wrote: [ ... ] My present code uses thread_create(). I am seeing kernel panics due to an ASSERT fail in the sfmmu_tsbmiss_exception(). Can you please post the part of the output of ::msgbuf (from mdb on your crashdump) following the panic[cpu...] line ? I do think you're running way down the wrong track there. You get a trap because of an invalid pointer, that the trap handling mechanism doesn't tell you that clearly but fails somewhere else is more than likely just an artifact. The _real_ meat is elsewhere. when you do crashdump analysis, don't always focus only on the topmost function in a stacktrace. There's more to it than that and the bug you try to track down fix isn't necessarily at the very place where things fall over. Are you willing to share that crashdump with the community ? Thx, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel threads
Hi Frank, I think you meant to send this to Ramana, not me... max [EMAIL PROTECTED] wrote: On Mon, 28 Jan 2008, [EMAIL PROTECTED] wrote: [ ... ] My present code uses thread_create(). I am seeing kernel panics due to an ASSERT fail in the sfmmu_tsbmiss_exception(). Can you please post the part of the output of ::msgbuf (from mdb on your crashdump) following the panic[cpu...] line ? I do think you're running way down the wrong track there. You get a trap because of an invalid pointer, that the trap handling mechanism doesn't tell you that clearly but fails somewhere else is more than likely just an artifact. The _real_ meat is elsewhere. when you do crashdump analysis, don't always focus only on the topmost function in a stacktrace. There's more to it than that and the bug you try to track down fix isn't necessarily at the very place where things fall over. Are you willing to share that crashdump with the community ? Thx, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel threads
On Mon, 28 Jan 2008, [EMAIL PROTECTED] wrote: [ ... ] My present code uses thread_create(). I am seeing kernel panics due to an ASSERT fail in the sfmmu_tsbmiss_exception(). Can you please post the part of the output of ::msgbuf (from mdb on your crashdump) following the panic[cpu...] line ? panic[cpu0]/thread=2a108169cc0: BAD TRAP: type=31 rp=2a1081693a0 addr=349 mmu_fsr=0 occurred in module unix du e to a NULL pointer dereference updisk: trap type = 0x31 addr=0x349 pid=984, pc=0x1034db8, sp=0x2a108168c41, tstate=0x441601, context=0x1 g1-g7: 60016022090, 2a108169cc0, 42f90, 8, 121c574, 0, 2a108169cc0 02a1081690c0 unix:die+78 (31, 2a1081693a0, 349, 0, 2a108169180, 108dc00) %l0-3: 0031 0100 2000 %l4-7: 0182d0f0 0182d000 0005 0001 02a1081691a0 unix:trap+9d8 (2a1081693a0, 0, 5, 1c00, 0, 1) %l0-3: 060016022090 0031 %l4-7: e000 004325ca 0005 0001 02a1081692f0 unix:ktl0+64 (60008b5cb64, 42f98, 1, fff8, 7331b, 1 ) %l0-3: 0180c000 00441601 0101e3a8 %l4-7: 0300014c3e40 004325ca 02a1081693a0 02a108169440 genunix:uiomove+90 (2a1081695a0, 42001, 31, 0, 43254b, 60015481 0c8) %l0-3: 0180c000 0001 1c00 %l4-7: 0300014c3e40 004325ca 0002 0180c000 02a1081694f0 unix:ktl0+64 (60008b5cb64, 42f98, 1, fff8, 7331b, 1 ) %l0-3: 0180c000 80001607 01034d64 %l4-7: 0008 02a108169940 02a1081695a0 02a108169640 genunix:uiomove+90 (60008b5cb5c, 8, 0, 2a108169950, 0, 8) %l0-3: 02a108169960 02a108169950 0002 8000 %l4-7: 0008 02a108169940 02a108169950 060008b5cb64 02a1081696f0 genunix:struiocopyout+38 (60003b53080, 2a108169950, 2a108169864 , 0, 60008b5cb64, 1) %l0-3: 030015d9bd18 030015d9bc98 0002 8000 %l4-7: 0008 0008 02a108169950 060008b5cb64 02a1081697a0 genunix:strread+4b4 (0, 2a108169950, 0, 30017460860, 0, 0) %l0-3: 030015d9bd18 030015d9bc98 0002 8000 %l4-7: 060003b53080 02a108169870 ipfs:ipfs_in+1e8 (0, 3001bba0940, 30017460860, 8, 2a108169ab0, 0) %l0-3: 018ec400 030015d9bc98 060005e8 %l4-7: 060005e80068 0008 0600153ad4e0 02a108169990 ipfs:ipfs_active_in+ec (60005e8, 3001bba0940, 60016dc0400, 600153a, 0, 60005e800d8) %l0-3: 0600153ad120 704a5400 %l4-7: 060005e80068 060005e8 0600153ad4e0 I do think you're running way down the wrong track there. You get a trap because of an invalid pointer, that the trap handling mechanism doesn't tell you that clearly but fails somewhere else is more than likely just an artifact. The _real_ meat is elsewhere. when you do crashdump analysis, don't always focus only on the topmost function in a stacktrace. There's more to it than that and the bug you try to track down fix isn't necessarily at the very place where things fall over. Are you willing to share that crashdump with the community ? I dont think you would like this, Its from Solaris 10 not OpenSolaris. Thx, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel threads
On Mon, 28 Jan 2008, [EMAIL PROTECTED] wrote: Hi, [ ... ] Calling lwp_create from a kernel driver will get you into trouble. Why would you want to create an LWP from within a kernel driver ? My present code uses thread_create(). I am seeing kernel panics due to an ASSERT fail in the sfmmu_tsbmiss_exception(). And why do you think that would have anything to do with each other ? If you're looking for something entirely different, the way how to find out which LWP is executing your kernel driver code, use: klwp_t *curlwp = ttolwp(threadp()); Can you clarify what you want to achieve ? If I do this in my thread, I am getting curlwp as NULL. because there is no LWP created when I do a thread_create(). And this sfmmu_tsbmiss_exception() is doing the same thing. 11824 /* 11825* Must set lwp state to LWP_SYS before 11826* trying to acquire any adaptive lock 11827*/ Can you explain that sourcecode comment ? It's wrong, but why you think this should be so might give more insight as to what your expectations actually are ? This comment is from /usr/src/uts/sfmmu/vm/hat_sfmmu.c . My intention is just to create a thread and I achieved it by thread_create() but because of this code in sfmmu_tsbmiss_exception() function my code with thread_create() is causing kernel panics. So wondering if I can get rid of this if I can get a valid lwp value. 11828 lwp = ttolwp(curthread); 11829 ASSERT(lwp); // this is causing kernel panic And what is unusual by that ? Not every thread has an LWP, it's pretty normal to see ttolwp(curthread) being NULL. The only thing that tells you is that the currently running thread is not part of any userland process but has been created by the kernel itself, or by some kernel driver. So, to avoid this I was just trying to see if it is possible to use lwp_create(). Creating a kernel thread does not imply that a klwp_t is created. What information from an lwp do you need? If there is no user level, you should not need an lwp. So, why do you think you need one? Seconding Max here - why do you think you need one ? Thx, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel threads
On Fri, 25 Jan 2008, ramana polamarasetti wrote: Hi, Can anyone tell me what are all the differences between the threads created with thread_create() and those created with lwp_create()? And is there any way to get an lwp, but using thread_create()? Thanks for any help, Ramana Where do you want to create threads ? In you application ? In a kernel driver of yours ? If the former, i.e. you want to use threads in your application, then you're way along the wrong path, check thr_create() resp. pthread_create() instead. If the latter, i.e. you want to create a thread from within your kernel driver, then please consider first whether other asynchronous mechanisms (taskq or timeout) would do instead. The use of threads breaks power management interfaces, and creates difficult-to-deal-with races on driver unloading. In any case, if you have to it's thread_create(). Calling lwp_create from a kernel driver will get you into trouble. Why would you want to create an LWP from within a kernel driver ? If you're looking for something entirely different, the way how to find out which LWP is executing your kernel driver code, use: klwp_t *curlwp = ttolwp(threadp()); Can you clarify what you want to achieve ? thanks, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel threads
On Fri, 25 Jan 2008, ramana polamarasetti wrote: Hi, Can anyone tell me what are all the differences between the threads created with thread_create() and those created with lwp_create()? And is there any way to get an lwp, but using thread_create()? Thanks for any help, Ramana Where do you want to create threads ? In you application ? In a kernel driver of yours ? In my kernel module. If the former, i.e. you want to use threads in your application, then you're way along the wrong path, check thr_create() resp. pthread_create() instead. If the latter, i.e. you want to create a thread from within your kernel driver, then please consider first whether other asynchronous mechanisms (taskq or timeout) would do instead. The use of threads breaks power management interfaces, and creates difficult-to-deal-with races on driver unloading. In any case, if you have to it's thread_create(). Calling lwp_create from a kernel driver will get you into trouble. Why would you want to create an LWP from within a kernel driver ? My present code uses thread_create(). I am seeing kernel panics due to an ASSERT fail in the sfmmu_tsbmiss_exception(). If you're looking for something entirely different, the way how to find out which LWP is executing your kernel driver code, use: klwp_t *curlwp = ttolwp(threadp()); Can you clarify what you want to achieve ? If I do this in my thread, I am getting curlwp as NULL. because there is no LWP created when I do a thread_create(). And this sfmmu_tsbmiss_exception() is doing the same thing. 11824/* 11825 * Must set lwp state to LWP_SYS before 11826 * trying to acquire any adaptive lock 11827 */ 11828lwp = ttolwp(curthread); 11829ASSERT(lwp); // this is causing kernel panic So, to avoid this I was just trying to see if it is possible to use lwp_create(). thanks, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org Thanks for the reply. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
