Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#379 82574L on mini-itx Intel 2500MUD2 not working

closed
Todd Fujinaka
None
in-kernel_driver
1
2013-09-05
2013-08-21
prz
No

82574L chip is foobar'ed to an unbelievable degree. Tried e'thing from 1.3.xx drivers up to 2.3 & 2.4.

. first issue the power savings & chip patch, did all that
. as next issue killed the msi-x & msi, chip is in legacy mode
. tried to switch off all the tx,rx & so on things
. ran out of ideas/internet searches

kernel: Live CD F18 or custom 2.6.39 with ported in drivers, behaves all the same
symptom: cannot dhcp an address on boot (waits for carrier, looses carrier after that, misses offers, whatever), barely stays up on pings, on a thing like ssh or any minimal ip traffic chip basically resets, comes back 10 secs later
with msi and msi-x same problems as other forum issue, basically logs 'hangs' and restarts chip.

Would not bother with that but must bring up 2500MUD2 board for customers in an embedded environment & that is a showstopper.

Discussion

  • Todd Fujinaka
    Todd Fujinaka
    2013-08-22

    Sorry you're having this trouble. I would not expect the 2.6.39 kernel (2.6.39.4 is the latest but is from 8/2011) to run on a motherboard that was released in Q3 of 2012. Fedora 18 was released in January of 2013, so would be a better choice, but it's also a moving target and you need the updates for many of the drivers to work properly.

    Also, our desktop boards also do not have official Linux support.

    This is also the support for the network driver so I can't really help you with the board.

    I would suggest loading the latest stable kernel or the latest patched Fedora 19 on a hard drive and giving that a try.

    The 82574L should be supported on most e1000e drivers, but you're going to have to find a usable kernel that is newer than your motherboard.

    Also, a transmit hang is a symptom of a problem, not the problem itself. It just means the part or the network or even the system isn't keeping up with sending the data that is being sent to the Ethernet controller. Just googling for transmit hang and the part number will not get you much closer to the root cause of your issue.

    The 82574L does have issues, but most have them have been addressed and the part should run close to 1G line rate, but I've only tried this with non-Atom processors. I don't know if the Atom can provide enough data to run at line rate.

    Hope that helps.

     
  • prz
    prz
    2013-08-22

    Thanks for answer, Todd but this is missing realities of things on the ground how mini-ITX boards are used often in high-value long-term applications. Those are boards for embedded market that is much slower than the average 'just update to newest beta & try it' desktop use.

    And I am in fact doing that, brining up F19 up & looking @ CentOS to find something that works to back-port.

    Honestly, I do not think it's just a symptom (unless the hardware here is fried which I do not hope), 2.6.39 kernels were really stable and lots embedded world runs it. Actually, I have it @ the point it behaves better than F18, it can stay up on pings until first bigger IP packet hits it. F18 can't even ping, it says NETDEV watchdog transmit queue 0 timed out & resets on unit hang.

    BTW, I had 2.6.39 on countless chips & boards & this Intel chip is by far the worse I hit.

    Right now a simple 'ping' is 'not keeping up with the network' on F18 so I don't think volume is of any relation to the problem. The problem is clearly in the driver running on this board (trust me, doing Linux here since 0.9 betas so it has been a few years, releases & boards).

     
    Last edit: prz 2013-08-22
  • prz
    prz
    2013-08-22

    FYI, newest F19 live image behaves exactly the same as F18, unexpected adapter resets the moment 2-3 packets hit it.
    Driver is @ 2.2.14-k

     
    Last edit: prz 2013-08-22
  • prz
    prz
    2013-08-22

    here's the info (with kernel debug & prink enabled on the driver) in case it's helpful. It is consitent across f18, ubuntu 12.04 LTS, 2.6.39 with all kind of drivers compiled in

    Kernel is

    01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
    Subsystem: Intel Corporation Device 2014
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort+ <MAbort-="">SERR- <PERR- INTx-
    Latency: 0, Cache Line Size: 64 bytes
    Interrupt: pin A routed to IRQ 42
    Region 0: Memory at 80020000 (32-bit, non-prefetchable) [size=128K]
    Region 1: Memory at 80000000 (32-bit, non-prefetchable) [size=128K]
    Region 2: I/O ports at 1000 [size=32]
    Region 3: Memory at 80040000 (32-bit, non-prefetchable) [size=16K]
    Capabilities: [c8] Power Management version 2
    Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
    Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Address: 00000000fee0f00c Data: 4179
    Capabilities: [e0] Express (v1) Endpoint, MSI 00
    DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
    ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
    DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
    RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
    MaxPayload 128 bytes, MaxReadReq 512 bytes
    DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
    LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
    ClockPM- Surprise- LLActRep- BwNot-
    LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
    ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
    LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
    Capabilities: [a0] MSI-X: Enable- Count=5 Masked-
    Vector table: BAR=3 offset=00000000
    PBA: BAR=3 offset=00002000
    Capabilities: [100 v1] Advanced Error Reporting
    UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
    UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
    UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
    CESta: RxErr+ BadTLP+ BadDLLP- Rollover- Timeout+ NonFatalErr+
    CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
    AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
    Capabilities: [140 v1] Device Serial Number 00-22-4d-ff-ff-a0-2f-6a
    Kernel driver in use: e1000e


    e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-NAPI
    e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
    e1000e 0000:01:00.0: Disabling ASPM L0s L1
    e1000e 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
    e1000e 0000:01:00.0: setting latency timer to 64
    e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
    e1000e 0000:01:00.0: Interrupt Mode set to 1
    e1000e 0000:01:00.0: irq 42 for MSI/MSI-X
    e1000e 0000:01:00.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:22:4d:a0:2f:6a
    e1000e 0000:01:00.0: eth0: Intel(R) PRO/1000 Network Connection
    e1000e 0000:01:00.0: eth0: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF


    Aug 22 16:50:10 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:10 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:11 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:11 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:13 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:13 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:15 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:15 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:17 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:17 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:19 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:19 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:21 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:21 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:23 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:23 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:25 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:25 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:25 localhost kernel: : e1000e 0000:01:00.0: eth0: Detected Hardware Unit Hang:
    Aug 22 16:50:27 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:27 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:29 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:29 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:29 localhost kernel: : e1000e 0000:01:00.0: eth0: Detected Hardware Unit Hang:
    Aug 22 16:50:31 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:31 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:33 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:33 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:33 localhost kernel: : e1000e 0000:01:00.0: eth0: Detected Hardware Unit Hang:
    Aug 22 16:50:33 localhost kernel: : e1000e 0000:01:00.0: eth0: Reset adapter unexpectedly
    Aug 22 16:50:33 localhost kernel: : e1000e 0000:01:00.0: eth0: Master requests are pending.
    Aug 22 16:50:33 localhost kernel: : e1000e 0000:01:00.0: eth0: PCI-E Master disable polling has failed.
    Aug 22 16:50:33 localhost kernel: : e1000e 0000:01:00.0: eth0: Masking off all interrupts
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Issuing a global reset to MAC
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Initializing the IEEE VLAN
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Programming MAC Address into RAR[0]
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Clearing RAR[1-14]
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Zeroing the MTA
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: After fix-ups FlowControl is now = 3
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Reconfiguring auto-neg advertisement params
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: autoneg_advertised 2f
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Advertise 10mb Half duplex
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Advertise 10mb Full duplex
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Advertise 100mb Half duplex
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Advertise 100mb Full duplex
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Advertise 1000mb Full duplex
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Auto-Neg Advertising de1
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Restarting Auto-Neg
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Unable to establish link!!!
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Initializing the Flow Control address, type and timer regs
    Aug 22 16:50:34 localhost kernel: : e1000e 0000:01:00.0: eth0: Phy info is only valid if link is up
    Aug 22 16:50:37 localhost kernel: : e1000e 0000:01:00.0: eth0: hw->fc.current_mode = 3
    Aug 22 16:50:37 localhost kernel: : e1000e 0000:01:00.0: eth0: Flow Control = FULL.
    Aug 22 16:50:37 localhost kernel: : e1000e 0000:01:00.0: eth0: 1000 Mbps, Full Duplex
    Aug 22 16:50:37 localhost kernel: : e1000e 0000:01:00.0: eth0: hw->fc.current_mode = 3
    Aug 22 16:50:37 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:37 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:50:37 localhost kernel: : e1000e 0000:01:00.0: eth0: 1000 Mbps, Full Duplex
    Aug 22 16:50:37 localhost kernel: : e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
    Aug 22 16:50:39 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:50:39 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    ...
    Aug 22 16:51:55 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:51:55 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:51:55 localhost kernel: : e1000e 0000:01:00.0: eth0: Detected Hardware Unit Hang:
    Aug 22 16:51:57 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:51:57 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:51:59 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:51:59 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:51:59 localhost kernel: : e1000e 0000:01:00.0: eth0: Detected Hardware Unit Hang:
    Aug 22 16:52:01 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:52:01 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:52:02 localhost kernel: : e1000e 0000:01:00.0: eth0: Reset adapter unexpectedly
    Aug 22 16:52:02 localhost kernel: : e1000e 0000:01:00.0: eth0: Master requests are pending.
    Aug 22 16:52:02 localhost kernel: : e1000e 0000:01:00.0: eth0: PCI-E Master disable polling has failed.
    Aug 22 16:52:02 localhost kernel: : e1000e 0000:01:00.0: eth0: Masking off all interrupts
    Aug 22 16:52:02 localhost kernel: : e1000e 0000:01:00.0: eth0: Issuing a global reset to MAC
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Initializing the IEEE VLAN
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Programming MAC Address into RAR[0]
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Clearing RAR[1-14]
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Zeroing the MTA
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: After fix-ups FlowControl is now = 3
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Reconfiguring auto-neg advertisement params
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: autoneg_advertised 2f
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Advertise 10mb Half duplex
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Advertise 10mb Full duplex
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Advertise 100mb Half duplex
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Advertise 100mb Full duplex
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Advertise 1000mb Full duplex
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Auto-Neg Advertising de1
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Restarting Auto-Neg
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Unable to establish link!!!
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Initializing the Flow Control address, type and timer regs
    Aug 22 16:52:03 localhost kernel: : e1000e 0000:01:00.0: eth0: Phy info is only valid if link is up
    Aug 22 16:52:06 localhost kernel: : e1000e 0000:01:00.0: eth0: hw->fc.current_mode = 3
    Aug 22 16:52:06 localhost kernel: : e1000e 0000:01:00.0: eth0: Flow Control = FULL.
    Aug 22 16:52:06 localhost kernel: : e1000e 0000:01:00.0: eth0: 1000 Mbps, Full Duplex
    Aug 22 16:52:06 localhost kernel: : e1000e 0000:01:00.0: eth0: hw->fc.current_mode = 3
    Aug 22 16:52:06 localhost kernel: : e1000e 0000:01:00.0: rpm_resume flags 0x0
    Aug 22 16:52:06 localhost kernel: : e1000e 0000:01:00.0: rpm_resume returns 1
    Aug 22 16:52:06 localhost kernel: : e1000e 0000:01:00.0: eth0: 1000 Mbps, Full Duplex
    Aug 22 16:52:06 localhost kernel: : e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-08-22

    • assigned_to: Todd Fujinaka
     
  • Todd Fujinaka
    Todd Fujinaka
    2013-08-22

    We're getting a board to look at. It may take a couple of days to build up, but we have this set for local repro.

     
  • prz
    prz
    2013-08-22

    Todd, thanks, impressive, I assume Intel somehow sets you right for that kind of support. If you need any more info please do ping me.

    I tried 64bit distros (same problem) and tried to get MMU out the picture but the kernel bulked & would not compile.

    f19 has the same issue as well (not surprised, they're on 2.0.0 or so only)

    As fasr I saw, all e1000e up to the newest ones incl. Intel official downloads have the problem.

    Otherwise the board would be ok, I don't need graphics (purely embedded product) but the Ether is a killer for me.

    Sorry I slightly lost it, Intel makes the best stuff & I pay for it & it already took me on the 525MW 2 days to figure out issues so when I was forced onto those MUD2 I kind of snapped. well, sorry again.

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-08-22

    Just to be complete, can you tell me what hardware you have added to the board? How much memory, what drives, etc?

     
  • prz
    prz
    2013-09-01

    so, any news on this front ?

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-09-01

    We just got the RAM on Friday and Fedora 19 loads fine. I'm doing all the updates to the packages over the weekend over the network and, being a US company, we're not expected back until Tuesday (Monday is a holiday).

    I'm not sure what the differences in my system are that it is not having problems. The problem areas I'd look at are BIOS version, amount of RAM (mine is maxed out at 4G), and whether you're really loading a 32-bit kernel because of the Atom processor.

    Do you have any custom apps? Are they compiled for a 32-bit kernel?

     
  • prz
    prz
    2013-09-01

    Todd, 2GB RAM, Kingston/Corsair, something like this, 64GB SSD Sandisk
    Sata III, so all very plain.

    I loaded 32bit F19 & 64bit F19 & both had same problem. I also tried 2
    different netgear switches, all same problem. Older Intel Atom board
    with Realtek on this ethernet works 100% fine.

    No apps whatsoever after original install. The problem persisted over
    2.6.39, Fedoras & Ubuntu so it's very consistent.

    Can you really operate the e1000e fine & ssh & ftp & e'thing ? Mine
    under F19 only gets DHCP & under first traffic packet load just drops
    the line & the kernel resets it & so on
    ad inifinitum.

    Let's hope it's not a bad board which I never had from Intel. I put an
    USB ethernet into it & that works perfectly fine (but I can't deliver
    stuff that way obviously)

     
  • prz
    prz
    2013-09-01

    ah, and yeah, newest BIOS (which didn't make a difference either)

     
  • prz
    prz
    2013-09-01

    to be sure flipped mmeory modules & gave the ethernet board mount a good push. Booted ubuntu, exactly same behavior so I think I have all variables wrung out except a faulty board

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-09-03

    I'm running Fedora 19 and the gui doesn't work properly. From a text console, I was able to update to the newest packages (via Ethernet). I removed half of the memory and am running line-rate tx/rx tests.

    At this point I can't get it to fail. I would suggest contacting support@intel.com to replace your board, but you may also want to run a memory test as well.

    Unless you have further questions, I'd like to close this issue.

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-09-03

    Just as an addendum, it looks like it's not keeping up on Transmitting line rate, but I'm not going to look into that right now.

     
  • prz
    prz
    2013-09-03

    Todd, thanks much. I changed memory modules, same problem. Don't have time to debug boards or order new ones. I will just assume it's buggy & throw it into the pile of junk here.

    Saw that Intel is getting out of mainboard business as well so I'm actually looking @ competitive products after this mess & probably settle on an ASRock (anything BUT Intel's networking chip) or something if it holds up under tests.

    thanks again.

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-09-03

    • status: open --> closed
     
  • Todd Fujinaka
    Todd Fujinaka
    2013-09-03

    I'm not sure why you think it is the networking part, and support will get you a replacement board. Most of the problems with the 82574L have been addressed in the driver though there is one in the queue due to BIOS workarounds. The reason it pops up so often in bug reports is due to its ubiquity.

    I'll close this issue.

     
  • Todd Fujinaka
    Todd Fujinaka
    2013-09-04

    Just for completeness, I tried Fedora 18 and I had no problems there as well. Network is fine out-of-box and allowed a yum update with no issues. The transmit seems constrained (~280Mbps) but otherwise works fine.

     
  • prz
    prz
    2013-09-05

    thanks, Todd. The only likely possibility seems a faulty board then.