Thanks Kirstian,

We'll take a look at this and try a repro here in our lab.  In the mean time 
can you please get us on EEPROM dump using ethtool for the device in question?  
We'd like to see if it is programmed correctly.  

Thanks.

Cheers,
John


> -----Original Message-----
> From: Kristian Kielhofner [mailto:[email protected]]
> Sent: Friday, September 28, 2012 8:24 PM
> To: Ronciak, John
> Cc: Dave, Tushar N; [email protected]
> Subject: Re: [E1000-devel] 82574L issues with e1000e
> 
> John,
> 
>   I have more detail for you.  I've been able to identify a single
> ethernet frame that (upon receipt) can cause this error.  The ethernet
> frame is attached (pod-t22.pcap).
> 
>   Technically speaking this frame contains an SDP syntax error
> (duplication) but that shouldn't matter to the e1000e/82574L components
> (all other frame params are correct).  When this pcap file is replayed
> the 82574L interface drops and loses link.
> 
>   I've hex-edited the frame to have correct SDP syntax.  This edited
> packet does not cause any errors and the NIC stays up.  This is the
> attached valid_sdp_edit.pcap
> 
>   The logs are here:
> 
> http://pastebin.com/TpvrHwmG
> 
>   It starts at system startup.  At line 68 the pod-t22.pcap frame is
> received.  At this point (as you can see) the hardware is irrecoverable
> until I physically power down the unit and power it back up.  Reboot
> and/or reloading the driver results in the errors starting at line 110.
> 
>   To be clear: a single receipt of pod-t22.pcap will kill the adapter
> until power-off.  Virtually all other traffic (including
> valid_sdp_edit.pcap) passes perfectly well.  Very strange.
> 
> Thanks!
> 
> On Thu, Sep 27, 2012 at 4:47 PM, Kristian Kielhofner
> <[email protected]> wrote:
> > John,
> >
> >   Yes, we have had the driver report NIC corruption regularly.  In
> > most cases the eeprom_fix script is able to restore these although
> > sometimes the EEPROM corruption returns.  We've actually had to build
> > a special version of the e1000e driver that allows the device to
> > initialize even when the EEPROM check fails.  This allows us to use
> > ethtool to restore the corrupted EEPROM.
> >
> >   The 82574L is on the motherboard (PCIe).  These aren't add-in
> cards.
> >  No other strange issues with the motherboards but then again these
> > are embedded headless systems - no sound, no VGA, etc.  Just ethernet
> > and SATA for the most part.
> >
> > On Thu, Sep 27, 2012 at 4:36 PM, Ronciak, John
> <[email protected]> wrote:
> >> Thanks Kristian,
> >>
> >> If you really are having the EEPROM corrupted this is highly
> unusual.
> >> The motherboards all look to have our devices down on them .  So
> they aren't really NIC's right? (i.e. plug in PCIe boards) Are you
> having power issues or something like that?  Are you seeing other
> strangeness with the motherboards?  Like other devices having issues?
> >>
> >> Cheers,
> >> John
> >
> > --
> > Kristian Kielhofner
> 
> 
> 
> --
> Kristian Kielhofner

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit 
http://communities.intel.com/community/wired

Reply via email to