fmd itself will not disable DIMMs. The firmware on some SPARC platforms
(I don't think the V890 is one of them) may blacklist DIMMs that
experience a fatal UE. From the OS' point of view, a blacklisted DIMM
will appear to have effectively disappeared. But that is not what
happened here.
Wh
On Fri, Mar 11, 2011 at 11:21 PM, Jerry Sutton wrote:
> I believe you will find that fmd has disabled this DIMM or DIMMs.
> If you know how much memory is supposed to be there you can check the
> output of 'prtconf", or, preferably, that of "prtdiag -v" and compare that
> to what you believe is ph
I believe you will find that fmd has disabled this DIMM or DIMMs.
If you know how much memory is supposed to be there you can check the
output of 'prtconf", or, preferably, that of "prtdiag -v" and compare
that to what you believe is physically installed.
The last time I read the fmadm manpage,
On 03/11/11 01:51 PM, Bill Shannon wrote:
> When printing from firefox using lpr in snv_160, lpr dumps core:
>
> Is this a known bug?
Yes. 7010842 lp segfaults when asked to print stdin
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineeri
When printing from firefox using lpr in snv_160, lpr dumps core:
datsunx$ adb /usr/lib/lp/bin/lpr core
core file = core -- program ``/usr/lib/lp/bin/lpr'' on platform i86pc
SIGSEGV: Segmentation Fault
$c
libpapi-common.so.0`regvalue+0x16(fedb5ad4, fedb5ad8, 0, 4, 806b4a0, fef6e000)
libpapi-common
You might run into an issue with the Partition numbers in menu.lst.
So, to modify things.
Do a complete backup of everything just in case.
Print out the grub documentation just in case you need to use grub's find
command to find things in a different partition number.
Repartition.
Install Win
Our V890 server reported a memory fault, rebooted, and now shows the following:
csgams08:~>sudo fmadm faulty
Password:
--- -- -
TIMEEVENT-ID MSG-ID SEVERITY
--- --
Hi all
It seems the physmem option in /etc/system and as given to the kernel boot is
broken. Booting a system with physmem set to something lower than its actual
size fails to give any message, and the system has its full amount of memory
available. Same applies to using kernel options (-B phys
Interesting story. So basically: avoid dedup. But you didnt loose any data.
Right?
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Actually, I have three partitions:
1) WinXP
2) FAT32
3) S11e
If I modify the size of 1) and 2), for instance merge 1) and 2), before
installing S11e - does this change anything? Do I need to use the same steps as
you outlined?
--
This message posted from opensolaris.org
___
Ok, I will print out menu.lst and look at it before formatting. And I need to
get the S11e disc, as I have upgraded from b134.
Thanks man!
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris
> > Deleting the dedup'ed data won't work better,
> since
> > ZFS will have to process it quite the same way as
> if
> > you're destroying a ZFS volume.
>
> This was my only dedup'd dataset, so I have no other
> experience deleting them. Do you think that, had
> there been no data, my "zfs destro
12 matches
Mail list logo
