From: Ben Skeggs <skeggsb@gmail.com>
To: Chris Clayton <chris2553@googlemail.com>
Cc: Linux regressions mailing list <regressions@lists.linux.dev>,
bskeggs@redhat.com, Karol Herbst <kherbst@redhat.com>,
Lyude Paul <lyude@redhat.com>,
ML nouveau <nouveau@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>,
ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected
Date: Mon, 30 Jan 2023 11:09:27 +1000 [thread overview]
Message-ID: <CACAvsv4sOtPjCVnEcKd2RCUqYWxSn5XKyksbS-Bds2qCqyusVw@mail.gmail.com> (raw)
In-Reply-To: <ab1b0f73-6b4e-8602-2999-b7bec25d92db@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 7111 bytes --]
On Sat, 28 Jan 2023 at 21:29, Chris Clayton <chris2553@googlemail.com> wrote:
>
>
>
> On 28/01/2023 05:42, Linux kernel regression tracking (Thorsten Leemhuis) wrote:
> > On 27.01.23 20:46, Chris Clayton wrote:
> >> [Resend because the mail client on my phone decided to turn HTML on behind my back, so my reply got bounced.]
> >>
> >> Thanks Thorsten.
> >>
> >> I did try to revert but it didnt revert cleanly and I don't have the knowledge to fix it up.
> >>
> >> The patch was part of a merge that included a number of related patches. Tomorrow, I'll try to revert the lot and report
> >> back.
> >
> > You are free to do so, but there is no need for that from my side. I
> > only wanted to know if a simple revert would do the trick; if it
> > doesn't, it in my experience often is best to leave things to the
> > developers of the code in question,
>
> Sound advice, Thorsten. Way to many conflicts for me to resolve.
Hey,
This is a complete shot-in-the-dark, as I don't see this behaviour on
*any* of my boards. Could you try the attached patch please?
Thanks,
Ben.
>
> as they know it best and thus have a
> > better idea which hidden side effect a more complex revert might have.
> >
> > Ciao, Thorsten
> >
> >> On 27/01/2023 11:20, Linux kernel regression tracking (Thorsten Leemhuis) wrote:
> >>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> >>> to make this easily accessible to everyone.
> >>>
> >>> @nouveau-maintainers, did anyone take a look at this? The report is
> >>> already 8 days old and I don't see a single reply. Sure, we'll likely
> >>> get a -rc8, but still it would be good to not fix this on the finish line.
> >>>
> >>> Chris, btw, did you try if you can revert the commit on top of latest
> >>> mainline? And if so, does it fix the problem?
> >>>
> >>> 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
> >>> If I did something stupid, please tell me, as explained on that page.
> >>>
> >>> #regzbot poke
> >>>
> >>> On 19.01.23 15:33, Linux kernel regression tracking (Thorsten Leemhuis)
> >>> wrote:
> >>>> [adding various lists and the two other nouveau maintainers to the list
> >>>> of recipients]
> >>>
> >>>> On 18.01.23 21:59, Chris Clayton wrote:
> >>>>> Hi.
> >>>>>
> >>>>> I build and installed the lastest development kernel earlier this week. I've found that when I try the laptop down (or
> >>>>> reboot it), it hangs right at the end of closing the current session. The last line I see on the screen when rebooting is:
> >>>>>
> >>>>> sd 4:0:0:0: [sda] Synchronising SCSI cache
> >>>>>
> >>>>> when closing down I see one additional line:
> >>>>>
> >>>>> sd 4:0:0:0 [sda]Stopping disk
> >>>>>
> >>>>> In both cases the machine then hangs and I have to hold down the power button fot a few seconds to switch it off.
> >>>>>
> >>>>> Linux 6.1 is OK but 6.2-rc1 hangs, so I bisected between this two and landed on:
> >>>>>
> >>>>> # first bad commit: [0e44c21708761977dcbea9b846b51a6fb684907a] drm/nouveau/flcn: new code to load+boot simple HS FWs
> >>>>> (VPR scrubber)
> >>>>>
> >>>>> I built and installed a kernel with f15cde64b66161bfa74fb58f4e5697d8265b802e (the parent of the bad commit) checked out
> >>>>> and that shuts down and reboots fine. It the did the same with the bad commit checked out and that does indeed hang, so
> >>>>> I'm confident the bisect outcome is OK.
> >>>>>
> >>>>> Kernels 6.1.6 and 5.15.88 are also OK.
> >>>>>
> >>>>> My system had dual GPUs - one intel and one NVidia. Related extracts from 'lscpi -v' is:
> >>>>>
> >>>>> 00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05) (prog-if 00 [VGA controller])
> >>>>> Subsystem: CLEVO/KAPOK Computer CometLake-H GT2 [UHD Graphics]
> >>>>>
> >>>>> Flags: bus master, fast devsel, latency 0, IRQ 142
> >>>>>
> >>>>> Memory at c2000000 (64-bit, non-prefetchable) [size=16M]
> >>>>>
> >>>>> Memory at a0000000 (64-bit, prefetchable) [size=256M]
> >>>>>
> >>>>> I/O ports at 5000 [size=64]
> >>>>>
> >>>>> Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
> >>>>>
> >>>>> Capabilities: [40] Vendor Specific Information: Len=0c <?>
> >>>>>
> >>>>> Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
> >>>>>
> >>>>> Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
> >>>>>
> >>>>> Capabilities: [d0] Power Management version 2
> >>>>>
> >>>>> Kernel driver in use: i915
> >>>>>
> >>>>> Kernel modules: i915
> >>>>>
> >>>>>
> >>>>> 01:00.0 VGA compatible controller: NVIDIA Corporation TU117M [GeForce GTX 1650 Ti Mobile] (rev a1) (prog-if 00 [VGA
> >>>>> controller])
> >>>>> Subsystem: CLEVO/KAPOK Computer TU117M [GeForce GTX 1650 Ti Mobile]
> >>>>> Flags: bus master, fast devsel, latency 0, IRQ 141
> >>>>> Memory at c4000000 (32-bit, non-prefetchable) [size=16M]
> >>>>> Memory at b0000000 (64-bit, prefetchable) [size=256M]
> >>>>> Memory at c0000000 (64-bit, prefetchable) [size=32M]
> >>>>> I/O ports at 4000 [size=128]
> >>>>> Expansion ROM at c3000000 [disabled] [size=512K]
> >>>>> Capabilities: [60] Power Management version 3
> >>>>> Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
> >>>>> Capabilities: [78] Express Legacy Endpoint, MSI 00
> >>>>> Kernel driver in use: nouveau
> >>>>> Kernel modules: nouveau
> >>>>>
> >>>>> DRI_PRIME=1 is exported in one of my init scripts (yes, I am still using sysvinit).
> >>>>>
> >>>>> I've attached the bisect.log, but please let me know if I can provide any other diagnostics. Please cc me as I'm not
> >>>>> subscribed.
> >>>>
> >>>> Thanks for the report. To be sure the issue doesn't fall through the
> >>>> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
> >>>> tracking bot:
> >>>>
> >>>> #regzbot ^introduced e44c2170876197
> >>>> #regzbot title drm: nouveau: hangs on poweroff/reboot
> >>>> #regzbot ignore-activity
> >>>>
> >>>> This isn't a regression? This issue or a fix for it are already
> >>>> discussed somewhere else? It was fixed already? You want to clarify when
> >>>> the regression started to happen? Or point out I got the title or
> >>>> something else totally wrong? Then just reply and tell me -- ideally
> >>>> while also telling regzbot about it, as explained by the page listed in
> >>>> the footer of this mail.
> >>>>
> >>>> Developers: When fixing the issue, remember to add 'Link:' tags pointing
> >>>> to the report (the parent of this mail). See page linked in footer for
> >>>> details.
> >>>>
> >>>> 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.
> >>
> >>
[-- Attachment #2: nvdec0-reset.diff --]
[-- Type: text/x-patch, Size: 849 bytes --]
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp102.c b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp102.c
index 2658481d575b..a75aa82be1aa 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp102.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp102.c
@@ -30,16 +30,18 @@ int
gp102_fb_vpr_scrub(struct nvkm_fb *fb)
{
struct nvkm_subdev *subdev = &fb->subdev;
+ struct nvkm_falcon *falcon = &subdev->device->nvdec[0]->falcon;
struct nvkm_falcon_fw fw = {};
int ret;
ret = nvkm_falcon_fw_ctor_hs(&gm200_flcn_fw, "mem-unlock", subdev, NULL,
- "nvdec/scrubber", 0, &subdev->device->nvdec[0]->falcon, &fw);
+ "nvdec/scrubber", 0, falcon, &fw);
if (ret)
return ret;
ret = nvkm_falcon_fw_boot(&fw, subdev, true, NULL, NULL, 0, 0x00000000);
nvkm_falcon_fw_dtor(&fw);
+ nvkm_falcon_reset(falcon);
return ret;
}
next prev parent reply other threads:[~2023-01-30 1:09 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-18 20:59 linux-6.2-rc4+ hangs on poweroff/reboot: Bisected Chris Clayton
2023-01-19 14:33 ` Linux kernel regression tracking (Thorsten Leemhuis)
2023-01-19 16:43 ` Linux kernel regression tracking (#update)
2023-01-27 11:20 ` Linux kernel regression tracking (Thorsten Leemhuis)
2023-01-27 11:35 ` Karol Herbst
2023-01-27 19:41 ` Chris Clayton
2023-01-27 19:46 ` Chris Clayton
2023-01-28 5:42 ` Linux kernel regression tracking (Thorsten Leemhuis)
2023-01-28 11:29 ` Chris Clayton
2023-01-30 1:09 ` Ben Skeggs [this message]
2023-01-30 20:19 ` Chris Clayton
2023-01-30 23:09 ` Chris Clayton
2023-01-30 23:27 ` Ben Skeggs
2023-02-01 13:51 ` Chris Clayton
2023-02-02 20:45 ` Chris Clayton
2023-02-08 8:48 ` Chris Clayton
2023-02-10 18:35 ` Linux regression tracking (Thorsten Leemhuis)
2023-02-10 19:01 ` Karol Herbst
2023-02-10 19:33 ` Linux regression tracking (Thorsten Leemhuis)
2023-02-11 13:38 ` Chris Clayton
2023-02-13 2:57 ` Dave Airlie
2023-02-13 9:14 ` Chris Clayton
2023-02-15 10:36 ` Linux regression tracking #update (Thorsten Leemhuis)
2023-02-15 11:09 ` Karol Herbst
2023-02-18 12:22 ` Chris Clayton
2023-02-18 12:25 ` Karol Herbst
2023-02-18 15:19 ` Chris Clayton
2023-02-18 18:55 ` Chris Clayton
2023-02-20 5:35 ` Ben Skeggs
2023-02-20 10:51 ` Chris Clayton
2023-02-20 11:26 ` Karol Herbst
2023-02-20 22:16 ` Ben Skeggs
2023-03-10 9:26 ` Chris Clayton
2023-03-10 10:20 ` Karol Herbst
2023-03-12 13:30 ` Linux regression tracking (Thorsten Leemhuis)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACAvsv4sOtPjCVnEcKd2RCUqYWxSn5XKyksbS-Bds2qCqyusVw@mail.gmail.com \
--to=skeggsb@gmail.com \
--cc=bskeggs@redhat.com \
--cc=chris2553@googlemail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kherbst@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=nouveau@lists.freedesktop.org \
--cc=regressions@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).