Re: September 2025 stabilization week

> Is there any additional info I can collect that he wants ?

Yes! Can you send me your dmesg after doing a suspend-resume and also
the result of:

acpidump -s

Also would help me if you could apply this patch:

diff --git a/sys/dev/acpica/acpi_powerres.c b/sys/dev/acpica/acpi_powerres.c
index 0a8b67a5fa84..c0c0c9c758c9 100644
--- a/sys/dev/acpica/acpi_powerres.c
+++ b/sys/dev/acpica/acpi_powerres.c
@@ -741,13 +741,14 @@ acpi_pwr_switch_consumer(ACPI_HANDLE consumer, int state)
      * before we were checking D-states.
      */
     if (ACPI_FAILURE(acpi_pwr_get_state_locked(consumer, &new_state))) {
-       printf("%s: failed to get new D-state\n", __func__);
+       printf("%s: failed to get new D-state (device %s)\n", __func__,
+              acpi_name(consumer));
        pc->ac_state = state;
     } else {
        if (new_state != state)
-           printf("%s: new power state %s is not the one requested %s\n",
+           printf("%s: new power state %s is not the one requested %s (%s)\n",
                   __func__, acpi_d_state_to_str(new_state),
-                  acpi_d_state_to_str(state));
+                  acpi_d_state_to_str(state), acpi_name(consumer));
        pc->ac_state = new_state;
     }

On Wed, 24 Sept 2025 at 17:59, Aymeric Wibo <me@obiw.ac> wrote:
>
> > Is there any additional info I can collect that he wants ?
>
> Yes! Can you send me your dmesg after doing a suspend-resume and also
> the result of:
>
> acpidump -s
>
> Also would help me if you could apply this patch:
>
> diff --git a/sys/dev/acpica/acpi_powerres.c b/sys/dev/acpica/acpi_powerres.c
> index 0a8b67a5fa84..c0c0c9c758c9 100644
> --- a/sys/dev/acpica/acpi_powerres.c
> +++ b/sys/dev/acpica/acpi_powerres.c
> @@ -741,13 +741,14 @@ acpi_pwr_switch_consumer(ACPI_HANDLE consumer, int state)
>       * before we were checking D-states.
>       */
>      if (ACPI_FAILURE(acpi_pwr_get_state_locked(consumer, &new_state))) {
> -       printf("%s: failed to get new D-state\n", __func__);
> +       printf("%s: failed to get new D-state (device %s)\n", __func__,
> +              acpi_name(consumer));
>         pc->ac_state = state;
>      } else {
>         if (new_state != state)
> -           printf("%s: new power state %s is not the one requested %s\n",
> +           printf("%s: new power state %s is not the one requested %s (%s)\n",
>                    __func__, acpi_d_state_to_str(new_state),
> -                  acpi_d_state_to_str(state));
> +                  acpi_d_state_to_str(state), acpi_name(consumer));
>         pc->ac_state = new_state;
>      }
>
>
>
> On Wed, 24 Sept 2025 at 17:12, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> >
> > --------
> > Gleb Smirnoff writes:
> >
> > > On Tue, Sep 23, 2025 at 09:18:53AM +0000, Poul-Henning Kamp wrote:
> > > P> > started with FreeBSD/main at main-n280533-f72908c94df9, which was tagged as
> > > P> > main-stabweek-2025-Sep.
> > > P>
> > > P> Works on my T14s gen 2.
> > > P>
> > > P> The right hand USB-A port is still dead after suspend-resume (this started
> > > P> within the last approx 8 weeks).
> > >
> > > I bisected my Thinkpad X1 Carbon 7th Gen down to 02a8fadd2c4dc4b78d6d93d9d8b70e9348a6de6d.
> >
> > > Can you try reverting this revision, too?
> >
> > I've added that to the TODO list, may get to it tonight.
> >
> > > Note: to reproduce the dead USBs I need not only suspend-resume
> > > cycle, but also pull out power cord.
> >
> > I dont need to do that, but I'm powering through a dock, so that may
> > make some kind of difference.
> >
> > > Good news: Aymeric is here at EuroBSDCon and in next two days
> > > he is close to my laptop and we are going to debug this.
> >
> > Great!
> >
> > Is there any additional info I can collect that he wants ?
> >
> > --
> > Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> > phk@FreeBSD.ORG         | TCP/IP since RFC 956
> > FreeBSD committer       | BSD since 4.3-tahoe
> > Never attribute to malice what can adequately be explained by incompetence.