I've filed specifically for ZFS:
6735425 some places where 64bit values are being incorrectly accessed
on 32bit processors
eric
On Aug 6, 2008, at 1:59 PM, Brian D. Horn wrote:
> In the most recent code base (both OpenSolaris/Nevada and S10Ux with
> patches)
> all the known marvell88sx probl
Hmm... it appears that my e-mail to the zfs list covering the problems has
disappeared. I will send it again and cross my fingers.
The basic problem I found was that with the Supermicro AOC-SAT2-MV8 card (using
the marvell chipset), drive removals are not detected consistently by Solaris.
The
1) I don't believe that any bug report has been generated despite various
e-mails
about this topic.
2) The marvell88sx driver has not been changed recently, so that if this problem
actually exists, it is probably related to the sata framework.
3) Is this problem simply that when a device i
> In the most recent code base (both OpenSolaris/Nevada and S10Ux with patches)
> all the known marvell88sx problems have long ago been dealt with.
I'd dispute that. My testing appears to show major hot plug problems with the
marvell driver in snv_94.
This message posted from opensolaris.org
+--
| On 2008-08-07 03:53:04, Marc Bevand wrote:
|
| Bryan, Thomas: these hangs of 32-bit Solaris under heavy (fs, I/O) loads are
a
| well known problem. They are caused by memory contention in the kernel heap.
| Check
Yes, there have been bugs with heavy I/O and ZFS running the system
out of memory. However, there was a contention in the thread
about it possibly being due to marvell88sx driver bugs (most likely not).
Further, my mention of 32-bit Solaris being unsafe at any speed is still
true. Without analysi
On Thu, Aug 7, 2008 at 5:53 AM, Marc Bevand <[EMAIL PROTECTED]> wrote:
> Bryan, Thomas: these hangs of 32-bit Solaris under heavy (fs, I/O) loads are a
> well known problem. They are caused by memory contention in the kernel heap.
> Check 'kstat vmem::heap'. The usual recommendation is to change th
Bryan, Thomas: these hangs of 32-bit Solaris under heavy (fs, I/O) loads are a
well known problem. They are caused by memory contention in the kernel heap.
Check 'kstat vmem::heap'. The usual recommendation is to change the
kernelbase. It worked for me. See:
http://mail.opensolaris.org/pipermai
On Thu, Aug 7, 2008 at 5:32 AM, Peter Bortas <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 6, 2008 at 7:31 PM, Bryan Allen <[EMAIL PROTECTED]> wrote:
>>
>> Good afternoon,
>>
>> I have a ~600GB zpool living on older Xeons. The system has 8GB of RAM. The
>> pool is hanging off two LSI Logic SAS3041X-Rs (
On Wed, Aug 6, 2008 at 6:22 PM, Carson Gaspar <[EMAIL PROTECTED]> wrote:
> Brian D. Horn wrote:
>> In the most recent code base (both OpenSolaris/Nevada and S10Ux with patches)
>> all the known marvell88sx problems have long ago been dealt with.
>
> Not true. The working marvell patches still have
As far as I can tell from the patch web patches:
For Solaris 10 x86 138053-01 should have the fixes it does
depend on other earlier patches though). I find it very difficult
to tell what the story is with patches as the patch numbers
seem to have very little in them to correlate them to
code chan
Brian D. Horn wrote:
> In the most recent code base (both OpenSolaris/Nevada and S10Ux with patches)
> all the known marvell88sx problems have long ago been dealt with.
Not true. The working marvell patches still have not been released for
Solaris. They're still just IDRs. Unless you know somethi
Brian D. Horn wrote:
> In the most recent code base (both OpenSolaris/Nevada and S10Ux with patches)
> all the known marvell88sx problems have long ago been dealt with.
>
> However, I've said this before. Solaris on 32-bit platforms has problems and
> is not to be trusted. There are far, far too
In the most recent code base (both OpenSolaris/Nevada and S10Ux with patches)
all the known marvell88sx problems have long ago been dealt with.
However, I've said this before. Solaris on 32-bit platforms has problems and
is not to be trusted. There are far, far too many places in the source
code
For what it's worth I see this as well on 32-bit Xeons, 1GB ram, and
dual AOC-SAT2-MV8 (large amounts of io sometimes resulting in lockup
requiring a reboot --- though my setup is Nexenta b85). Nothing in the
logging, nor loadavg increasing significantly. It could be the
regular Marvell driver iss
On Wed, Aug 6, 2008 at 13:31, Bryan Allen <[EMAIL PROTECTED]> wrote:
> I have a ~600GB zpool living on older Xeons. The system has 8GB of RAM. The
> pool is hanging off two LSI Logic SAS3041X-Rs (no RAID configured).
You might try taking out 4gb of the ram (!). Some 32-bit drivers have
problems do
Good afternoon,
I have a ~600GB zpool living on older Xeons. The system has 8GB of RAM. The
pool is hanging off two LSI Logic SAS3041X-Rs (no RAID configured).
When I put a moderate amount of load on the zpool (like, say, copying many
files locally, or deleting a large number of ZFS fs), the sys
Hello Erik,
Friday, June 23, 2006, 2:35:30 AM, you wrote:
ET> So, basically, the problem boils down to those with Xeons, a few
ET> single-socket P4s, and some of this-year's Pentium Ds. Granted, this
ET> makes up most of the x86 server market. So, yes, it _would_ be nice to
ET> be able to dump
Erik Trimble wrote:
Artem Kachitchkine wrote:
AMD Geodes are 32-bit only. I haven't heard any mention that they
will _ever_ be 64-bit. But, honestly, this and the Via chip aren't
really ever going to be targets for Solaris. That is, they simply
aren't (any substantial) part of the audience
Erik Trimble wrote:
AMD Geodes are 32-bit only. I haven't heard any mention that they will
_ever_ be 64-bit. But, honestly, this and the Via chip aren't really
ever going to be targets for Solaris. That is, they simply aren't (any
substantial) part of the audience we're trying to reach with S
>AMD Geodes are 32-bit only. I haven't heard any mention that they will
>_ever_ be 64-bit. But, honestly, this and the Via chip aren't really
>ever going to be targets for Solaris. That is, they simply aren't (any
>substantial) part of the audience we're trying to reach with Solaris x86.
I'm
I guess the only hope is to find pin-compatible Xeons that are 64bit
to replace what is a large chassis with 24 slots of disks that has
specific motherboard form-factor, etc. We have 6 of these things from
a government grant that must be used for the stated purpose. So, yes,
we can buy product, bu
Erik Trimble wrote:
Dell (arrggh! Not THEM!) sells PowerEdge servers with plenty of PCI
slots and RAM, and 64-bit CPUs for around $1000 now. Hell, WE sell
dual-core x2100s for under $2k. I'm sure one can pick up a whitebox
single-core Opteron for around $1k. That's not unreasonable to ask
Artem Kachitchkine wrote:
AMD Geodes are 32-bit only. I haven't heard any mention that they
will _ever_ be 64-bit. But, honestly, this and the Via chip aren't
really ever going to be targets for Solaris. That is, they simply
aren't (any substantial) part of the audience we're trying to reac
AMD Geodes are 32-bit only. I haven't heard any mention that they will
_ever_ be 64-bit. But, honestly, this and the Via chip aren't really
ever going to be targets for Solaris. That is, they simply aren't (any
substantial) part of the audience we're trying to reach with Solaris x86.
Didn'
AMD Geodes are 32-bit only. I haven't heard any mention that they will
_ever_ be 64-bit. But, honestly, this and the Via chip aren't really
ever going to be targets for Solaris. That is, they simply aren't (any
substantial) part of the audience we're trying to reach with Solaris x86.
Also, r
On Thu, 22 Jun 2006, Joe Little wrote:
> On 6/22/06, Darren J Moffat <[EMAIL PROTECTED]> wrote:
> > Rich Teer wrote:
> > > On Thu, 22 Jun 2006, Joe Little wrote:
> > >
> > > Please don't top post.
> > >
> > >> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
> > >> I think it
Joe Little wrote:
On 6/22/06, Darren J Moffat <[EMAIL PROTECTED]> wrote:
Rich Teer wrote:
> On Thu, 22 Jun 2006, Joe Little wrote:
>
> Please don't top post.
>
>> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
>> I think it would still be ideal to allow tweaking of things
On 6/22/06, Darren J Moffat <[EMAIL PROTECTED]> wrote:
Rich Teer wrote:
> On Thu, 22 Jun 2006, Joe Little wrote:
>
> Please don't top post.
>
>> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
>> I think it would still be ideal to allow tweaking of things at runtime
>> to ma
>Are VIA processor chips 64bit capable yet ?
No, I don't think so.
And Geode?
Casper
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Rich Teer wrote:
On Thu, 22 Jun 2006, Joe Little wrote:
Please don't top post.
What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
I think it would still be ideal to allow tweaking of things at runtime
to make 32-bit systems more ideal.
I respectfully disagree. Even on x86
On Thu, 22 Jun 2006, Joe Little wrote:
Please don't top post.
> What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
> I think it would still be ideal to allow tweaking of things at runtime
> to make 32-bit systems more ideal.
I respectfully disagree. Even on x86, 64-bits are c
What if your 32bit system is just a NAS -- ZFS and NFS, nothing else?
I think it would still be ideal to allow tweaking of things at runtime
to make 32-bit systems more ideal.
On 6/21/06, Mark Maybee <[EMAIL PROTECTED]> wrote:
Yup, your probably running up against the limitations of 32-bit kern
Yup, your probably running up against the limitations of 32-bit kernel
addressability. We are currently very conservative in this environment,
and so tend to end up with a small cache as a result. It may be
possible to tweak things to get larger cache sizes, but you run the risk
of starving out
Hello zfs-discuss,
Simple test 'ptime find /zfs/filesystem >/dev/null' with 2GB RAM.
After second, third, etc. time still it reads a lot from disks while
find is running (atime is off).
on x64 (Opteron) it doesn't.
I guess it's due to 512MB heap limit in kernel for its cache.
::memst
35 matches
Mail list logo
