From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 17FC11B1F8; Fri, 10 Nov 2017 03:11:06 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2017 18:11:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,371,1505804400"; d="scan'208";a="382651" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.241.224.59]) ([10.241.224.59]) by FMSMGA003.fm.intel.com with ESMTP; 09 Nov 2017 18:11:04 -0800 From: Ferruh Yigit To: gregory@weka.io Cc: Chas Williams <3chas3@gmail.com>, Thomas Monjalon , stable@dpdk.org, dev@dpdk.org, Jianfeng Tan , Jingjing Wu , Shijith Thotton , Harish Patil , George Prekas , Sergio Gonzalez Monroy , Rasesh Mody , Lee Roberts , Stephen Hemminger References: <20171103223822.28852-1-ferruh.yigit@intel.com> <2004961.P5XXAOnQC2@xps> <1866566.0zvbrY6xpu@polaris> <0465168a-d7ce-8589-1f34-cf905f7069f6@intel.com> Message-ID: Date: Thu, 9 Nov 2017 18:11:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <0465168a-d7ce-8589-1f34-cf905f7069f6@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [dpdk-stable] ugb_uio: r3.8xlarge bind failure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 02:11:07 -0000 On 11/9/2017 5:42 PM, Ferruh Yigit wrote: > On 11/9/2017 9:20 AM, Gregory Etelson wrote: >> Hello, >> >> There are some AWS R3.8XLARGE instances >> that fail to bind Intel 10G VFs with igb_uio [c05cb4f939082]. > > Hi Gregory, > > Will you dig this issue more? Please keep us updated. > >> System dmeg log show this backtrace: >> >> igb_uio: probe of 0000:00:05.0 failed with error -16 >> IRQ handler type mismatch for IRQ 0 >> current handler: timer >> Pid: 3619, comm: bash Not tainted 2.6.32-642.15.1.el6.x86_64 #1 >> Call Trace: >> [] ? __setup_irq+0x382/0x3c0 >> [] ? uio_interrupt+0x0/0x48 [uio] >> [] ? request_threaded_irq+0x133/0x230 >> [] ? __uio_register_device+0x553/0x610 [uio] >> [] ? igbuio_pci_probe+0x290/0x47a [igb_uio] Here igb_uio probe() calls request_irq(), this behavior changed in latest code. Can you please double check that you are using latest code? Thanks, ferruh >> [] ? kobject_get+0x1a/0x30 >> [] ? local_pci_probe+0x17/0x20 >> [] ? pci_device_probe+0x101/0x120 >> [] ? driver_sysfs_add+0x62/0x90 >> [] ? driver_probe_device+0xaa/0x3a0 >> [] ? driver_bind+0xca/0x110 >> [] ? drv_attr_store+0x2c/0x30 >> [] ? sysfs_write_file+0xe5/0x170 >> [] ? vfs_write+0xb8/0x1a0 >> [] ? fget_light_pos+0x16/0x50 >> [] ? sys_write+0x51/0xb0 >> >> The VFs can be returned back to kernel ixgbevf driver with no faults. >> >> The instances can bind VFs with igb_uio[b58eedfc7dd57] >> >> I could not find yet why some R3.8XLARGE instances can bind IXGBE VFs with >> igb_uio while other fail >> >> lspci -vvv -s 0000:00:05.0 >> 00:05.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller >> Virtual Function (rev 01) >> Physical Slot: 5 >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >> SERR- > Latency: 64 >> Region 0: Memory at f3010000 (64-bit, prefetchable) [size=16K] >> Region 3: Memory at f3014000 (64-bit, prefetchable) [size=16K] >> Capabilities: [70] MSI-X: Enable+ Count=3 Masked- >> Vector table: BAR=3 offset=00000000 >> PBA: BAR=3 offset=00002000 >> Kernel driver in use: ixgbevf >> Kernel modules: ixgbevf >> >> Regards, >> Gregory >> >