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;
Subject: Re: [PATCH] hack to debug acpiphp crash
To:     Igor Mammedov <imammedo@redhat.com>
Cc:     linux-kernel@vger.kernel.org, bhelgaas@google.com,
        linux-pci@vger.kernel.org, mst@redhat.com
References: <11fc981c-af49-ce64-6b43-3e282728bd1a@gmail.com>
 <20230724135902.2217991-1-imammedo@redhat.com>
 <92150d8d-8a3a-d600-a996-f60a8e4c876c@gmail.com>
 <20230725100644.6138efb6@imammedo.users.ipa.redhat.com>
 <20230725104237.0c8d0dc1@imammedo.users.ipa.redhat.com>
From:   Woody Suwalski <terraluna977@gmail.com>
Message-ID: <d1333a63-c6b8-fe9a-24ce-05d2198323c2@gmail.com>
Date:   Tue, 25 Jul 2023 07:45:08 -0400
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:91.0) Gecko/20100101 Firefox/91.0
 SeaMonkey/2.53.16
MIME-Version: 1.0
In-Reply-To: <20230725104237.0c8d0dc1@imammedo.users.ipa.redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Igor Mammedov wrote:
> On Tue, 25 Jul 2023 10:06:44 +0200
> Igor Mammedov <imammedo@redhat.com> wrote:
>
>> PS:
>> What happens is that on resume firmware (likely EC),
>> issues ACPI bus check on root ports which (bus check) is
>> wired to acpiphp module (though pciehp module was initialized
>> at boot to manage root ports), it's likely firmware bug.
>>
>> I'd guess the intent behind this was to check if PCIe devices
>> were hotplugged while laptop has been asleep, and for
>> some reason they didn't use native PCIe hotplug to handle that.
>> However looking at laptop specs you can't hotplug PCIe
>> devices via external ports. Given how old laptop is
>> it isn't going to be fixed, so we would need a workaround
>> or fixup DSDT to skip buscheck.
>>
>> The options I see is to keep old kernel as for such case,
>> or bail out early from bus check/enable_slot since root port
>> is managed by pciehp module (and let it handle hotplug).
> scratch all of above out (it's wrong). Looking at DSDT
> firmware sends Notify(rpxx, 2 /* Wake */) event. Which
> according to spec needs to be handed down to the native
> device driver.
>
>
I agree that this laptop is a tricky one. I had to adjust my kernel 
config NOHZ just to make it suspend to ram, otherwise it was waking back 
right after going to sleep (and the same nohz kernel worked on all my 
other machines)...