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,
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
, 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 },
Cheers,
Steve Gonczi
- Original Message -
I just found that I do not exactly know: What
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
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
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 =
