| Bug ID | 97620 |
|---|---|
| Summary | [REGRESSION] KMS having issues after kernel upgrade (4.5.1-1 = to 4.6.4-1) |
| Product | xorg |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | critical |
| Priority | medium |
| Component | Driver/nouveau |
| Assignee | nouveau@lists.freedesktop.org |
| Reporter | lukeisgreat@gmail.com |
| QA Contact | xorg-team@lists.x.org |
Created attachment 126259= [details] working kernel version Originally diagnosed in https://bbs.archlinux.org/viewtopic.php?id=3D216364 distro is Arch. Music studio machine with an nvidia GeForce GTX 460 and "ACHIEVA Shimian QH270-Lite 27" Wide QHD PC Monitor DVI-D 2560x14= 40" connected via DVI. Have been using nouveau without issue since 2012. Kernel update from 4.5.1-= 1 to (4.6.4-1 or 4.6.7-rt11-2-rt) causes a lower than standard resolution during kernel messages then no video once X attempts to start. Reverting to 4.5.1-1 works perfectly. "nomodeset single" kernel options allow me to ge= t to a terminal. some package versions that don't change between kernels: extra/mesa 12.0.2-1 [installed] extra/xf86-video-nouveau 1.0.12-2 (xorg-drivers xorg) [installed]
Created =
attachment 126260 [details]
newer kernel with regression (no video)
Your 4.6 kernel is being booted with 'nomodeset'. That disable= s the nouveau kernel driver entirely.
Created [details]
dmesg_4.6.7-rt11-2-rt (without nomodeset)
Created attachment 126266 [details]
dmesg_4.6.4-1-ARCH - in case you'd rather not bother with a realtime kernel=
| What | Removed | Added |
|---|---|---|
| Attachment #126260 is obsolete | 1 |
| What | Removed | Added |
|---|---|---|
| Attachment #126259 description | working kernel version | 4.5.1-1-ARCH video working flawlessly |
| What | Removed | Added |
|---|---|---|
| Attachment #126259 description | 4.5.1-1-ARCH video working flawlessly | dmesg_4.5.1-1-ARCH video working flawlessly |
Hrmph. Well it looks like your GPU just goes nuts.
[ 9.933619] nouveau 0000:01:00.0: bus: MMIO write of 00000002 FAULT at
13b154 [ IBUS ]
[ 9.936957] nouveau 0000:01:00.0: bus: MMIO write of 00000000 FAULT at
61019c [ IBUS ]
followed by a ton more 610xxx errors. 610xxx is PDISPLAY stuff, but 13b154 =
is
in PXBAR.GPC_*. I also can't find any way that we'd be writing to that
register, at least nothing too direct. Something we do greatly upsets the c=
hip
though.
I looked through the nouveau changes between 4.5 and 4.6, and while there w=
as a
ton of stuff, nothing jumps out at me.
Can you do a git bisect on the kernel between v4.5 and v4.6 (you can restri=
ct
it to drivers/gpu/drm/nouveau) to figure out which change killed it?
Separately, you could see if it magically got fixed in v4.7 or v4.8-rcN.
FYI a newer kernel (linux-git 4.8rc4.r0.g3eab887-1) didn't hel= p. I also knocked my machine unreachable by trying to `git bisect` without specifying the limiting path. I'll test more when I get home from work and can power cycle= the machine.
Hi! Sorry that took so long. My other machine didn't have enou= gh memory to run git bisect on the kernel. Here's the goods. Any change marked bad exhibited the exact same symptoms (monitor turns off shortly after boot). git bisect start '--' 'drivers/gpu/drm/nouveau' # good: [b562e44f507e863c6792946e4e1b1449fbbac85d] Linux 4.5 git bisect good b562e44f507e863c6792946e4e1b1449fbbac85d # bad: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7 git bisect bad 523d939ef98fd712632d93a5a2b588e477a7565e # bad: [3a91b9c5efd27729767edfde9df069aa61c4816f] drm/nouveau/clk/gk20a: fix VCO bit mask git bisect bad 3a91b9c5efd27729767edfde9df069aa61c4816f # bad: [a2e435a1b0a3c2bc766d40356151610cc54b8772] drm/nouveau/fifo/gk104: t= ake runlist target into account git bisect bad a2e435a1b0a3c2bc766d40356151610cc54b8772 # bad: [18cd5bc8ea587dc2fc0c07d2a4bf3cfe9ed2ef53] drm/nouveau/gr/gf100: load firmware in outer function git bisect bad 18cd5bc8ea587dc2fc0c07d2a4bf3cfe9ed2ef53 # good: [1b82111faebc24427c76b83738566bda7f315225] drm/nouveau/device/tegra: fix uninitialized IRQ number git bisect good 1b82111faebc24427c76b83738566bda7f315225 # bad: [989f57847396d1d042204747985d6aacf5399c8a] drm/nouveau/bios/devinit: rename INIT_DP_CONDITION to INIT_GENERIC_CONDITION git bisect bad 989f57847396d1d042204747985d6aacf5399c8a # good: [8fb1240a7152d450d57402b5b85ba46d8610d443] drm/nouveau/devinit/nv50: remove unneeded variable git bisect good 8fb1240a7152d450d57402b5b85ba46d8610d443 # bad: [96aedd0ba9122a13fd0f756e022856ce7f05f086] drm/nouveau/ltc/gm107: fix slice intr offset git bisect bad 96aedd0ba9122a13fd0f756e022856ce7f05f086
(In reply to Luke Tidd from comment #9) > Hi! Sorry that took so long. My other machine di= dn't have enough memory to > run git bisect on the kernel. >=20 >=20 > Here's the goods. Any change marked bad exhibited the exact same sympt= oms > (monitor turns off shortly after boot). Looks like you didn't finish? At the end it should say "commit XYZ is = the first bad commit"
You are right, sorry new to git bisect. Was thrown off by &quo= t;0 more steps to do". git bisect start '--' 'drivers/gpu/drm/nouveau' # good: [b562e44f507e863c6792946e4e1b1449fbbac85d] Linux 4.5 git bisect good b562e44f507e863c6792946e4e1b1449fbbac85d # bad: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7 git bisect bad 523d939ef98fd712632d93a5a2b588e477a7565e # bad: [3a91b9c5efd27729767edfde9df069aa61c4816f] drm/nouveau/clk/gk20a: fix VCO bit mask git bisect bad 3a91b9c5efd27729767edfde9df069aa61c4816f # bad: [a2e435a1b0a3c2bc766d40356151610cc54b8772] drm/nouveau/fifo/gk104: t= ake runlist target into account git bisect bad a2e435a1b0a3c2bc766d40356151610cc54b8772 # bad: [18cd5bc8ea587dc2fc0c07d2a4bf3cfe9ed2ef53] drm/nouveau/gr/gf100: load firmware in outer function git bisect bad 18cd5bc8ea587dc2fc0c07d2a4bf3cfe9ed2ef53 # good: [1b82111faebc24427c76b83738566bda7f315225] drm/nouveau/device/tegra: fix uninitialized IRQ number git bisect good 1b82111faebc24427c76b83738566bda7f315225 # bad: [989f57847396d1d042204747985d6aacf5399c8a] drm/nouveau/bios/devinit: rename INIT_DP_CONDITION to INIT_GENERIC_CONDITION git bisect bad 989f57847396d1d042204747985d6aacf5399c8a # good: [8fb1240a7152d450d57402b5b85ba46d8610d443] drm/nouveau/devinit/nv50: remove unneeded variable git bisect good 8fb1240a7152d450d57402b5b85ba46d8610d443 # bad: [96aedd0ba9122a13fd0f756e022856ce7f05f086] drm/nouveau/ltc/gm107: fix slice intr offset git bisect bad 96aedd0ba9122a13fd0f756e022856ce7f05f086 # bad: [a6a0f67ca7aae2e6bec7ebf55d1e4853dc220816] drm/nouveau/devinit/gf100= -: detect if BIOS invoked devinit git bisect bad a6a0f67ca7aae2e6bec7ebf55d1e4853dc220816 # first bad commit: [a6a0f67ca7aae2e6bec7ebf55d1e4853dc220816] drm/nouveau/devinit/gf100-: detect if BIOS invoked devinit
(In reply to Luke Tidd from comment #11) > # first bad commit: [a6a0f67ca7aae2e6bec7ebf55d1= e4853dc220816] > drm/nouveau/devinit/gf100-: detect if BIOS invoked devinit That's interesting. It either used to run init tables and now doesn't, or conversely didn't use to and now does. Would you mind running a "working" kernel with nouveau.debug=3Dde= bug and see if it ever says "bios: running init tables"? If it does, you can pro= bably make the new kernels work by adding nouveau.config=3DNvForcePost=3D1 . If it previou= sly didn't run the tables and now does, there's no config-line way of overriding it.
Another thing you could do is boot (any) kernel with nomodeset= , and then using envytools (https://gith= ub.com/envytools/envytools/), do nvapeek 2240c This should output 1 line, either a number or just "..." [which m= eans "0"], I would like to know what it is. Ideally this would be done on a cold boot.
kernel 4.7.4-1-ARCH nomodeset single # nvapeek 2240c ... testing working kernel now.
(In reply to Luke Tidd from comment #14) > kernel 4.7.4-1-ARCH > nomodeset single >=20 > # nvapeek 2240c > ... >=20 >=20 > testing working kernel now. Hm, that means that the bit we're checking is 0, which indicates that the V= BIOS hasn't run. This is, of course, patently false, since it seems like this is= the only video card in the system, and it's working (right? you're at the conso= le, the screen is on, etc?) And, I'm guessing, in the new kernel we're now running the vbios whereas we previously didn't use to. And running it a second time destroys the universe for some reason. Separately, I just happened to notice that you have vesafb turned on. I won= der if this somehow upsets matters. Any chance you could flip that off?
(In reply to Ilia Mirkin from comment #15) > (In reply to Luke Tidd from comment #14) > > kernel 4.7.4-1-ARCH > > nomodeset single > >=20 > > # nvapeek 2240c > > ... > >=20 > >=20 > > testing working kernel now. >=20 > Hm, that means that the bit we're checking is 0, which indicates that = the > VBIOS hasn't run. This is, of course, patently false, since it seems l= ike > this is the only video card in the system, and it's working (right? yo= u're > at the console, the screen is on, etc?) Yes, working, screen is on, this is the only video card. >=20 > And, I'm guessing, in the new kernel we're now running the vbios where= as we > previously didn't use to. And running it a second time destroys the un= iverse > for some reason. >=20 > Separately, I just happened to notice that you have vesafb turned on. I > wonder if this somehow upsets matters. Any chance you could flip that = off? Sure, just a sec
Created attachment 126609 [details]
dmesg 4.5.0-rc7 nouveau.debug=3Ddebug log_buf_len=3D1M single
(In reply to Ilia Mirkin from comment #12) > (In reply to Luke Tidd from comment #11) > > # first bad commit: [a6a0f67ca7aae2e6bec7ebf55d1e4853dc220816] > > drm/nouveau/devinit/gf100-: detect if BIOS invoked devinit >=20 > That's interesting. It either used to run init tables and now doesn't,= or > conversely didn't use to and now does. >=20 > Would you mind running a "working" kernel with nouveau.debug= =3Ddebug and see > if it ever says "bios: running init tables"? If it does, you= can probably > make the new kernels work by adding nouveau.config=3DNvForcePost=3D1 .= If it > previously didn't run the tables and now does, there's no config-line = way of > overriding it. https:/= /bugs.freedesktop.org/attachment.cgi?id=3D126609 I don't see "bios: running init tables" but here is the entire dm= esg.
Created attachment 126610 [details]
4.5.0-rc7 nouveau.debug=3Ddebug video=3Dvesafb:off log_buf_len=3D1M
(In reply to Luke Tidd from comment #18) > https://bugs.freedesktop.org/attachment.cgi?id=3D126609= > I don't see "bios: running init tables" but here is the enti= re dmesg. Indeed. So the "working" state is to not run the VBIOS. Something= in there is upsetting matters (normally running the VBIOS a second time doesn't hurt anything, it's just pointless work and can cause a flicker). Assuming that disabling vesafb doesn't help (the way those legacy interfaces are implemen= ted can be pretty brittle), please include (a) /sys/kernel/debug/dri/0/vbios.rom (from any boot) (b) nouveau.debug=3Ddebug,bios=3Dtrace output from a *broken* kernel boot Ideally that should provide some further things to look at.