On Friday, May 06, 2011 11:36:52 am Jack Vogel wrote: > I don't see why you are blaming em, you can see its on MSIX vectors > that are NOT storming, its something with USB as noted. Trying to > disable em from using MSIX is in exactly the wrong direction IMHO. In the past Intel host bridges have exhibited very brain damaged behavior where em interrupts could trigger false interrupts on USB controllers. These host bridges did this because they assumed that if the interrupt line was masked in the I/O APIC, then the OS must be using the 8259A PICs and not the I/O APICs, so it would forward the interrupt down to the 8259A's in the ICH, and the effect was to trigger an interrupt on the line shared with the USB controllers creating phantom USB interrupts for each em(4) interrupt. FreeBSD triggered this because when using INTx and not using Scott's INTR_FAST changes, the kernel would mask em(4)'s interrupt in the I/O APIC which triggered the buggy behavior in the bridge. If for some reason em(4) is asserting both the INTx interrupt and the MSI-X interrupt now, then since the INTx interrupt is not enabled in FreeBSD, the I/O APIC pin will be masked and any INTx assertions would trigger similar phantom interrupts if this bridge was similarly broken. So given that, is there any chance that em(4) could still be asserting its INTx line (or the simulated INTx line rather) when MSI-X is being used? -- John BaldwinReceived on Fri May 06 2011 - 18:19:40 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:13 UTC