netdev - Re: ipv6 not bringing up due to qdisc_tx_is

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <56E99571.8080209@stressinduktion.org>
Date:	Wed, 16 Mar 2016 18:18:41 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Nikolay Borisov <kernel@...p.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	SiteGround Operations <operations@...eground.com>
Subject: Re: ipv6 not bringing up due to qdisc_tx_is_noop failing

On 16.03.2016 18:14, Nikolay Borisov wrote:
> On Wed, Mar 16, 2016 at 7:07 PM, Hannes Frederic Sowa
> <hannes@...essinduktion.org> wrote:
>> On 16.03.2016 16:29, Nikolay Borisov wrote:
>>>
>>> I have stack traces which do show this sequence of events, so my
>>> questions now are:
>>>
>>> 1. What's the difference between netdev_queue->qdisc and
>>> netdev_queue->qdisc_sleeping. Git blaming indicates those member haves
>>> existed even before the git history was started.
>>
>> qdisc_sleeping is the qdisc you configure before the device is brought up.
>> It should transition during carrier up to the normal qdisc.
>>
>>> 2. Shouldn't the netdev_queue->qdisc also be updated during
>>> attach_one_default_qdisc?
>>
>> Yes, do you have carrier up on your card?
>
> Actually no, the interface indeed shows no carrier yet ibping to other
> hosts on the infiniband network works and ibstats shows the link as
> being in up state. Do you have any ideas how to debug this further?

Probably something in the driver should call netif_carrier_on if carrier 
is connectivity is available. I don't have enough knowledge about IB how 
carrier detection is done there.

>> Is this a regression, did this work for you and stopped working with a
>> specific kernel version?
>
> I don't think this is a regression.

Okay, thanks.

Bye,
Hannes