search for: mac_rx_srs_poll_r

...832624 What is the stack calling ddi_dma_sync? dtrace -n ''ddi_dma_sync:entry/cpu==2/{@[stack()]=count();}'' -c "sleep 10" has following output: ixgbe`ixgbe_ring_rx+0x49 ixgbe`ixgbe_ring_rx_poll+0x3e mac`mac_rx_srs_poll_ring+0x143 unix`thread_start+0x8 3545313 ixgbe`ixgbe_ring_rx+0x200 ixgbe`ixgbe_ring_rx_poll+0x3e mac`mac_rx_srs_poll_ring+0x143 unix`thread_start+0x8 3545314 From that, we can say that...

In crossbow, each mac_srs has a kernel thread called "mac_rx_srs_poll_ring" to poll the hardware and crossbow will wakeup this thread to poll packets from the hardware automatically. Does crossbow provide any method to disable the polling mechanism, for example disabling the this kernel thread? Thanks Zhihui -------------- next part -------------- An HTML attachme...

Now at 36 hours since zdb process start and: PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 827 root 4936M 4931M sleep 59 0 0:50:47 0.2% zdb/209 Idling at 0.2% processor for nearly the past 24 hours... feels very stuck. Thoughts on how to determine where and why? -- This message posted from opensolaris.org

I''ve recently re-installed an X4500 running Nevada b109 and have been experiencing ZFS lock ups regularly (perhaps once every 2-3 days). The machine is a backup server and receives hourly ZFS snapshots from another thumper - as such, the amount of zfs activity tends to be reasonably high. After about 48 - 72 hours, the file system seems to lock up and I''m unable to do anything