On Monday, January 28, 2013 1:39:53 am Vijay Singh wrote: > I am investigating an issue where the ixgbe (82599) device is hung and > I think I have traced it to the driver not getting interrupts. I have > MSI/X enabled, with 2 rx/tx queues. > > I am trying to understand this bit of code in the MSI/X setup: > > if (ixgbe_enable_msix) { > ixgbe_configure_ivars(adapter); > /* Set up auto-mask */ <<== THIS BIT > if (hw->mac.type == ixgbe_mac_82598EB) > IXGBE_WRITE_REG(hw, IXGBE_EIAM, IXGBE_EICS_RTX_QUEUE); > else { > IXGBE_WRITE_REG(hw, IXGBE_EIAM_EX(0), 0xFFFFFFFF); > IXGBE_WRITE_REG(hw, IXGBE_EIAM_EX(1), 0xFFFFFFFF); > } > } > > Does this mean that ixgbe_disable_queue() is not needed in the msi/x > interrupt handler - ixgbe_msix_que()?
You are really going to need the datasheet for this adapter to tell. From my recent reading of the datasheet for igb(4) (which is likely similar), it appears that MSI interrupts on that device are configured to auto-clear bits in the interrupt cause registers (ICR and EICR) when an MSI interrupt is posted so that the interrupt handler doesn't have to do a read of these registers to clear their status bits (one of the points of MSI interrupts is that you can just access in-memory descriptor rings when the handler fires without needing to do a read of the PCI device to force any posted memory writes by the device to flush). If I had to wager a guess, I'd say that ixgbe was following the same model. -- John Baldwin _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"