On 5/19/07, Eric Saxe <[EMAIL PROTECTED]> wrote:
Thomas De Schampheleire wrote:
> This is run on a simulated serengeti machine.
>
> In the meanwhile, I have tried two things:
>
> 1/ I made my own sbdp_cpu_poweroff function(), which is correctly
> recognized. The execution *seems* to go well, but
Thomas De Schampheleire wrote:
This is run on a simulated serengeti machine.
In the meanwhile, I have tried two things:
1/ I made my own sbdp_cpu_poweroff function(), which is correctly
recognized. The execution *seems* to go well, but I have nevertheless
the idea that it is not correct. Using
Thomas De Schampheleire wrote:
Hi,
I am confused by the following piece of code from
uts/sun4u/serengeti/os/serengeti.c :
237 /*ARGSUSED*/
238 int
239 plat_cpu_poweroff(struct cpu *cp)
240 {
241 int (*serengeti_cpu_poweroff)(struct cpu *) = NULL;
242
243 serengeti_c
When I execute cpu_poweroff() which in turn calls this
plat_cpu_poweroff() function, it returns with ENOTSUP, so it seems the
sbdp_cpu_poweroff function does not exist.
What kind of machine are you running this on?
However, using the source browser, there seems to be a
sbdp_cpu_poweroff() fu
Thomas De Schampheleire wrote:
Hi,
1257 /*
1258 * Take the CPU out of interrupt participation so we won't
find
1259 * bound kernel threads. If the architecture cannot
completely
1260 * shut off interrupts on the CPU, don't quiesce it, but don't
1261 * run any
I managed to work through the problems listed above and have now run into the
limitation of the gnu linker which:
- doesn't generate program headers for "partially linked" objects
- doesn't support the -N flag to add DT_NEEDED entries in the header so that
fssnap_if can be autoloaded to resolve t
Hi,
When testing, you can put your module in any directory you want, for example
/tmp.
The commands you want are modload(9F), modinfo(9F) and modunload(9F). Take a
look at their manpages for some more information.
You don't need a configuration file.
I personally found the following page use
Hi,
On 5/18/07, Eric Saxe <[EMAIL PROTECTED]> wrote:
Thomas De Schampheleire wrote:
>
> I am wondering what the difference is between the CPU_OFFLINE and
> CPU_POWEROFF state, for the operating system.
>
> Of course there is a hardware difference, i.e. the voltage is cut in
> CPU_POWEROFF etc.,
Constantine Kousoulos wrote:
How do we make sure in file
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/i86pc/unix/Makefile
that the embedded 32-bit code remains within the 1st 8K of the elf64
image?
I think ld is in charge of that. Frankly, I do not know exactly how.
Somebo
Thomas De Schampheleire wrote:
I am wondering what the difference is between the CPU_OFFLINE and
CPU_POWEROFF state, for the operating system.
Of course there is a hardware difference, i.e. the voltage is cut in
CPU_POWEROFF etc., but does this make a difference for the OS?
Is it correct that n
Ok, with your help i'm begining to really understand how the magic
works in order to boot a 64 bit image. A few bits and pieces are
still missing to complete the picture.
How do we make sure in file
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/i86pc/unix/Makefile
that the
Hi,
I am wondering what the difference is between the CPU_OFFLINE and
CPU_POWEROFF state, for the operating system.
Of course there is a hardware difference, i.e. the voltage is cut in
CPU_POWEROFF etc., but does this make a difference for the OS?
Is it correct that neither in CPU_OFFLINE, neit
This is run on a simulated serengeti machine.
In the meanwhile, I have tried two things:
1/ I made my own sbdp_cpu_poweroff function(), which is correctly
recognized. The execution *seems* to go well, but I have nevertheless
the idea that it is not correct. Using `psradm -v -a -n` I can verify
13 matches
Mail list logo
