Messages in this thread | | | From | Nix <> | Subject | Re: [E1000-devel] e1000e interface hang on 82574L | Date | Sat, 17 Mar 2012 23:50:51 +0000 |
| |
On 17 Mar 2012, Chris Boot verbalised: > Most notably it appears as though MSI-X is not enabled on the > Supermicro, and ASPM L1 is. There appears to be no difference on the > Supermicro as to the MSI-X status when booting with IntMode=1,1 compared > to without it.
This bug is an ASPM bug, not an MSI bug, and has been present in the in-kernel drivers since something like 2.6.36. I reported it a rather long time ago to the e1000e bugzilla: <http://sourceforge.net/tracker/index.php?func=detail&aid=3170405&group_id=42302&atid=447449> but then I got a severe attack of forgetfulness and forgot what bz it was on until this post prodded me into finding it again. (And then kernel.org was penetrated and I didn't even bother looking, because of course I reported it to the offlined kernel bz, right? No, I didn't.)
I really should follow up on it now and ask the kernel PCI hackers to suggest reasons why ASPM might be getting magically re-enabled at around the same time as the interface is brought up. (Disabling ASPM via setpci at boot doesn't help if the interface hasn't stabilized before that point.)
I haven't done much printf()-scattering to try to track it down because rebooting this machine is quite annoying: it's the heart of my network, my damn-near-everything-server and the machine on which all my work virtual machines run, so rebooting it means disappearing from work for some time while the reboot happens... (but of course this is a really pathetic excuse because I could have devoted a weekend to it or something. So add laziness to my sins.)
So currently I'm doing
setpci -s 02:00.0 CAP_EXP+10.b=40 setpci -s 03:00.0 CAP_EXP+10.b=40
in a root shell to force ASPM off on my two 82574Ls after every boot. It is quite annoying, but 'solves' the problem (for a very crap value of 'solves').
-- NULL && (void)
| |