From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 59AE4593E for ; Thu, 16 Oct 2014 11:30:22 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 16 Oct 2014 02:38:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,731,1406617200"; d="scan'208";a="619759486" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga002.jf.intel.com with ESMTP; 16 Oct 2014 02:38:08 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.175]) by IRSMSX101.ger.corp.intel.com ([169.254.1.201]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 10:37:06 +0100 From: "Richardson, Bruce" To: Lilijun , "dev@dpdk.org" , "stephen@networkplumber.org" Thread-Topic: [dpdk-dev] kernel panic when stop my test demo Thread-Index: AQHP56ZUPvztkWlRV0KpOUEmoRcWZ5ww2LQAgAAXPbCAAQT+AIAAhGMQ Date: Thu, 16 Oct 2014 09:37:06 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B03441F544@IRSMSX103.ger.corp.intel.com> References: <20130813225821.3e23ad90@nehalam.linuxnetplumber.net> <543D0FF3.6020306@huawei.com> <543E419A.70509@huawei.com> <59AF69C657FD0841A61C55336867B5B03441EDC0@IRSMSX103.ger.corp.intel.com> <543F3008.4040800@huawei.com> In-Reply-To: <543F3008.4040800@huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] kernel panic when stop my test demo X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 09:30:22 -0000 > -----Original Message----- > From: Lilijun [mailto:jerry.lilijun@huawei.com] > Sent: Thursday, October 16, 2014 3:40 AM > To: Richardson, Bruce; dev@dpdk.org; stephen@networkplumber.org > Subject: Re: [dpdk-dev] kernel panic when stop my test demo >=20 > On 2014/10/15 18:08, Richardson, Bruce wrote: > > > > > >> -----Original Message----- > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Lilijun > >> Sent: Wednesday, October 15, 2014 10:43 AM > >> To: dev@dpdk.org; stephen@networkplumber.org > >> Subject: Re: [dpdk-dev] kernel panic when stop my test demo > >> > >> Hi all, > >> > >> After adding unmap uio resources operations in process signal handler > functions, > >> An new error was found as follows: > >> Call Trace: > >> [] uio_release+0x40/0x60 [uio] > >> [] __fput+0xe9/0x270 > >> [] ____fput+0xe/0x10 > >> [] task_work_run+0xa7/0xe0 > >> [] do_notify_resume+0x97/0xb0 > >> [] int_signal+0x12/0x17 > >> > >> The code for unmap uio resources is shown: > >> static void pci_dev_uio_unmap(struct rte_pci_device *pci_dev, uint8_t > port_id) > >> { > >> int i; > >> > >> RTE_LOG(INFO, EAL, "begin unmap port %d uio resource! \n", por= t_id); > >> if (NULL =3D=3D pci_dev) > >> { > >> RTE_LOG(ERR, EAL, "begin unmap port %d uio resource! \= n", > port_id); > >> return; > >> } > >> > >> for (i =3D 0; i !=3D PCI_MAX_RESOURCE; i++) > >> { > >> /* skip empty BAR */ > >> if (0 =3D=3D pci_dev->mem_resource[i].phys_addr) > >> continue; > >> if (munmap(pci_dev->mem_resource[i].addr, pci_dev- > >>> mem_resource[i].len) > >> = =3D=3D -1){ > >> RTE_LOG(ERR, EAL, "Error with munmap\n"); > >> return; > >> } > >> } > >> if (close(pci_dev->intr_handle.fd) =3D=3D -1){ > >> RTE_LOG(ERR, EAL, "Error closing interrupt handle\n"); > >> return; > >> } > >> pci_dev->intr_handle.type =3D RTE_INTR_HANDLE_UNKNOWN; > >> RTE_LOG(INFO, EAL, "unmap port %d uio resource successfully!\n= ", > >> port_id); > >> } > >> > >> Does anyone has some ideas? > >> > >> Thanks for any help. > >> Jerry > >> > >> On 2014/10/14 19:58, Lilijun wrote: > >>> Hi Stephen and all, > >>> > >>> I have a same problem as this older email describes on Aug 14, 2013. > >>> Any help will be appreciated. > >>> > >>> The details is shown as follows. > >>> The key step implementation of my demo is: > >>> 1. Firstly, call rte_eal_init() to do some initialization. > >>> 2. Switch the driver of my Intel 82599 NIC from ixgbe.ko to igb_uio.= ko > >>> like tools/dpdk_nic_bind.py written in C source code. > >>> 3. Configure rte_dev and start it. > >>> 4. Do some rx/tx tests. > >>> 5. call rte_eth_dev_stop(dpdk_port_id) to stop the hardware as your h= istory > >> emails. > >>> 6. Switch the driver of the NIC from igb_uio.ko to ixgbe.ko. > >>> 7. Kill the demo using commands: kill -9. > > > > Just to clarify one point - you have an application running which was u= sing the > NICs with DPDK while you remove the uio driver and replace it with ixgbe? > I would expect doing such a thing to cause problems as stopping the devic= e does > not cause the NIC BAR memory to be unmapped from the DPDK process. > Therefore removing the driver providing that memory map and getting anoth= er > driver to start using those same BARs would not be recommended. > > >=20 > Thanks for your reply. > Yes, I want to change the NIC driver by replacing the uio driver with ixg= be in > order to recover the NIC to origin kernel ether-net devices while keeping= the > application running. > Then my application can use the NICs with DPDK or with kernel ixgbe drive= r on > demand. > I am confusing with how to release all uio resources when stop my applica= tion. >=20 > Would you like to give me any suggestions for my requirements? >=20 Right now, there is no way to do this without changing the internals of the= DPDK itself. The BARs from the NIC are mmapped permanently into the proces= ses address space on initialization of the application, and are never relea= sed. You'd basically need to write code to un-initialize the DPDK and then = reinitialize it at a later point. Might an alternative be to actually have two separate applications or binar= ies that appear as one, or work as one? Then you could shut down the dpdk b= inary before removing the uio driver, and switch over to the ixgbe driver a= nd use the other application. However, I realise that getting a seamless tr= ansition could be difficult there. /Bruce