|
Description
|
Jurassic-x4600 paniced at about 2:10 with the following stack trace:
> $c
vpanic()
assfail+0x7e(fffffffffbb48c80, fffffffffbb48e50, 2d7)
segmap_fault+0x46e(fffffffeca74ef08, fffffffffbc2a7f0, ffffff08dbd64000, 2000, 2
, 1)
snf_segmap+0x22a(ffffff096d6e5780, ffffff091a505300, 0, 8e0a, 4000,
ffffff0040d17a40)
sendvec_chunk+0x50f(ffffff096d6e5780, ffffff0040d17bb8, ffffff0040d17cc0, 1,
ffffff0040d17bb0)
sendfilev+0x348(0, 7, 8047350, 1, 804736c)
sys_syscall32+0x1ff()
Core files are on jurassic-x4600:/tank/dump/crash/jurassic-x4600/*.15
Note system was updated to SNV_65 thursday night. Today was the first day system was heavily used - time will tell if this was a rare or common occurance.
|
|
Work Around
|
In /etc/system add
set ip:do_tcpzcopy=0
On a live system where do_tcpzcopy has its default value of 1,
echo 'ip`do_tcpzcopy/W 0' | mdb -kw
will prevent any further sockets being zero copy enabled and exposed to this bug.
Note that due to CR 6564963 the fix suggested will not work.
Sorry, mixing up terms.
The _workaround_ suggested above does not work due to CR 6564963, which
is fixed in snv_67. The suggested fix is OK.
|
