Looking over the code it looks like there is only one spot where the
driver could be failing without displaying some sort of error message. 
That would be at the register_netdev call.

If you look in the netdev.c file you should be able to find a tag named
"err_register:".  It would greatly help with debugging if you could
modifying it by adding an e_err in the line after the tag.  With the
change the code should look something like this:

err_register:
        e_err("register_netdev returned %d\n", err);
        if (!(adapter 
<http://ladlxr.jf.intel.com/lxr/linux-2.6/ident?v=3.5;i=adapter>->flags 
<http://ladlxr.jf.intel.com/lxr/linux-2.6/ident?v=3.5;i=flags> & FLAG_HAS_AMT 
<http://ladlxr.jf.intel.com/lxr/linux-2.6/ident?v=3.5;i=FLAG_HAS_AMT>))        


If you could build and test that driver it will help to confirm if the
error is actually being returned from netdev_register and this is
resulting in everything being silently freed after being assigned.

Thanks,

Alex       

On 11/08/2012 10:57 AM, Mark Bidewell wrote:
> Yes,  In the working case the log looks like:
> Nov  3 12:26:00 cbidewell-desktop kernel: [    1.400831] e1000e 0000:00:19.0: 
> >irq 46 for MSI/MSI-X
> Nov  3 12:26:00 cbidewell-desktop kernel: [    1.705990] e1000e 0000:00:19.0: 
> >eth0: (PCI Express:2.5GT/s:Width x1) 00:1c:c0:60:ee:1e
> Nov  3 12:26:00 cbidewell-desktop kernel: [    1.705993] e1000e 0000:00:19.0: 
> >eth0: Intel(R) PRO/1000 Network Connection
> Nov  3 12:26:00 cbidewell-desktop kernel: [    1.706015] e1000e 0000:00:19.0: 
> >eth0: MAC: 7, PHY: 6, PBA No: FFFFFF-0FF
> Nov  3 12:26:00 cbidewell-desktop NetworkManager[860]: <info> (eth0): new 
> Ethernet device (driver: 'e1000e' ifindex: 2)
> Nov  3 12:26:01 cbidewell-desktop kernel: [   18.180366] e1000e 0000:00:19.0: 
> >irq 46 for MSI/MSI-X
> Nov  3 12:26:01 cbidewell-desktop kernel: [   18.284093] e1000e 0000:00:19.0: 
> >irq 46 for MSI/MSI-X 
> Nov 3 12:26:04 cbidewell-desktop kernel: [ 20.929802] e1000e: eth0 NIC
> Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx 
>
> lshw in the failure case shows the following:
> *-network UNCLAIMED
>              description: Ethernet controller
>              product: 82566DC-2 Gigabit Network Connection
>              vendor: Intel Corporation
>              physical id: 19
>              bus info: pci@0000:00:19.0
>              version: 02
>              width: 32 bits
>              clock: 33MHz
>              capabilities: pm msi cap_list
>              configuration: latency=0
>              resources: memory:e3200000-e321ffff memory:e3224000-e3224fff 
> ioport:3400(size=32)
>
>
> On Thu, Nov 8, 2012 at 1:52 PM, Alexander Duyck
> <[email protected] <mailto:[email protected]>> wrote:
>
>     Are you sure this is the failure case?  I ask since it seems like the
>     e1000e is claiming the device and assigning it irq 47 for use with MSI
>     based on the snippet from the log below.  I would have expected to see
>     an error stating that it failed to load the driver on the interface.
>
>     Thanks,
>
>     Alex
>
>     On 11/08/2012 10:31 AM, Mark Bidewell wrote:
>     > Thanks.  Here is the logging in the failure case:
>     > [    1.139788] e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
>     > [    1.139791] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
>     > [    1.139828] e1000e 0000:00:19.0: >setting latency timer to 64
>     > [    1.139899] e1000e 0000:00:19.0: >Interrupt Throttling Rate
>     (ints/sec) set to dynamic conservative mode
>     > [    1.139934] e1000e 0000:00:19.0: >irq 47 for MSI/MSI-X
>     > I have been tracking the issue with Ubuntu here:
>      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072722
>     >
>     >
>     > On Thu, Nov 8, 2012 at 1:04 PM, Alexander Duyck
>     > <[email protected]
>     <mailto:[email protected]>
>     <mailto:[email protected]
>     <mailto:[email protected]>>> wrote:
>     >
>     >     Mark,
>     >
>     >     I could recommend checking the dmesg log after you have
>     >     unloaded/reloaded the e1000e driver.  There is likely an
>     error that is
>     >     being reported that is preventing the driver from loading
>     and knowing
>     >     what the error is that is being reported would go a long way
>     toward
>     >     telling us what the issue is.
>     >
>     >     The difference between the working and non-working case is
>     likely
>     >     due to
>     >     the fact that the driver enables bus mastering and MSI
>     interrupts once
>     >     it is loaded.  In the case where it didn't load it will not have
>     >     enabled
>     >     bus mastering or MSI interrupts.
>     >
>     >     Thanks,
>     >
>     >     Alex
>     >
>     >     On 11/08/2012 08:29 AM, Mark Bidewell wrote:
>     >     > Thank you, that is what I suspect but since it worked up until
>     >     recently, I
>     >     > thought it would be good to check.  I tried to recovery
>     reflash
>     >     the BIOS
>     >     > after replacing the battery (I am already at the latest -
>     so no
>     >     update)  no
>     >     > way to know if it actually did the reflash.  Should the e1000e
>     >     be able to
>     >     > support the HW configuration in the non-working case (IRQ
>     20, no
>     >     MSI, no
>     >     > bus master)?  Because even when lspci reports IRQ 20, e1000e
>     >     still looks at
>     >     > 46.
>     >     >
>     >     > Thanks
>     >
>     > --
>     > Mark Bidewell
>     > http://www.linkedin.com/in/markbidewell
>
>
>
>
> -- 
> Mark Bidewell
> http://www.linkedin.com/in/markbidewell


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
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