Nicolas Droux wrote:
Andrew,
Thanks for the additional info. We'd like to verify that interrupts are
getting disabled from interrupt context itself. If you don't mind, could
you gather an aggregation of the callers of mac_hwring_disable_intr()
during one of your runs? You should be able to do this with "dtrace -n
fbt:: mac_hwring_disable_intr:entry'{...@[stack()] = count()}'"
Yes, they're all coming from the interrupt context, via my rx
interrupt handler:
dtrace: description 'fbt::mac_hwring_disable_intr:entry' matched 1 probe
^C
mac`mac_rx_srs_drain+0x359
mac`mac_rx_srs_process+0x1db
mac`mac_rx+0x94
mac`mac_rx_ring+0x4c
myri10ge`myri10ge_intr_rx+0x70
myri10ge`myri10ge_intr+0xa2
unix`av_dispatch_autovect+0x7c
unix`dispatch_hardint+0x33
unix`switch_sp_and_call+0x13
66481
FWIW, I was able to reproduce the problem on another machine
running build 111. I BFU'ed to 112, 113, and 114, and I see
the same thing in each build.
I think that I must be doing something wrong in my driver.
Is there some sort of counter or dtrace script that one
use to track down out-of-order packets?
I'm not sure if this is helpful, but the 2 stacks I see for
the increment of mib:::tcpInDataUnorderSegs are:
# dtrace -n mib:::tcpInDataUnorderSegs'{...@[stack()] = count()}'
dtrace: description 'mib:::tcpInDataUnorderSegs' matched 1 probe
^C
ip`tcp_rput_data+0xdd0
ip`squeue_enter+0x330
ip`ip_input+0xc17
mac`mac_rx_soft_ring_drain+0xdf
mac`mac_soft_ring_worker+0x111
unix`thread_start+0x8
1710
ip`tcp_rput_data+0xdd0
ip`squeue_drain+0x179
ip`squeue_enter+0x3f4
ip`ip_input+0xc17
mac`mac_rx_soft_ring_drain+0xdf
mac`mac_soft_ring_worker+0x111
unix`thread_start+0x8
195335
Thanks,
Drew
_______________________________________________
networking-discuss mailing list
[email protected]
