From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gopakumar Choorakkot Edakkunni Subject: Re: ethtool doesnt work on some interface after unbinding dpdk Date: Fri, 15 Apr 2016 15:56:27 -0700 Message-ID: References: <570F4383.7040003@intel.com> <57109D32.70506@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: dev@dpdk.org To: Remy Horton Return-path: Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by dpdk.org (Postfix) with ESMTP id A3460475E for ; Sat, 16 Apr 2016 00:56:28 +0200 (CEST) Received: by mail-io0-f182.google.com with SMTP id o126so148823931iod.0 for ; Fri, 15 Apr 2016 15:56:28 -0700 (PDT) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Well, I jumped to a conclusion too soon on the ACPI, that was a wrong statement (wishful thinking), I recreated the issue even with ACPI off This time the problem statement is more narrowed down. 1. dpdk is enabled on the interface, interfaces bound to igb_uio 3. kill the process using dpdk 3. rmmod rte_kni 4. rmmod igb_uio 5. bind interface to igb 6. ethtool, ifconfig up/down etc.. works for approximately 30 seconds, and then stops working At step #6, if I do an lspci of the device, the device is completely shut down (attached a sample lspci output - memory not initialized, irqs not present in /proc/interrupts etc..). But theres nothing in the dmesg that shows any kind of errors after the messages about the interface being bound in step #5 And the wierd part is that the device is up at step #6 for like 30 seconds before it appears shut down in the pci output. Another observation is that in step #4 when igb_uio relinquishes control of the device it still seems to leave it in an initialized state, so the only theory I can think of is whether the device being left in an initia;ized state when it was handed off to igb in step #5 caused igb to run into some error and shut down the device ? The next step is to enable debugs in igb driver and see if there are any debugs that tells more about what happened Rgds, Gopa. On Fri, Apr 15, 2016 at 12:31 PM, Gopakumar Choorakkot Edakkunni < gopakumar.c.e@gmail.com> wrote: > So looks like I figured it out .. I came across this bug reference > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728692 and thought of > checking out my problem with ACPI turned off. And with ACPI turned off, the > problem doesnt happen. So theres something that the igb driver is not happy > about when acpi is on .. Any thoughts ? > > Rgds, > Gopa. > > On Fri, Apr 15, 2016 at 10:38 AM, Gopakumar Choorakkot Edakkunni < > gopakumar.c.e@gmail.com> wrote: > >> Nothing in dmesg .. The ethtool was just a side-observation, the biggest >> problem was that after unbinding from igb_uio and rebinding to igb, if I >> follow it up with an /etc/init.d/network restart, that completely hoses the >> linux system - anyone trying to open a socket (ifconfig for example) just >> hangs. Thats how I started troubleshooting this and happened to see this >> ethtool thing along with it, not sure if its related. Also the issue >> doesn't happen with one or two interfaces, there needs to be at least five >> or six interfaces for this to happen. >> >> The other thing I noticed is that if I put some sleep (2 seconds) between >> unbind igb_uio and re-bind igb, the network-restart-hosing-system doesnt >> happen, but the ethtool issue still remains >> >> Rgds, >> Gopa. >> >> On Fri, Apr 15, 2016 at 12:50 AM, Remy Horton >> wrote: >> >>> On 14/04/2016 20:25, Gopakumar Choorakkot Edakkunni wrote: >>> [..] >>> >>>> ge8-----> 06:00.0 Ethernet controller: Intel Corporation 82576 Gigabit >>>> Network Connection (rev 01) >>>> >>>> root:~# ls /sys/class/net/ge8/device/driver/module/drivers/ >>>> pci:igb >>>> root:~# >>>> >>>> root:~# ethtool ge8 >>>> Settings for ge8: >>>> Cannot get device settings: No such device >>>> Cannot get wake-on-lan settings: No such device >>>> Cannot get message level: No such device >>>> Cannot get link status: No such device >>>> No data available >>>> >>> >>> Seems a little odd. Does dmesg show anything related to igb/ixgbe when >>> you try this? >>> >>> ..Remy >>> >> >> >