Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 22 May 2023 15:43:15 +0200
From:   Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To:     Mike Galbraith <efault@gmx.de>
Cc:     Heiner Kallweit <hkallweit1@gmail.com>,
        lkml <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>
Subject: Re: r8169: disable ASPM during NAPI poll locking changes --> BUG:
 Invalid wait context --> PREEMPT_RT pain
Message-ID: <20230522134315.oBK0Ll7f@linutronix.de>
References: <e55be0ae115ad6494ebb48fecd03e5c2fe528230.camel@gmx.de>
 <28727b435c143f15feddffb4c29095fee2500dff.camel@gmx.de>
 <20230522080604.MgUGcyeU@linutronix.de>
 <d7fa9ffe0e6cd546b8ff3826379c2cf78e5342b6.camel@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <d7fa9ffe0e6cd546b8ff3826379c2cf78e5342b6.camel@gmx.de>
Precedence: bulk

On 2023-05-22 12:41:21 [+0200], Mike Galbraith wrote:
> > I've been looking at the r8169 the other day and it seemed all good
> > since it was only scheduling workqueues and NAPI. But now I see this
> > mac_ocp_lock + config25_lock which are acquire in hardirq context but
> > can't. This needs to be taken care.
> 
> I did a patch converting the locks, but didn't post it hoping maybe
> those locks weren't really really needed.  It doesn't matter for my
> box, as it doesn't do anything but give RT chances to trip over bugs.

I missed that part. Do you still see those 160us if you keep the locks
as-it as drop the no-threads flag? I'm trying to figure out if this is
due to hwirq context or just blocked PCI-bus due ASPM.

> 	-Mike

Sebastian