On Wed, Feb 15, 2023 at 11:36 AM Linux regression tracking #update (Thorsten Leemhuis) <regressions@xxxxxxxxxxxxx> wrote: > > On 13.02.23 10:14, Chris Clayton wrote: > > On 13/02/2023 02:57, Dave Airlie wrote: > >> On Sun, 12 Feb 2023 at 00:43, Chris Clayton <chris2553@xxxxxxxxxxxxxx> wrote: > >>> > >>> > >>> > >>> On 10/02/2023 19:33, Linux regression tracking (Thorsten Leemhuis) wrote: > >>>> On 10.02.23 20:01, Karol Herbst wrote: > >>>>> On Fri, Feb 10, 2023 at 7:35 PM Linux regression tracking (Thorsten > >>>>> Leemhuis) <regressions@xxxxxxxxxxxxx> wrote: > >>>>>> > >>>>>> On 08.02.23 09:48, Chris Clayton wrote: > >>>>>>> > >>>>>>> I'm assuming that we are not going to see a fix for this regression before 6.2 is released. > >>>>>> > >>>>>> Yeah, looks like it. That's unfortunate, but happens. But there is still > >>>>>> time to fix it and there is one thing I wonder: > >>>>>> > >>>>>> Did any of the nouveau developers look at the netconsole captures Chris > >>>>>> posted more than a week ago to check if they somehow help to track down > >>>>>> the root of this problem? > >>>>> > >>>>> I did now and I can't spot anything. I think at this point it would > >>>>> make sense to dump the active tasks/threads via sqsrq keys to see if > >>>>> any is in a weird state preventing the machine from shutting down. > >>>> > >>>> Many thx for looking into it! > >>> > >>> Yes, thanks Karol. > >>> > >>> Attached is the output from dmesg when this block of code: > >>> > >>> /bin/mount /dev/sda7 /mnt/sda7 > >>> /bin/mountpoint /proc || /bin/mount /proc > >>> /bin/dmesg -w > /mnt/sda7/sysrq.dmesg.log & > >>> /bin/echo t > /proc/sysrq-trigger > >>> /bin/sleep 1 > >>> /bin/sync > >>> /bin/sleep 1 > >>> kill $(pidof dmesg) > >>> /bin/umount /mnt/sda7 > >>> > >>> is executed immediately before /sbin/reboot is called as the final step of rebooting my system. > >>> > >>> I hope this is what you were looking for, but if not, please let me know what you need > > > > Thanks Dave. [...] > FWIW, in case anyone strands here in the archives: the msg was > truncated. The full post can be found in a new thread: > > https://lore.kernel.org/lkml/e0b80506-b3cf-315b-4327-1b988d86031e@xxxxxxxxxxxxxx/ > > Sadly it seems the info "With runpm=0, both reboot and poweroff work on > my laptop." didn't bring us much further to a solution. :-/ I don't > really like it, but for regression tracking I'm now putting this on the > back-burner, as a fix is not in sight. > > #regzbot monitor: > https://lore.kernel.org/lkml/e0b80506-b3cf-315b-4327-1b988d86031e@xxxxxxxxxxxxxx/ > #regzbot backburner: hard to debug and apparently rare > #regzbot ignore-activity > yeah.. this bug looks a little annoying. Sadly the only Turing based laptop I got doesn't work on Nouveau because of firmware related issues and we probably need to get updated ones from Nvidia here :( But it's a bit weird that the kernel doesn't shutdown, because I don't see anything in the logs which would prevent that from happening. Unless it's waiting on one of the tasks to complete, but none of them looked in any way nouveau related. If somebody else has any fancy kernel debugging tips here to figure out why it hangs, that would be very helpful... > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > -- > Everything you wanna know about Linux kernel regression tracking: > https://linux-regtracking.leemhuis.info/about/#tldr > That page also explains what to do if mails like this annoy you. > > #regzbot ignore-activity >