From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.172]) by dpdk.org (Postfix) with ESMTP id 92FC358FA for ; Fri, 10 Mar 2017 17:16:26 +0100 (CET) Received: by mail-wr0-f172.google.com with SMTP id u108so67824722wrb.3 for ; Fri, 10 Mar 2017 08:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9vlPhUcQbRwbdot+2Hov/7RPRuXUYNvJboxD+Px5VGQ=; b=uDv+uaZedIB1Vz08vGDALFxaQ/vapprjA2w1X/lzG+KFKP54r8s+Nr54nsjHujl6NO T8WdTgKBTX1fNf2FFmllks+cumF78ju/36UGuBwX4GjnWWjqmtdmr907dZ3U3L3+M3WV th/kdAzVgcN6Or5foWTy3iFBPR/Q3/zyuSTwCeOT//Hhl1kPXoV4SUHID6vbulBp83wc cUY1vQuYkj4zg4DJhYIlDsWxkXPT3ARCvHa3iQcoqEOl/4T41IteZoDBUSxDLM+xAt6J F0jK372Fn+hiLcyzb6mTV7AGfHhxlwgBlssjCqYs+nbtPFj4scApfZTrrxveXdVxSRV6 C3Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9vlPhUcQbRwbdot+2Hov/7RPRuXUYNvJboxD+Px5VGQ=; b=EqUr8FdGspL2KP/WTFjryIuuluUvE1tEOlHWCsVUlCrAkYUwb83QejIAmn0187vI6d xpRgAYolBPU2D82JSE21sShEEHfajqE54TYjDgtnXwrYz6YPBsaJdV0WmEh6q9UkbSFc XB9vNxyqumoVRIOe6WSHujW5SBh62hfnHE1VJvOjh+uo1tQLFGlkv9LKUoSGsJUFGKx8 uXov8ZKR95GbuUgKRchLc+2naM07SyM2J/6XBdoPzJrD3XvZO04Y81iEm9/PHhqTVrS8 FlhD3EUbZtugRt8UvAS8cPV+JI2pWel48ozLujc8bkCBhmK8gs41O5wUyzDAoGsukQ8/ dwoQ== X-Gm-Message-State: AMke39nSa4LvHJAwnorMINC228KvWWaJ5bqbnXr+IFbRglrCYu2H98N2ym0etAzxYNTbNqk/BsMgBx9XoTOxtw== X-Received: by 10.223.162.212 with SMTP id t20mr15841691wra.122.1489162586374; Fri, 10 Mar 2017 08:16:26 -0800 (PST) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.211.20 with HTTP; Fri, 10 Mar 2017 08:16:25 -0800 (PST) In-Reply-To: <17a10461-122b-c6ad-ca44-f25b4cdb36c8@brocade.com> References: <17a10461-122b-c6ad-ca44-f25b4cdb36c8@brocade.com> From: Jan Blunck Date: Fri, 10 Mar 2017 17:16:25 +0100 X-Google-Sender-Auth: 37Mfdoz1FJntw72Ib_qNnTYoDQo Message-ID: To: Wen Chiu Cc: dev Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] dpdk 0005-net-bonding-reconfigure-all-slave-queues-every-time.patch issue 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 Mar 2017 16:16:26 -0000 On Thu, Mar 9, 2017 at 3:22 AM, Wen Chiu wrote: > Hi, > > 0005-net-bonding-reconfigure-all-slave-queues-every-time.patch is now > officially in dpdk 17.02. This is commit 1e2eff64f554 ("net/bonding: reconfigure all slave queues every time"). > But, it caused segmentation fault every time when > I configured bonding. In slave_configure(), "Setup Tx Queues" logic change > from for q_id=old_nb_tx_queues to qid=0 which always enters the for loop and > calls rte_eth_tx_queue_setup. After that, rte_eth_dev_start() is called to > start the device. In rte_eth_dev_start(), vmxnet3_dev_start() is called > which calls vmxnet3_dev_rxtx_init(). In vmxnet3_dev_rxtx_init(), after for > loop for rx_queues; dev->data->tx_queues[0] is override with value like > 0x121b20600 which is an invalid memory address that caused the fault. > > Without this 0005 patch, looks like rte_eth_tx_queue_setup() is never called > as q_id=old_nb_tx_queues never < nb_tx_queues. So, I suspect the calls to > queue_setup() somehow makes the queues to be setup incorrectly or > incompletely which causes the fault. So did the slave_configure() actually return an error? > Has anyone else encounters the same > issue? No, not with the device I tested with. > Regards, > > Wen Chiu > > >