netdev - Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c80563da-d4f7-5281-d692-d05f43fc80b6@synopsys.com>
Date:   Mon, 8 May 2017 12:40:18 +0100
From:   Joao Pinto <Joao.Pinto@...opsys.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Joao Pinto <Joao.Pinto@...opsys.com>
CC:     Jan Kiszka <jan.kiszka@...mens.com>,
        "David S. Miller" <davem@...emloft.net>,
        Giuseppe CAVALLARO <peppe.cavallaro@...com>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config
 for multiple queues

Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 1:42 PM, Joao Pinto <Joao.Pinto@...opsys.com> wrote:
>> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <Joao.Pinto@...opsys.com> wrote:
>>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
> 
>>>>> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
>>>>> got the following:
> 
>>>> Are you using the same version of Ethernet IP, 10/100?
>>>
>>> I'm running on Intel Galileo Gen2 board (v4.11 by the way works fine
>>> with direct boot from SD card)
>>>
>>>> Could you please verify if the crash you are experiencing is this place?
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2956&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0&s=yZu3uME5PK-3nJlxz-H-HfHh3Shjzg0je5If_jSXVb4&e=
>>>>
>>>> I would say that for rather old IPs, the napi is not capable of giving a valid
>>>> queue number. Could you please print the queue index returned by this line?
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2948&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0&s=p_TgHODJum23I2N4AldR4oIaOPffSDpk9agmbRMQgoM&e=
>>>
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> @@ -2953,7 +2953,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
>>> *skb, struct net_device *dev)
>>>        unsigned int enh_desc;
>>>        unsigned int des;
>>>
>>> +       pr_info("%s <<< 1: priv %p, queue: %u\n", __func__, priv, queue);
>>>        tx_q = &priv->tx_queue[queue];
>>> +       pr_info("%s <<< 2: priv %p, queue: %u tx_q: %p\n", __func__,
>>> priv, queue, tx_q);
>>>
>>>
>>> [  101.591040] stmmac_xmit <<< 1: priv cdd1c4c0, queue: 7
>>> [  101.596377] stmmac_xmit <<< 2: priv cdd1c4c0, queue: 7 tx_q: cdd1caac
> 
>> I assume that the queue index is always 7 right? By return 7, the napi interface
>> 'thinks' that your setup is using 8 TX queues which I assume it is not and thats
>> the problem causing your board to malfuntion.
>>
>> Could you please check the values of the 'real' tx and rx queues count in this line?
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n4107&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=6PN46fgWi1XTHkxFzV9wkYHPkKJWvkRC1OOlEhyKdcA&s=cyYmWeYuPwacYmVRzJbhRm3Krz6XNyHbxq8t7ZUi8Ec&e= 
>>
>> For default they are =1, so napi should be assuming 1RX and 1TX, and so you
>> should be getting queue index =0 in reception and transmission.
>>
>> In terms of reception, could you print the queue index that stmmac_poll is using
>> here:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n3468&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=6PN46fgWi1XTHkxFzV9wkYHPkKJWvkRC1OOlEhyKdcA&s=Xli0e7Key3FA7Rve_opcwc6W7nd4khVX15wwoNpFHL4&e= 
> 
> +       pr_info("%s <<< %u\n", __func__, rx_q->queue_index);
>        work_done = stmmac_rx(priv, budget, rx_q->queue_index);
>        if (work_done < budget) {
>                napi_complete_done(napi, work_done);
> 
>        /* Configure real RX and TX queues */
>        netif_set_real_num_rx_queues(ndev, priv->plat->rx_queues_to_use);
>        netif_set_real_num_tx_queues(ndev, priv->plat->tx_queues_to_use);
> +       pr_info("%s <<< %hhu %hhu\n", __func__,
> priv->plat->rx_queues_to_use, priv->plat->tx_queues_to_use);
> 
> 
> [   44.374161] stmmac_dvr_probe <<< 0 0
> 

Ok, so this is the cause of the problem. The driver is geting 0 for real RX and
TX queues.

Your setup uses standard DT parsing from stmmac_platform or a custom one?

If you are using stmmac_probe_config_dt():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n363

You will find a function named stmmac_mtl_setup() being called:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n492

In this function, the number of RX and TX queues is being set to 1 by default.

Joao


> [  109.014763] stmmac_xmit <<< 1: priv cdcea4c0, queue: 2
> [  109.020099] stmmac_xmit <<< 2: priv cdcea4c0, queue: 2 tx_q: cdcea9e4
> 
> That's all, no poll activated.
>