Well, when you leave out a bunch of relevant information you also leave
people guessing! :-)
Regardless, is it possibly that all of your testing was done with ZFS and not
just the "raw" disk? If so, it is possible that ZFS isn't noticing the hot
unplugging
of the disk until it tries to access th
Looking at what you wrote, you claim that hot plug events on ports 6 and 7
generally work, but other ports are not immediately discovered. Since
there is no special code for ports 6 & 7 and no one else has reported this
sort of behavior, it would make me think that you have a hardware issue.
Possi
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
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
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
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
eric kustarz wrote:
>
> On Mar 6, 2008, at 7:58 AM, Brian D. Horn wrote:
>
>> Take a look at CR 6634371. It's worse than you probably thought.
>
> The only place i see ZFS mentioned in that bug report is regarding
> z_mapcnt. Its being atomically inc/dec in zfs_
If you look at the contents of the CR it does say that. However there
are something like 200 instances and of those perhaps one or two
dozen are NOT statistics. A few examples from around the kernel
were pointed out. (interrupt handling, NIC driver, ZFS, ...)
This message posted from opensol
It isn't a simple as getting an old stale value. You can get a totally
incorrect
value. Example:
Let us assume a monotonically increased 64-bit values which at the start
of this discussion is: 0x (32-bits 0, 32-bits 1).
The 32-bit kernel goes to read the 64-bit value and does s
Take a look at CR 6634371. It's worse than you probably thought.
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
ZFS is not 32-bit safe. There are a number of places in the ZFS code where
it is assumed that a 64-bit data object is being read atomically (or set
atomically). It simply isn't true and can lead to weird and bugs.
This message posted from opensolaris.org
__
Scott Lovenberg wrote:
>> eric kustarz wrote:
>>
>>> On Jul 9, 2007, at 11:21 AM, Scott Lovenberg wrote:
>>>
>>>
>>>
You sir, are a gentleman and a scholar!
>> Seriously, this is exactly
>>
>>> the information I was looking for, thank you very
>>>
>>
eric kustarz wrote:
> On Jul 9, 2007, at 11:21 AM, Scott Lovenberg wrote:
>
>
>> You sir, are a gentleman and a scholar! Seriously, this is exactly
>> the information I was looking for, thank you very much!
>>
>> Would you happen to know if this has improved since build 63 or if
>> chipset
13 matches
Mail list logo
