Thank you very much for the suggestion.
I have shut off interrupt processing on 4 out of the 16 cpus, and now I can run
dtrace
profiling, without the watchdog killing dtrace.
The machine still goes into a bogged-down state.
Running dtrace -n 'profile:::profile-3456 /arg0/ { @[stack(4)] = count(); }'
for a minute or so while in the "bad state" fingers these stacks as most
frequent:
Looks mostly idle to me. Yet, as I type, I have to wait seconds for my text
to appear on the console,
and network throughput is down to nothing.
Ideas, anyone?
unix`disp_getwork+0xb6
unix`disp+0x1c2
unix`swtch+0xa4
genunix`cv_wait+0x61
3742
zfs`lzjb_compress+0xee
zfs`zio_compress_data+0x8e
zfs`zio_write_bp_init+0x216
zfs`zio_execute+0x8d
3808
unix`ddi_get32+0x14
mac`mac_hwring_disable_intr+0x1d
mac`mac_rx_srs_drain+0x3a2
mac`mac_rx_srs_process+0x1db
3819
unix`0xfffffffffb85074a
genunix`uiomove+0xe9
sockfs`socopyoutuio+0x68
sockfs`so_dequeue_msg+0x4e9
4886
unix`i86_monitor+0x10
unix`cpu_idle_mwait+0xbe
unix`cpu_acpi_idle+0x8d
unix`cpu_idle_adaptive+0x19
6028
unix`acpi_cpu_cstate+0x2f0
unix`cpu_acpi_idle+0x82
unix`cpu_idle_adaptive+0x19
unix`idle+0x114
9725
unix`atomic_and_64+0x4
unix`acpi_cpu_cstate+0x2d9
unix`cpu_acpi_idle+0x82
unix`cpu_idle_adaptive+0x19
17888
unix`acpi_cpu_cstate+0x2ae
unix`cpu_acpi_idle+0x82
unix`cpu_idle_adaptive+0x19
unix`idle+0x114
86695
unix`i86_mwait+0xd
unix`cpu_idle_mwait+0xf1
unix`cpu_acpi_idle+0x8d
unix`cpu_idle_adaptive+0x19
1645528
--
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
