Prev: Warning: error writing VTOC Warning: no backup labels Write label failed
Next: Problem with Developer Releases - Drive offline
From: nccc on 1 Nov 2009 11:22 > > No, it's all dynamic .... > And which struct specifies the location of the first cpu_t struct? All this thing must have its roots in a known place, right? Maybe I reach the undisclosed details of Solaris?...
From: Casper H.S. Dik on 1 Nov 2009 12:30 nccc <strikosn(a)gmail.com> writes: >> >> No, it's all dynamic .... >> >And which struct specifies the location of the first cpu_t struct? All >this thing must have its roots in a known place, right? Maybe I reach >the undisclosed details of Solaris?... Well, they're compiled in the kernel and so the kernel can find the particular symbol after it was loaded. The first cpu is "cpus" and the pointers to all cpus are in the array "cpu". Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
From: nccc on 3 Nov 2009 12:39 This has been helpful. Thanks alot. nccc
From: nccc on 4 Nov 2009 12:24 Well, that was actually trickier than I thought... The reason is that, although I read the 'cpu_thread[0].t_procp [0].p_user.u_comm' string beginning from the cpu_t struct, the string that it contains is not the right one. And I know, because when the cpu is executing instructions of my application, the string reads "sched" i.e. the scheduler. It seems that this cpu_t struct does not reflect what is actually executing on the cpu. What is going on?? nccc
From: Casper H.S. Dik on 5 Nov 2009 03:33
nccc <strikosn(a)gmail.com> writes: >Well, that was actually trickier than I thought... >The reason is that, although I read the 'cpu_thread[0].t_procp >[0].p_user.u_comm' string beginning from the cpu_t struct, the string >that it contains is not the right one. And I know, because when the >cpu is executing instructions of my application, the string reads >"sched" i.e. the scheduler. It seems that this cpu_t struct does not >reflect what is actually executing on the cpu. What is going on?? I can only mean that one of the kernel server threads is running on the CPU. Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth. |