Jike Song wrote:
Hi Dan,
Glad to hear from you! I added Solaris support to x86info, built
successfully,
and the patch is attached(against the lasted x86 git repo) for your
information.
But the lack of MSR access make it almost useless. Say:
I don't know what x86info output is supposed to
Hi Dan,
Glad to hear from you! I added Solaris support to x86info, built successfully,
and the patch is attached(against the lasted x86 git repo) for your information.
But the lack of MSR access make it almost useless. Say:
[js226...@git x86info]$ ./x86info
x86info v1.24. Dave Jones 2001
Jike Song wrote:
Hi,
I'm porting x86info to opensolaris. Among many options, x86info try to
access MSR registers(MTRR, TSC, etc.), but x86 CPU allows MSR access
only in RING 0 privilege. In order to allow access from userspace,
there have to be a msr driver in kernel to handle it.
Does op
Guy wrote:
Hello community !
Is there a way to disable opteron dram scrubbing from GRUB menu ?
I know a way from /etc/system (set mc-amd:mc_scrub_rate_dram = 0)
But since my opteron server tends to hard hang after a while (because of
opteron bug),
if I try to install an entire distribution, I
On 9/04/09 09:41 AM, Garrett D'Amore wrote:
Paul Durrant wrote:
Garrett D'Amore wrote:
I'm unconvinced that it is any cheaper. The question is ... how is
the kernel DDI going to track these by dev_t. dev_ts don't point
to structures. So the DDI implementation would either need to use a
Hi everyone
I am a recruiter for a company called Paradigm Technology, and I handle all of
the contract, contract-to-hire and permanent staffing for a variety of
Information Technology positions and projects across the country. My client
has immediate needs for a Unix Engineer/Admin for AI
Paul Durrant wrote:
Garrett D'Amore wrote:
I'm unconvinced that it is any cheaper. The question is ... how is
the kernel DDI going to track these by dev_t. dev_ts don't point to
structures. So the DDI implementation would either need to use a
hash table itself, or would need to manage to
Garrett D'Amore wrote:
I'm unconvinced that it is any cheaper. The question is ... how is the
kernel DDI going to track these by dev_t. dev_ts don't point to
structures. So the DDI implementation would either need to use a hash
table itself, or would need to manage to track the state else
Hi Darren,
There's another issue with this change. With some open
type(parameter otyp), prefixopen entry will be called once for each
sys_open system call, and prefixclose entry may only be called for
the last sys_close system call when open count changes from
non-zero to zero. So how to en
Paul Durrant wrote:
Garrett D'Amore wrote:
While this would make some drivers simpler (the lookup of the dev_t
would be simpler), it isn't strictly necessary.
I think you could achieve the same basic result by just offering a
new set of utility routines:
* ddi_set_devt_private(dev_t, voi
Garrett D'Amore wrote:
While this would make some drivers simpler (the lookup of the dev_t
would be simpler), it isn't strictly necessary.
I think you could achieve the same basic result by just offering a new
set of utility routines:
* ddi_set_devt_private(dev_t, void *ctx);
* void *d
Paul Durrant wrote:
Darren Reed wrote:
What I'd like to suggest is that we consider expanding the entry
points for regular device drivers to allow for context to be created
in open(9e), passed back in with all of the other entry points (read,
write, strategy, etc) and require the driver to clea
>Hi,
>
>Recently we hit a problem with one of our file systems where 2 kernel threads
>were killed holding
a kmutex. Due to this all the applications which use the fs blocked waiting for
the kmutex.
>
>I am wondering why there is no synchronization type equivalent to
>USYNC_PROCESS_ROBUST (whi
Hi,
Recently we hit a problem with one of our file systems where 2 kernel threads
were killed holding a kmutex. Due to this all the applications which use the fs
blocked waiting for the kmutex.
I am wondering why there is no synchronization type equivalent to
USYNC_PROCESS_ROBUST (which essent
Paul Durrant wrote:
Darren Reed wrote:
What I'd like to suggest is that we consider expanding the entry
points for regular device drivers to allow for context to be created
in open(9e), passed back in with all of the other entry points (read,
write, strategy, etc) and require the driver to clea
Hello gerry
Maybe the nevada distro DVD could embed this in its /etc/system ?
It's not important to have the dram scrubber enabled while Solaris is being
installed.
As long as the default value for the installed system is not modified, it's
worth it.
It protects against opteron hard hang bugs.
Darren Reed wrote:
What I'd like to suggest is that we consider expanding the entry
points for regular device drivers to allow for context to be created
in open(9e), passed back in with all of the other entry points (read,
write, strategy, etc) and require the driver to clear it in close(9e).
T
17 matches
Mail list logo
