| Bug ID | 110142 |
|---|---|
| Summary | "Oops: Kernel access of bad area sig 7" on Kernel 5= .0.0 PPC64LE when loading amdgpu, xorg hangs after being unable to load aft= er OS boots. |
| Product | DRI |
| Version | unspecified |
| Hardware | PowerPC |
| OS | Linux (All) |
| Status | NEW |
| Severity | critical |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | JollyRoger@Mailfence.com |
Created attachment 143700 [details]
dmesg output, kernel configuration file, lspci, and Xorg.0.log respectively.
Ahoy!
It looks like amdgpu is having an "Oops" when initializing with K=
ernels 5.0.0
and later on Linux PPC64 (Little Endian) platforms, right as it tries to lo=
ad
amdgpu.=20
In the attached dmesg it looks like it starts around here:=20
[ 34.247578] Oops: Kernel access of bad area, sig: 7 [#1]
I came to notice this bug when I upgraded the kernel from 4.20.11 on Gentoo=
and
4.20.1 on Debian and rebooted, then trying to bring up xfce4 would hang. Th=
is
even causes Gentoo to hang on shutdown when / cannot be unmounted and requi=
res
a hard poweroff, even if I attempt to kill the process starting xfce4.=20
I tried it with both 5.0.0 and 5.0.2 on Gentoo, after upgrading from 4.20.1=
1,
and got similar results: when I enter "startxfce4" at the prompt,=
xorg hangs.=20
I'm attaching my dmesg, kernel configuration file, the output of lspci, and=
the
xorg.0.log in that order. The xorg.0.log file is only 48 lines long, and ha=
sn't
been truncated, that's all that's in it. Currently the only way to work aro=
und
this is for me to use an older kernel. I can post the dmesg from 4.20.11 (t=
he
last kernel I had that worked) if it's required.
Sure!=20 I haven't git bisected a kernel before so I'll go and teach myself how to a= nd report back as soon as I figure it out (I'm currently testing it with 4.20.= 16, which also seems to work). I apologize for the delay, I will keep you updat= ed!
http= s://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id= =3Dc713a461459202504050305242cd854bad57837c seems the most likely candidate, it's the only significant change to gmc_v9_0_late_init between 4.20 and 5.0. I guess the problem is actually in gmc_v9_0_allocate_vm_inv_eng though. Pet= er, what does scripts/faddr2line drivers/gpu/drm/amd/amdgpu/amdgpu.ko gmc_v9_0_late_init+0x114/0x500 say in the kernel build tree (in the state after building the binaries which generated the attached dmesg output)?
| What | Removed | Added |
|---|---|---|
| Status | NEW | ASSIGNED |
Yeah, that is a known problem. Give me a moment to submit a fix to the mailing list.
I'm going to try to see if I can narrow things down a bit by finding the la= st commit that worked before the bug happened and then bisect the kernel there. I'm going to try to compile the kernels, install them, and then try rebooti= ng and starting xfce4 one by one until I find the one that won't start. I apologize in advance for the sluggishness, there are a lot of commits here and the computer boots very slowly, so this puts a bit of a bottleneck on h= ow many kernels I can test in a given timeframe. I'll try to hurry as best I c= an and I'll try to keep this thread updated as I make progress on it. Right no= w I think I'll start at commit af0df68432f65915b2a316aa99eeeb588d4c65a2 since t= hat one works, and I'll start working my way towards 5.0.0 from there to see if= I can narrow down the right commit that borked the driver.=20 > I guess the problem is actually in gmc_v9_0_allo= cate_vm_inv_eng though. Peter, what does...[truncated] Sure. 5.0.2, which gave us that dmesg output, returned to this message when= I tried to enter the commands as followed, this is what the screen looks like= :=20 > captain@morgans-revenge /usr/src/linux-5.0.2= -gentoo/scripts $ ./faddr2line ../drivers/gpu/drm/amd/amdgpu/amdgpu.ko > gmc_v9_0_late_init+0x114/0x500 > gmc_v9_0_late_init+0x114/0x500: > gmc_v9_0_late_init at gmc_v9_0.c:? > captain@morgans-revenge /usr/src/linux-5.0.2-gentoo/scripts $ I hope this might be what you are looking for? I wasn't sure what to enter = so I looked for the drivers folder and then typed the rest in as it was.
Whoops, hit return too quickly.=20 (In reply to Michel D=C3=A4nzer from comment #3) > https://git.kernel.org/pub/scm/linux= /kernel/git/torvalds/linux.git/commit/ > ?id=3Dc713a461459202504050305242cd854bad57837c seems the most likely > candidate, it's the only significant change to gmc_v9_0_late_init betw= een > 4.20 and 5.0. Sure. I'll go and give this one a try first, actually. I'm out of time for = the night but I can hop back on it first thing tomorrow.
Please try https://patchwork.freedesktop.org/patch/292720/ , it should fi= x the problem.
Great, I'll go try it on 5.0.2 and report back, thanks!
(In reply to Michel D=C3=A4nzer from comment #7) > Please try https://patchwork.freedesktop.org/patch/292720/ = , it should fix > the problem. Splice the mainbrace! It worked like a charm!=20 It worked, xfce4 started without a hitch this time with the new kernel. Tha= nk you so much!=20 What shall we do now? Is there a way to get that patch merged upstream?
It's on its way already, but it might take a while for it to l= and in a 5.0.y release.
| What | Removed | Added |
|---|---|---|
| Resolution | --- | FIXED |
| Status | ASSIGNED | RESOLVED |
Yay, glad to hear!=20 I'm going to change it to fixed then, if that's okay with you guys?=20 Thank you so much for the help.