From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0A52E3B29E for ; Thu, 31 Jan 2019 09:53:10 -0500 (EST) Received: by mail-ed1-f48.google.com with SMTP id o10so2764544edt.13 for ; Thu, 31 Jan 2019 06:53:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=MsauCPIuLQts+IiSen/q8mcV/Wr8VxPYB8p+tNXnkxo=; b=JoiaReWEeLYM0fO3Se5EbnVdsthQl+Ao5zjLlRkCKpiaxSktWVgVF2my4Fv2wclELZ exJzj6ZjQys3Aixp/Gs7DIVvZROISOlRioJrtTvxjqhs55rlfH79m3h0m4Sx3MsLZ7Tx UwC+D35TohKIy80vNkTg7PKCcczIqKMZpVz2RqdHCzqfoi2gQWDkoM5rZpsZVC3cQ8sf diMb/zuI+FOunS1RVmRJo2qgjSGte7vXbF/A6VpncuC6o2jvTOAKI4TnPg0Lm9Nn59vm IDVFZLCdaVCcezsTfXSlS5nuUHXqYXk36Ow41IBnPJGOQ79DTueJy1PhzD/e8f+Pk85k lTqg== X-Gm-Message-State: AJcUukfxzeF4czCABFpxvLReW3apixCUZv8VPvhon/ktDWPTDXGxNVmI X/M0+6/CYuU9+/JPWFs8EL4NhQ== X-Google-Smtp-Source: ALg8bN7TNxgQSmiE5AGQKwnQgdkGFIPbDbzFUN1sSxcGJfSyc1e2h3DmSaO299nx7p5J2pTCx2TfPw== X-Received: by 2002:a17:906:5c9:: with SMTP id t9-v6mr30640214ejt.111.1548946389044; Thu, 31 Jan 2019 06:53:09 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id s36sm1385188edb.43.2019.01.31.06.53.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 31 Jan 2019 06:53:08 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 3DCC7180496; Thu, 31 Jan 2019 15:53:07 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Pete Heist Cc: Cake List In-Reply-To: <9540B582-7B7C-4846-BA40-54419DF109D4@heistp.net> References: <15FB76CC-44B2-496B-80EC-8D00AD2AF9B7@heistp.net> <87zhrhiwfv.fsf@toke.dk> <9540B582-7B7C-4846-BA40-54419DF109D4@heistp.net> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 31 Jan 2019 15:53:07 +0100 Message-ID: <87r2csj2uk.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] lockup with multiple cake instances on 3.16.7 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 14:53:10 -0000 Pete Heist writes: > Thanks much for the try, only that didn=E2=80=99t fix it yet. Hmm, bugger :/ > I also tried > changing two more calls to sch_tree_lock/unlock in cake_change to the > maybe versions (recognizing that those may have still been there on > purpose), but I still see the lockup. Even commented all the lock > calls out to make sure. No, the other calls I left in on purpose; when changing configuration the lock *should* be held. Well, the backtrace is definitely hanging on that lock in gnet_stats_start_copy_compat(). If it's not related to the CAKE logging, I guess it must be a bug in the upstream kernel; which we probably can't fix from the cake side anyway. I don't suppose you can reproduce this on a newer kernel? -Toke