Jim,
This makes sense.
fmdump -eV reported that your original drive was experiencing repeated
fread failures ( scsi command code 0x28)
Steve
- Original Message -
Well, I decided to bite the bullet and kick the original
disk from the pool after replacing it with the spare, an
The interesting bit is what happens inside arc_reclaim_needed(),
that is, how it arrives at the conclusion that there is memory pressure.
Maybe we could trace arg0, which gives the location where
we have left the function. This would finger which return path
arc_reclaim_needed() took.
Steve
" },
{ byteswap_uint8_array , FALSE , "ZFS plain file" }, { zap_byteswap , TRUE ,
"ZFS directory" }, { zap_byteswap , TRUE , "ZFS master node" },
{ zap_byteswap , TRUE , "ZFS delete queue" },
{ byteswap_uint8_array , FALSE , "zvol object&qu
Greetings,
I am seeing some unexplained performance drop using the above cpus,
using a fairly up-to-date build ( late 145).
Basically, the system seems to be 98% idle, spending most if its time in this
stack:
unix`i86_mwait+0xd
unix`cpu_idle_mwait+0xf1
u
More info:
The crashes go away just by swapping the cpu to a faster/more horsepower cpu.
On one box where the crash consistently happened (2 core slow cpu)
I no longer see the crash after swapping to a quad core.
--
This message posted from opensolaris.org
As I am looking at this further, I convince myself this should really be an
assert.
(I am running release builds, so assert-s do not fire).
I think in a debug build, I should be seeing the !list_empty() assert in:
list_remove(list_t *list, void *object)
{
list_node_t *lold = list_d2l
Greetings,
I see repeatable crashes on some systems after upgrading.. the signature is
always the same:
operating system: 5.11 snv_139 (i86pc)
panic message: BAD TRAP: type=e (#pf Page fault) rp=ff00175f88c0 addr=0
occurred in module "genunix" due to a NULL pointer dereference
list_remove+
