Re: [E1000-devel] e1000e 3.9-rc1 suspend failure (was: Re: e1000e: nic does not work properly after cold power on)

> -Original Message- > From: Mihai Donțu [mailto:mihai.do...@gmail.com] > Sent: Monday, March 04, 2013 2:59 PM > To: Morten Stevens > Cc: e1000-devel@lists.sourceforge.net; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; Rafael J. Wysocki; Borislav Petkov; Jiri Slaby > Subject: Re:

Re: [E1000-devel] Bug#702245: Thinkpad T410s cannot detect link

> -Original Message- > From: YunQiang Su [mailto:wzss...@gmail.com] > Sent: Monday, March 04, 2013 7:58 AM > To: Ben Hutchings > Cc: e1000-devel@lists.sourceforge.net; 702...@bugs.debian.org > Subject: Re: [E1000-devel] Bug#702245: Thinkpad T410s cannot detect link > > On Mon, Mar 4, 2013

Re: [E1000-devel] [PATCH RESEND 1/3] e1000e: fix pci-device enable-counter balance

On Mon, 2013-02-25 at 09:19 +0400, Konstantin Khlebnikov wrote: > This patch removes redundant and unbalanced pci_disable_device() from > __e1000_shutdown(). pci_clear_master() is enough, device can go into > suspended state with elevated enable_cnt. > > Bug was introduced in commit 23606cf5d1192c

Re: [E1000-devel] [PATCH RESEND 3/3] e1000e: fix accessing to suspended device

On Mon, 2013-02-25 at 09:19 +0400, Konstantin Khlebnikov wrote: > This patch fixes some annoying messages like 'Error reading PHY > register' and > 'Hardware Erorr' and saves several seconds on reboot. > > Signed-off-by: Konstantin Khlebnikov > Acked-by: Rafael J. Wysocki > Cc: e1000-devel@lists

Re: [E1000-devel] [PATCH RESEND 2/3] e1000e: fix runtime power management transitions

On Mon, 2013-02-25 at 09:19 +0400, Konstantin Khlebnikov wrote: > This patch removes redundant actions from driver and fixes its > interaction > with actions in pci-bus runtime power management code. > > It removes pci_save_state() from __e1000_shutdown() for normal > adapters, > PCI bus callbacks

Re: [E1000-devel] Uhhuh. NMI received for unknown reason 2c on CPU 0.

[+cc e1000-devel, Jeff, Bruce] On Mon, Mar 4, 2013 at 2:50 PM, Borislav Petkov wrote: > On Fri, Feb 15, 2013 at 10:16:41AM +0100, Borislav Petkov wrote: >> So it looks Bjorn has taken most of them and the e1000e one will go >> through the e1000e maintainers. I'll test after the merge window is >>

Re: [E1000-devel] ixgbe - lan id needs to be set after the port swap check ?

The reason the lan_id variable exist at all is so we can store the func value regardless of the FACTPS LAN Function Sel does to it. You can think of func as a logical value and lan_id as a physical. We need to keep this value since the init of the SFP+ PHYs is different based on which physical

Re: [E1000-devel] 82574L Gig E Adapter not recognized by OpenSUSE kernel 3.8.0-28-desktop

> -Original Message- > From: Bruce Ferrell [mailto:bferr...@baywinds.org] > Sent: Sunday, March 03, 2013 9:49 AM > To: e1000-devel@lists.sourceforge.net > Subject: [E1000-devel] 82574L Gig E Adapter not recognized by OpenSUSE kernel > 3.8.0-28-desktop > > Any suggestions folks? Do I have

[E1000-devel] Re-2: e1000e detected hardware unit hang problem

Hello Tushar, first of all. Thanks for Your quick reply. That's the point. I don't know why this occurs. If I have the chance I see a failure of the e1000e driver on the console. The server is completly down and I can't logon to get any other information. The error isn't logged at dmesg.log or

Re: [E1000-devel] e1000e 3.9-rc1 suspend failure (was: Re: e1000e: nic does not work properly after cold power on)

On Mon, 4 Mar 2013 22:48:30 +0100 Borislav Petkov wrote: > On Mon, Mar 04, 2013 at 07:15:07PM +0100, Morten Stevens wrote: > > Can you reproduce this with linux 3.9-rc1? 3.9-rc1 has the latest > > upstream driver (e1000e 2.2.14) which contains many bugfixes. > On my system (ThinkPad T420) I get:

Re: [E1000-devel] [RFC PATCH 0/5] net: low latency Ethernet device polling

On Wed, 2013-02-27 at 21:17 +0200, Eliezer Tamir wrote: > On 27/02/2013 20:47, Tom Herbert wrote: > > On Wed, Feb 27, 2013 at 10:13 AM, Stephen Hemminger > > wrote: > >> > >> Have you looked at netmap? Seems like a cleaner user API for this. > >> > > That might be a bit orthogonal to this. I beli

Re: [E1000-devel] e1000e detected hardware unit hang problem

Lars, Sorry that you have issue with board. Please always send your email to or CC to e1000-devel@lists.sourceforge.net. What is the device? lspci -vvv (after issue occurs) Send full dmesg log after issue occurs. How quick does the issue occurs? Any repro

[E1000-devel] e1000e 3.9-rc1 suspend failure (was: Re: e1000e: nic does not work properly after cold power on)

On Mon, Mar 04, 2013 at 07:15:07PM +0100, Morten Stevens wrote: > Can you reproduce this with linux 3.9-rc1? 3.9-rc1 has the latest > upstream driver (e1000e 2.2.14) which contains many bugfixes. This e1000e thing gets more b0rked by the minute. This is what happens when I try to suspend with 3.9-

Re: [E1000-devel] [PATCH] ixgbevf: don't release the soft entries

On Fri, 1 Mar 2013 09:58:35 +0800 xunleer wrote: [snip] > > > Greg, > thanks for your advice, that's what exactly what i want to say, i'll > resubmit the patch. it's my first time to do this, thanks again. Li, the patch you submitted has failed internal testing here at Intel. Your patch is a

Re: [E1000-devel] Verifying that disabled K1 power state in Gigabit is in effect

Jon, 82579 is e1000e driver and not e1000. Getting to the issue, what is the motherboard? Are you running the latest BIOS? -Tushar >-Original Message- >From: Jon Nordby [mailto:j...@sqhead.com] >Sent: Monday, March 04, 2013 7:35 AM >To: e1000-devel@lists.sourceforge.net >Subject: [E1000

[E1000-devel] ixgbe - lan id needs to be set after the port swap check ?

Hello, While looking into the function 'ixgbe_set_lan_id_multi_port_pcie', it seemed like 'bus->lan_id' needs to be set after the port swap check. I might be missing some detail here as setting 'bus->lan_id' before port swap check may be by design. If it is an issue, please consider applying th

Re: [E1000-devel] 82574L Gig E Adapter not recognized by OpenSUSE kernel 3.8.0-28-desktop

So exactly what is the problem? The e1000e driver loaded into the system and looks to be associated with an interface from the dmesg output. Are you sure it's not eth0? Is this a dual port NIC? What does 'ifconfig -a' show? How about 'lsmod'? and all the output from 'lspci -vv'? Cheers,

Re: [E1000-devel] [RFC PATCH 0/5] net: low latency Ethernet device polling

On Wed, 27 Feb 2013 09:55:49 -0800 Eliezer Tamir wrote: > This patchset adds the ability for the socket layer code to poll directly > on an Ethernet device's RX queue. This eliminates the cost of the interrupt > and context switch and with proper tuning allows us to get very close > to the HW la

[E1000-devel] Verifying that disabled K1 power state in Gigabit is in effect

Hi, we are experiencing some packet losses with the Intel 82579 (on a Compulab Intense PC) when running in Gb mode, both when running 2.6.32 and 3.8. Losses are typically 40 packets/minute when running UDP traffic at about 250Mbit/s. Some investigation show that the chip going in and out of K1 p

Re: [E1000-devel] [RFC PATCH 1/5] net: implement support for low latency socket polling

On Mon, 2013-03-04 at 17:28 +0200, Eliezer Tamir wrote: > On 04/03/2013 16:52, Eric Dumazet wrote: > > On Mon, 2013-03-04 at 10:43 +0200, Eliezer Tamir wrote: > > > >> One could for example increment the generation id every time the RTNL is > >> taken. or is this too much? > > > > RTNL is taken for

Re: [E1000-devel] Bug#702245: Thinkpad T410s cannot detect link

On Mon, Mar 4, 2013 at 9:47 PM, Ben Hutchings wrote: > Control: tag -1 upstream > Control: forwarded -1 e1000-devel@lists.sourceforge.net > > On Mon, 2013-03-04 at 20:58 +0800, YunQiang Su wrote: >> Package: linux >> Version: 3.8-1~experimental.1 >> >> After upgrade to 3.8-1~experimental.1, my Thi

Re: [E1000-devel] [RFC PATCH 1/5] net: implement support for low latency socket polling

On 04/03/2013 16:52, Eric Dumazet wrote: > On Mon, 2013-03-04 at 10:43 +0200, Eliezer Tamir wrote: > >> One could for example increment the generation id every time the RTNL is >> taken. or is this too much? > > RTNL is taken for a lot of operations, it would be better to have a > finer grained inc

Re: [E1000-devel] e1000e: nic does not work properly after cold power on

On 03/04/2013 11:46 AM, Mihai Donțu wrote: > Hi, > > I apologize in advance for posting on two lists at once and for not > even being subscribed to e1000-devel. > > Ever since upgrading to 3.8.x, I'm unable to use my wired connection > (e1000e - Intel Corporation 82579LM Gigabit) immediately afte

Re: [E1000-devel] [RFC PATCH 1/5] net: implement support for low latency socket polling

On Mon, 2013-03-04 at 10:43 +0200, Eliezer Tamir wrote: > One could for example increment the generation id every time the RTNL is > taken. or is this too much? RTNL is taken for a lot of operations, it would be better to have a finer grained increment. ---

Re: [E1000-devel] Bug#702245: Thinkpad T410s cannot detect link

Control: tag -1 upstream Control: forwarded -1 e1000-devel@lists.sourceforge.net On Mon, 2013-03-04 at 20:58 +0800, YunQiang Su wrote: > Package: linux > Version: 3.8-1~experimental.1 > > After upgrade to 3.8-1~experimental.1, my Thinkpad T410s cannot detect > cable link now. > While it works wel

[E1000-devel] e1000e: nic does not work properly after cold power on

Hi, I apologize in advance for posting on two lists at once and for not even being subscribed to e1000-devel. Ever since upgrading to 3.8.x, I'm unable to use my wired connection (e1000e - Intel Corporation 82579LM Gigabit) immediately after power on. I have to boot into an older kernel (3.2.0 I

Re: [E1000-devel] ixgbe MTU change

Hi Kyle, Regarding "We suspect the image artifacts were due to dropped packets.", you should be seeing any dropped packets in the stats. Both from the stack as well as from our HW. You'll need to check both to see where the packets are being dropped or if they are being dropped at all (maybe

Re: [E1000-devel] [RFC PATCH 0/5] net: low latency Ethernet device polling

On 04/03/2013 09:37, Cong Wang wrote: > On 02/28/2013 01:55 AM, Eliezer Tamir wrote: >> >> Open issues: >> 1. Find a way to avoid the need to change the sk and skb structs. >> One big disadvantage of how we do this right now is that when a device is >> removed, it's hard to prevent it from getting

Re: [E1000-devel] [RFC PATCH 0/5] net: low latency Ethernet device polling

>>> >> >> >> A dumb question: is bypassing tcpdump/netfilters/qdisc etc. what we >> always want? Isn't this a security issue? > > We are not bypassing any of the regular stack checks/hooks, we call the > normal netif_rx_skb(). correction, netif_receive_skb() --

Re: [E1000-devel] [RFC PATCH 1/5] net: implement support for low latency socket polling

On 03/03/2013 20:35, Eric Dumazet wrote: > On Wed, 2013-02-27 at 09:55 -0800, Eliezer Tamir wrote: > >> index 821c7f4..d1d1016 100644 >> --- a/include/linux/skbuff.h >> +++ b/include/linux/skbuff.h >> @@ -408,6 +408,10 @@ struct sk_buff { >> struct sock *sk; >> struct net_devi