>-----Original Message----- >From: Eric Hamilton [mailto:eric.hamil...@harmonicinc.com] >Sent: Thursday, April 02, 2015 12:15 PM >To: e1000-devel@lists.sourceforge.net >Subject: [E1000-devel] ixgbe: Can't read card registers during probe > >I am attempting to get an X520-SR2 card to work in an Intel 1RU system using >the S2600WT2 server board (aka Wildcat Pass). It works great in Centos 7. >>Sadly I need to get the ixgbe driver to work in our old creaky 2.6.18-128 >based kernel-- basically the RHEL 5.3 srpm with a few patches. > >I know this is not a supported kernel tested by you developers, but if anybody >has seen this before and is feeling generous, any help would be appreciated. >>And heck, we're trying to buy Intel cards and Intel servers, so maybe in >addition pleading for mercy there might be a bit of mutual interest for at >least >some of the maintainers. > >I've tried with the 3.23.2 version from sourceforge (after fixing oops I >reported in bug 465). I've also tried 2.0.84.11 on the theory that we don't >need >X540 (yet) and that something older would be more likely to work with >older kernels. > >With no instrumentation the symptoms are misleading: > * 3.23.2 complains that "Driver can't access the Eeprom - SMBI Semaphore not > granted." > * 2.0.84.11 complains that SFP+ module is not supported (a head scratcher at > first since we bought it from Intel and it works on Centos). > >After turning on various debug options and embracing printk, those are just >symptoms of not being able to read registers from the card. I think something >>is wrong with setting up access to PCIe register space-- either in the driver >itself or in the driver interactions with the PCI subsystem. Here's >>instrumented output following modprobe:
If the register reads fail then all kinds of checks will fail which will result in the driver reporting errors. In general when register reads fail it is a strong indication of a HW issue of some sort - it is not something that the driver can resolve. >Intel(R) 10 Gigabit PCI Express Network Driver - version 3.23.2-experimental >Copyright (c) 1999-2014 Intel Corporation. >PCI: Enabling device 0000:81:00.0 (0140 -> 0143) >ACPI: PCI Interrupt 0000:81:00.0[A] -> GSI 56 (level, low) -> IRQ 154 >ixgbe_set_mac_type >ixgbe_set_mac_type found mac: 2, returns: 0 >PCI: Setting latency timer of device 0000:81:00.0 to 64 >ixgbe_init_shared_code >ixgbe_set_mac_type >ixgbe_set_mac_type found mac: 2, returns: 0 >ixgbe_init_ops_82599 >ixgbe_init_phy_ops_generic >ixgbe_init_ops_generic (I moved DEBUGFUNC before IXGBE_READ_REG) >ixgbe_read_reg called reg_addr=ffffc20010200000 reg=10010 >ixgbe_read_reg failed. reg_addr=ffffc20010200000 reg=10010 >ixgbe_read_reg failed. reg_addr=ffffc20010200000 reg=8 >IXGBE_STATUS failed previously. hw_addr=ffffc20010200000 >ixgbe 0000:81:00.0: Adapter removed > >After ixgbe_probe sets up hw->hw_addr, the very first call to >ixgbe_read_reg(), in ixgbe_init_ops_generic where it calls IXGBE_READ_REG(hw, >IXGBE_EEC) the >read fails. It then proceeds to try to read IXGBE_STATUS >which fails too, making it look like the card has been removed. Bad stuff >follows. > >Sound familiar? Any hints? I've also copied the lspci -vvv output for the >card below. Not really. As I mentioned the only time I have seen something like this is due to a HW issue. >Thanks, >Eric > >81:00.0 Ethernet controller: Intel Corporation Unknown device 10fb (rev 01) > Subsystem: Intel Corporation Unknown device 0003 > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > <TAbort- <MAbort- >SERR- <PERR- > Interrupt: pin A routed to IRQ 154 > Region 0: Memory at 387fffd80000 (64-bit, prefetchable) [disabled] > [size=512K] > Region 2: I/O ports at 8020 [disabled] [size=32] > Region 4: Memory at 387fffe04000 (64-bit, prefetchable) [disabled] > [size=16K] > Capabilities: [40] Power Management version 3 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0+,D1-,D2-,D3hot+,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=1 PME- > Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ > Queue=0/0 Enable- > Address: 0000000000000000 Data: 0000 > Masking: 00000000 Pending: 00000000 > Capabilities: [70] MSI-X: Enable- Mask- TabSize=64 > Vector table: BAR=4 offset=00000000 > PBA: BAR=4 offset=00002000 > Capabilities: [a0] Express Endpoint IRQ 0 > Device: Supported: MaxPayload 512 bytes, PhantFunc 0, ExtTag- > Device: Latency L0s <512ns, L1 <64us > Device: AtnBtn- AtnInd- PwrInd- > Device: Errors: Correctable- Non-Fatal+ Fatal+ Unsupported- > Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ > Device: MaxPayload 256 bytes, MaxReadReq 512 bytes > Link: Supported Speed unknown, Width x8, ASPM L0s, Port 0 > Link: Latency L0s <1us, L1 <8us > Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- > Link: Speed unknown, Width x8 > Capabilities: [100] Advanced Error Reporting > Capabilities: [140] Device Serial Number d0-ac-7f-ff-ff-ba-e2-90 > Capabilities: [150] Unknown (14) > Capabilities: [160] Unknown (16) You mentioned that CentOS 7 works fine - is it on this exact system? If so you may want to compare the output of lspci from the working and failing scenarios. Thanks, Emil ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
