Bug 90626

Summary: HP ZBook 15 nouveau driver hangup for kernel >= 4.1
Product: xorg Reporter: René Krell <renda.krell>
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: critical    
Priority: medium CC: vdanjean.ml, vincent-fdt
Version: unspecified   
Hardware: Other   
OS: All   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=91402
https://bugs.freedesktop.org/show_bug.cgi?id=91779
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
/sys/kernel/debug/dri/0/vbios.rom loaded on kernel 3.16.7
none
/var/log/boot.msg on kernel 3.16.7
none
/sys/kernel/debug/dri/0/vbios.rom loaded on kernel 3.18.10
none
/var/log/boot.msg on kernel 3.18.10
none
/var/log/boot.omsg on kernel 4.1rc4
none
acpidump -b
none
acpidump (HP ZBook 15, nVidia GK208GLM [Quadro K610M], BIOS v31/03/2015)
none
acpidump (HP ZBook 15, nVidia GK106GLM [Quadro K2100M], BIOS v08/13/2014)
none
acpidump (HP ZBook 15, NVidia GK208GLM [Quadro K610M], BIOS v21/07/2015) none

Description René Krell 2015-05-25 07:16:54 UTC
This is not a duplicate of bug #89047, but just another bug after a driver fix.

For bug #89047 there has been obviously made the following fix:
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4195f40685a5f2783b4decece13ed740b61ee038

I tried this on my HP ZBook 15 using 4.1.rc4 (OpenSUSE HEAD kernel, kernel-desktop) where this fix definitely went and run into another issue:

2015-05-25T08:26:17.054291+02:00 rkrell kernel: [    4.681436] nouveau  [  DEVICE][0000:01:00.0] BOOT0  : 0x108390a1
2015-05-25T08:26:17.054293+02:00 rkrell kernel: [    4.681438] nouveau  [  DEVICE][0000:01:00.0] Chipset: GK208 (NV108)
2015-05-25T08:26:17.054293+02:00 rkrell kernel: [    4.681440] nouveau  [  DEVICE][0000:01:00.0] Family : NVE0
2015-05-25T08:26:17.054294+02:00 rkrell kernel: [    4.686763] nouveau  [   VBIOS][0000:01:00.0] using image from ACPI
2015-05-25T08:26:17.054294+02:00 rkrell kernel: [    4.686921] nouveau  [   VBIOS][0000:01:00.0] BIT signature found
2015-05-25T08:26:17.054352+02:00 rkrell kernel: [    4.686924] nouveau  [   VBIOS][0000:01:00.0] version 80.28.52.00.09
2015-05-25T08:26:17.054353+02:00 rkrell kernel: [    4.686931] nouveau W[   VBIOS][0000:01:00.0] DCB contains no useful data
2015-05-25T08:26:17.054356+02:00 rkrell kernel: [    4.686932] nouveau W[   VBIOS][0000:01:00.0] DCB contains no useful data
2015-05-25T08:26:17.054356+02:00 rkrell kernel: [    4.686938] nouveau E[   VBIOS][0000:01:00.0] 0xce73[ ]: unknown opcode 0xff
2015-05-25T08:26:17.054357+02:00 rkrell kernel: [    4.686942] nouveau E[ DEVINIT][0000:01:00.0] init failed, -22
2015-05-25T08:26:17.054357+02:00 rkrell kernel: [    4.686944] nouveau E[     DRM] failed to create 0x00000080, -22
2015-05-25T08:26:17.054358+02:00 rkrell kernel: [    4.687221] nouveau: probe of 0000:01:00.0 failed with error -22

The kernel still hangs up, CTRL-ALT-BACKSPACE does not work.
The BIOS of the HP ZBook 15 is set to Legacy Mode, no UEFI is used.
Comment 1 René Krell 2015-05-26 14:08:25 UTC
For completeness I just got to mention another time (because it has been mentioned in another issue):
The nouveau driver worked _before_ kernel 3.19.x on the same hardware and stopped to work beginning from 3.19.x.
The problem reported in this issue applies to the kernel after commit 4195f40685a5f2783b4decece13ed740b61ee038.
Comment 2 Ilia Mirkin 2015-05-26 14:27:15 UTC
(In reply to René from comment #1)
> For completeness I just got to mention another time (because it has been
> mentioned in another issue):
> The nouveau driver worked _before_ kernel 3.19.x on the same hardware and
> stopped to work beginning from 3.19.x.

Did you mean for one of those version numbers to be different? Can you bisect between a working and non-working kernel to identify the issue? (Is it the same commit as pointed out in #89047?) Please post logs from a working kernel, as well as your VBIOS image (/sys/kernel/debug/dri/0/vbios.rom from a successful nouveau load).
Comment 3 René Krell 2015-05-26 14:37:30 UTC
Alright, trying to break it down regarding HP ZBook 15 and the nouveau driver:
- I'm currently on 3.16.7 and have a working nouveau driver. I will provide the needed attachments for exactly that one.
- Kernel 3.18: This is last working kernel I found.
- Kernel 3.19: The issue #89047 git introduced, which I could reproduce, and which has been apparently fixed by Ben in commit 4195f40685a5f2783b4decece13ed740b61ee038. I mentioned it just to ensure this report here is not the same issue to not mark it duplicate.
- Kernel 4.1 RC4: This is a kernel definitely containing the fix committed above and therefore the next stage to be tested for me. In kernel 4.1 RC4 I get the problem reported here, which is different from that in issue #89047.
Comment 4 Ilia Mirkin 2015-05-26 14:39:46 UTC
(In reply to René from comment #3)
> Alright, trying to break it down regarding HP ZBook 15 and the nouveau
> driver:
> - I'm currently on 3.16.7 and have a working nouveau driver. I will provide
> the needed attachments for exactly that one.
> - Kernel 3.18: This is last working kernel I found.
> - Kernel 3.19: The issue #89047 git introduced, which I could reproduce, and
> which has been apparently fixed by Ben in commit
> 4195f40685a5f2783b4decece13ed740b61ee038. I mentioned it just to ensure this
> report here is not the same issue to not mark it duplicate.
> - Kernel 4.1 RC4: This is a kernel definitely containing the fix committed
> above and therefore the next stage to be tested for me. In kernel 4.1 RC4 I
> get the problem reported here, which is different from that in issue #89047.

Right, I realize it's a different issue... but could have been caused by the same commit :)

Assuming nothing obvious comes to mind when you post the other info, doing a bisect between 3.18 and 3.19 will be the surest way to get this resolved.
Comment 5 René Krell 2015-05-26 14:41:36 UTC
Created attachment 116047 [details]
/sys/kernel/debug/dri/0/vbios.rom loaded on kernel 3.16.7
Comment 6 René Krell 2015-05-26 14:46:07 UTC
Created attachment 116048 [details]
/var/log/boot.msg on kernel 3.16.7
Comment 7 Ilia Mirkin 2015-05-26 14:50:59 UTC
Interesting. So the VBIOS you uploaded has:

0xce73: 71                                             DONE

However the error print from the more recent kernel says "unknown opcode 0xff". That means it's getting read in wrong somehow.
Comment 8 René Krell 2015-05-26 15:04:18 UTC
Can I provide something else or help somehow? I'm not a nouveau driver expert, but I can help in testing and reproducing, just need a HOWTO from some points :-)
Comment 9 René Krell 2015-05-26 15:46:10 UTC
Created attachment 116049 [details]
/sys/kernel/debug/dri/0/vbios.rom loaded on kernel 3.18.10
Comment 10 René Krell 2015-05-26 15:47:21 UTC
Created attachment 116051 [details]
/var/log/boot.msg on kernel 3.18.10
Comment 11 René Krell 2015-05-26 15:48:26 UTC
I attached also vbios.rom and boot.msg for kernel 3.18.10, which is the most recent working kernel version I currently know for this hardware.
Comment 12 Ilia Mirkin 2015-05-26 15:48:44 UTC
In the future, please avoid gzippling logs. That makes me have to download them instead of being able to read them via the web interface.
Comment 13 René Krell 2015-05-26 15:58:09 UTC
Created attachment 116053 [details]
/var/log/boot.omsg on kernel 4.1rc4
Comment 14 vdanjean@free.fr 2015-09-04 12:45:55 UTC
Any progress on this bug? Any missing information?

I still get the same thing on a HP ZBook 15, too:

août 30 23:33:05 eyak kernel: nouveau 0000:01:00.0: enabling device (0004 -> 0007)
août 30 23:33:05 eyak kernel: nouveau  [  DEVICE][0000:01:00.0] BOOT0  : 0x108390a1
août 30 23:33:05 eyak kernel: nouveau  [  DEVICE][0000:01:00.0] Chipset: GK208 (NV108)
août 30 23:33:05 eyak kernel: nouveau  [  DEVICE][0000:01:00.0] Family : NVE0
août 30 23:33:05 eyak kernel: nouveau  [   VBIOS][0000:01:00.0] using image from ACPI
août 30 23:33:05 eyak kernel: nouveau  [   VBIOS][0000:01:00.0] BIT signature found
août 30 23:33:05 eyak kernel: nouveau  [   VBIOS][0000:01:00.0] version 80.28.52.00.09
août 30 23:33:05 eyak kernel: nouveau W[   VBIOS][0000:01:00.0] DCB header validation failed
août 30 23:33:05 eyak kernel: nouveau W[   VBIOS][0000:01:00.0] DCB header validation failed
août 30 23:33:05 eyak kernel: nouveau  [ DEVINIT][0000:01:00.0] adaptor not initialised
août 30 23:33:05 eyak kernel: nouveau  [   VBIOS][0000:01:00.0] running init tables
août 30 23:33:05 eyak kernel: nouveau E[   VBIOS][0000:01:00.0] 0xd075[0]: unknown opcode 0xb1
août 30 23:33:05 eyak kernel: nouveau E[ DEVINIT][0000:01:00.0] init failed, -22
août 30 23:33:05 eyak kernel: nouveau E[     DRM] failed to create 0x00000080, -22
août 30 23:33:05 eyak kernel: nouveau: probe of 0000:01:00.0 failed with error -22

Note that the "0xd075[0]: unknown opcode 0xb1" varies. The previous boot had "0xce73[0]: unknown opcode 0x00"
And I did not upgrade the BIOS nor the kernel (4.2.0-rc8 from Debian).
Comment 15 René Krell 2015-10-22 07:29:41 UTC
Update: The nouveau driver still doesn't work on my ZBook 15 using kernel 4.2.3.
There has been a refactoring of the Nouveau source code in 4.3, but the relevant files seems to be left untouched.
Comment 16 Ilia Mirkin 2015-10-22 07:30:23 UTC
*** Bug 91402 has been marked as a duplicate of this bug. ***
Comment 17 Ilia Mirkin 2015-11-02 03:20:25 UTC
Could one of you post an acpidump from the laptop? Specifically interested in how the _ROM method is defined.
Comment 18 René Krell 2015-11-02 08:11:13 UTC
(In reply to Ilia Mirkin from comment #17)
> Could one of you post an acpidump from the laptop? Specifically interested
> in how the _ROM method is defined.

I can do that. Just two questions:
- Can I leave the native nvidia driver loaded (my workaround for the broken nouveau driver) when running acpidump or do I have to uninstall it an reactivate nouveau for this?
- Some special command line options to acpidump?
Comment 19 Ortwin Glück 2015-11-02 08:13:45 UTC
Created attachment 119333 [details]
acpidump -b
Comment 20 Ilia Mirkin 2015-11-02 08:17:01 UTC
(In reply to René from comment #18)
> (In reply to Ilia Mirkin from comment #17)
> > Could one of you post an acpidump from the laptop? Specifically interested
> > in how the _ROM method is defined.
> 
> I can do that. Just two questions:
> - Can I leave the native nvidia driver loaded (my workaround for the broken
> nouveau driver) when running acpidump or do I have to uninstall it an
> reactivate nouveau for this?

Running blob is fine, the ACPI tables are invariant of anything the OS does.

> - Some special command line options to acpidump?

Just run 'acpidump' and save the output (e.g. acpidump > zbook15.acpi)
Comment 21 Ilia Mirkin 2015-11-02 08:21:26 UTC
(In reply to Ortwin Glück from comment #19)
> Created attachment 119333 [details]
> acpidump -b

Sorry, I don't know what to do this. Can you get me the output without -b? These utilities are very finicky. Really I want to read the _ROM function and maybe a few others... normally I do acpidump, then acpixtract, then iasl -d. These tools don't like your output.
Comment 22 René Krell 2015-11-02 08:23:12 UTC
Created attachment 119334 [details]
acpidump (HP ZBook 15, nVidia GK208GLM [Quadro K610M], BIOS v31/03/2015)

Ok, here you are. There is already another acpidump.
Comment 23 Ortwin Glück 2015-11-02 08:45:52 UTC
Created attachment 119336 [details]
acpidump (HP ZBook 15, nVidia GK106GLM [Quadro K2100M], BIOS v08/13/2014)

OK, here hexdump version. Slightly different hardware than René's.
Comment 24 Ilia Mirkin 2015-11-02 08:46:47 UTC
Looks like this bios hard-codes a 4K return size for each bios chunk fetch. There is a "fast" and a "slow" method in nouveau... the fast one grabs it all in one go, while the "slow" one does it 4K at a time.

In drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c, try commenting out the line

                { 0, &nvbios_acpi_fast },

For some reason we're not detecting that it's fetching a bad bios...
Comment 25 Ortwin Glück 2015-11-02 08:53:33 UTC
Yes that fixes it for me. Tested with 4.3.0-rc6.
The slow version really is slower and causes a noticable delay during booting, but I don't really mind: work laptop boots only once a day.
Comment 26 Ilia Mirkin 2015-11-02 08:54:00 UTC
FTR, the _ROM function from both dumps (same thing):

            Method (_ROM, 2, NotSerialized)  // _ROM: Read-Only Memory
            {
                Local0 += Arg0 = (VRMB (0x04) + Local0)
                Local1 = (VRMS () - 0x04)
                If ((Arg0 < Local1))
                {
                    OperationRegion (OROM, SystemMemory, Local0, 0x1000)
                    Field (OROM, AnyAcc, NoLock, Preserve)
                    {
                        R4KB,   32768
                    }

                    Return (R4KB) /* \_SB_.PCI0.PEGP.DGFX._ROM.R4KB */
                }
                Else
                {
                    Local0 = Buffer (0x01)
                        {
                             0x00                                             /* . */
                        }
                    Return (Local0)
                }
            }
Comment 27 René Krell 2015-11-02 08:57:47 UTC
(In reply to Ilia Mirkin from comment #26)
> FTR, the _ROM function from both dumps (same thing):
> ...
>                              0x00                                           
> /* . */
> ...

Shouldn't this be also reported to HP? What do you think?
Comment 28 Ilia Mirkin 2015-11-02 09:00:48 UTC
(In reply to René Krell from comment #27)
> (In reply to Ilia Mirkin from comment #26)
> > FTR, the _ROM function from both dumps (same thing):
> > ...
> >                              0x00                                           
> > /* . */
> > ...
> 
> Shouldn't this be also reported to HP? What do you think?

This bit is fine, it handles the out-of-bounds case. The sad bit is

                    OperationRegion (OROM, SystemMemory, Local0, 0x1000)

Which hard-codes a 4K-sized region instead of taking it from Arg1. Feel free to give your contact at HP a call :)
Comment 29 René Krell 2015-11-02 09:13:07 UTC
(In reply to Ilia Mirkin from comment #28)
> ... Feel free to give your contact at HP a call :)

I will refer to this issue to not spread rumours :-)
Comment 30 Ilia Mirkin 2015-11-02 09:19:57 UTC
(In reply to Ilia Mirkin from comment #28)
> (In reply to René Krell from comment #27)
> > (In reply to Ilia Mirkin from comment #26)
> > > FTR, the _ROM function from both dumps (same thing):
> > > ...
> > >                              0x00                                           
> > > /* . */
> > > ...
> > 
> > Shouldn't this be also reported to HP? What do you think?
> 
> This bit is fine, it handles the out-of-bounds case. The sad bit is
> 
>                     OperationRegion (OROM, SystemMemory, Local0, 0x1000)
> 
> Which hard-codes a 4K-sized region instead of taking it from Arg1. Feel free
> to give your contact at HP a call :)

Actually judging from the comments in nouveau, the spec calls for precisely the behavior they implement. However most manufacturers just expose the full bios anyways, not a 4K-sized chunk.
Comment 31 Ortwin Glück 2015-11-02 09:21:59 UTC
The delays during boot are not caused by the bios shadow code but by this:
[    5.878439] nouveau E[  PGRAPH][0000:01:00.0] wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
[    7.877714] nouveau E[  PGRAPH][0000:01:00.0] wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
[    9.876992] nouveau E[  PGRAPH][0000:01:00.0] wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
[   11.876268] nouveau E[  PGRAPH][0000:01:00.0] wait for idle timeout (en: 1, ctxsw: 0, busy: 1)

So I think you could simply scrap the "fast" version and always use the 4K "slow" version for compatibility.
Comment 32 Ilia Mirkin 2015-11-02 09:24:26 UTC
(In reply to Ortwin Glück from comment #31)
> The delays during boot are not caused by the bios shadow code but by this:
> [    5.878439] nouveau E[  PGRAPH][0000:01:00.0] wait for idle timeout (en:
> 1, ctxsw: 0, busy: 1)
> [    7.877714] nouveau E[  PGRAPH][0000:01:00.0] wait for idle timeout (en:
> 1, ctxsw: 0, busy: 1)
> [    9.876992] nouveau E[  PGRAPH][0000:01:00.0] wait for idle timeout (en:
> 1, ctxsw: 0, busy: 1)
> [   11.876268] nouveau E[  PGRAPH][0000:01:00.0] wait for idle timeout (en:
> 1, ctxsw: 0, busy: 1)

Try

nouveau.config=War00C800_0=1

which will enable yet-another workaround.

> 
> So I think you could simply scrap the "fast" version and always use the 4K
> "slow" version for compatibility.

The old code was able to make the fallback just fine, apparently (since it broke when the rewrite happened). The new code should fall back as well, but... doesn't. Very odd.
Comment 33 Ortwin Glück 2015-11-02 09:32:52 UTC
(In reply to Ilia Mirkin from comment #32)
> nouveau.config=War00C800_0=1

Doesn't help, but don't worry now - different issue.

> The old code was able to make the fallback just fine, apparently (since it
> broke when the rewrite happened).

True. I think the fast/slow versions were also present in the old code.
Comment 34 Ilia Mirkin 2015-11-02 22:52:30 UTC
(In reply to Ortwin Glück from comment #33)
> (In reply to Ilia Mirkin from comment #32)
> > nouveau.config=War00C800_0=1
> 
> Doesn't help, but don't worry now - different issue.

Hmmm... did you see a "hw bug workaround enabled" line? Are you using Linux 4.3? [4.2 and older didn't have the workaround logic.]
Comment 35 Ortwin Glück 2015-11-03 17:02:48 UTC
(In reply to Ilia Mirkin from comment #34)
> Hmmm... did you see a "hw bug workaround enabled" line? Are you using Linux
> 4.3? [4.2 and older didn't have the workaround logic.]

Ok works fine in 4.3!

$ dmesg | grep workaround
[    4.082516] nouveau 0000:01:00.0: pmu: hw bug workaround enabled
[    4.194475] nouveau 0000:01:00.0: pmu: hw bug workaround enabled
Comment 36 vdanjean@free.fr 2015-11-07 00:31:57 UTC
I suffer from the same bug on HP ZBook. However, with the last Debian kernel (ie plain 4.3), I still got an 'error -22' and no "pmu: hw bug workaround enabled" log:

$ dmesg | grep nouveau
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.3.0-trunk-amd64 root=/dev/mapper/eyak-root ro nouveau.config=War00C800_0=1 apparmor=1 security=apparmor quiet
[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-4.3.0-trunk-amd64 root=/dev/mapper/eyak-root ro nouveau.config=War00C800_0=1 apparmor=1 security=apparmor quiet
[    4.459102] nouveau 0000:01:00.0: enabling device (0000 -> 0003)
[    4.459126] nouveau 0000:01:00.0: NVIDIA GK208 (108390a1)
[    4.462991] nouveau 0000:01:00.0: bios: version 80.28.52.00.09
[    4.462994] nouveau 0000:01:00.0: mxm: BIOS version 3.0
[    4.462995] nouveau 0000:01:00.0: bios: unknown ddc map v00
[    4.463695] nouveau 0000:01:00.0: devinit: 0xce73[0]: unknown opcode 0x00
[    4.463699] nouveau 0000:01:00.0: preinit failed with -22
[    4.463718] nouveau: DRM:dddddddd:00000080: init failed with -22
[    4.464046] nouveau: probe of 0000:01:00.0 failed with error -22

I will put in attachment the result of acpidump on my machine.

  Regards,
    Vincent
Comment 37 Ilia Mirkin 2015-11-07 00:33:58 UTC
(In reply to vdanjean@free.fr from comment #36)
> I suffer from the same bug on HP ZBook. However, with the last Debian kernel
> (ie plain 4.3), I still got an 'error -22' and no "pmu: hw bug workaround
> enabled" log:

You need to manually remove the "fast" acpi method. See my instructions in comment 24.
Comment 38 vdanjean@free.fr 2015-11-07 00:35:24 UTC
Created attachment 119456 [details]
acpidump (HP ZBook 15, NVidia GK208GLM [Quadro K610M], BIOS v21/07/2015)
Comment 39 vdanjean@free.fr 2015-11-07 00:38:14 UTC
I was thinking that the "nouveau.config=War00C800_0=1" workaround was enough with a plain 4.3 kernel.

So, I will try with your patch (but this will wait for tomorrow as I will need to recompile the kernel).

Thanks
  Vincent
Comment 40 Ilia Mirkin 2015-11-07 00:42:20 UTC
(In reply to vdanjean@free.fr from comment #39)
> I was thinking that the "nouveau.config=War00C800_0=1" workaround was enough
> with a plain 4.3 kernel.

No, that will do nothing for you -- that's only for GK104/GK106/GK107 boards. Yours is a GK208.
Comment 41 vdanjean@free.fr 2015-11-07 19:12:05 UTC
I just want to report that the fix work also for me :
$ xrandr --listproviders 
Providers: number : 2
Provider 0: id: 0x8d cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 3 associated providers: 0 name:Intel
Provider 1: id: 0x66 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 3 associated providers: 0 name:nouveau

I still have ACPI warnings when enabling or disabling the NVidia card but it seems to work nevertheless:
[23693.512790] ACPI Warning: \_SB_.PCI0.PEGP.DGFX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)
[23693.513206] ACPI: \_SB_.PCI0.PEGP.DGFX: failed to evaluate _DSM
[23693.513209] ACPI Warning: \_SB_.PCI0.PEGP.DGFX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150818/nsarguments-95)

Thank you very much
  Vincent
Comment 42 Ben Skeggs 2015-11-07 22:45:04 UTC
I should be receiving hardware with an issue similar to this during the week.  Hopefully the cause is the same and I can come up with a fix the lets us keep the "fast" method, as it saves quite a lot of boot time on (particularly) the laptop I primarily use :)
Comment 43 René Krell 2015-11-08 22:32:08 UTC
Just for the record:
I dropped a support question to HP regarding this issue: http://h30434.www3.hp.com/t5/Notebook-Display-and-Video/ZBook-15-BIOS-and-nouveau-incompatibility/m-p/5334943
The BIOS vendor should probably know this.
Please let me know if there is any inaccuracy in the description.
Comment 45 vdanjean@free.fr 2015-12-12 00:45:58 UTC
The last patch help. I tried it when I upgraded my kernel and I checked it works.

Without it, nouveau was failing at loading time

With it, I can use my NVidia card together with the Intel one.

Note that I tried the new kernel from Debian (package 4.3-1~exp2), it was less stable that 4.3-1~exp1. So I removed it, reinstall and repatch the 4.3-1~exp1 Debian kernel.
So, I can also certify that the new patch also works for the previous kernel where I applied the previous patch
Comment 46 René Krell 2016-05-31 15:19:36 UTC
Will this patches go into the main kernel driver?
Comment 47 Roy 2016-05-31 15:22:41 UTC
(In reply to René Krell from comment #46)
> Will this patches go into the main kernel driver?

It got merged in kernel 4.4-rc3 [1]. Please test and report when successful.

[1] http://lkml.iu.edu/hypermail/linux/kernel/1511.3/03588.html
Comment 48 René Krell 2016-05-31 15:39:15 UTC
(In reply to Roy from comment #47)
> (In reply to René Krell from comment #46)
> > Will this patches go into the main kernel driver?
> 
> It got merged in kernel 4.4-rc3 [1]. Please test and report when successful.
> 
> [1] http://lkml.iu.edu/hypermail/linux/kernel/1511.3/03588.html

There were tow patches mentioned by Ilja:
- http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=fcd74e81e65aee8a2a33bdca3142a5358dac7582 (This got merged as "drm/nouveau/bios: return actual size of the buffer retrieved via _ROM").
- https://bugs.freedesktop.org/show_bug.cgi?id=90626#c24 - removing the fast loading option (As far as I understand this one has been also necessary to make the HP ZBook 15 work. I can't see this officially. Is it obsolete or should just owners of that special hardware apply this patch?)
Comment 49 Roy 2016-05-31 16:05:43 UTC
(In reply to René Krell from comment #48)
> (In reply to Roy from comment #47)
> > (In reply to René Krell from comment #46)
> > > Will this patches go into the main kernel driver?
> > 
> > It got merged in kernel 4.4-rc3 [1]. Please test and report when successful.
> > 
> > [1] http://lkml.iu.edu/hypermail/linux/kernel/1511.3/03588.html
> 
> There were tow patches mentioned by Ilja:
> -
> http://cgit.freedesktop.org/~darktama/nouveau/commit/
> ?id=fcd74e81e65aee8a2a33bdca3142a5358dac7582 (This got merged as
> "drm/nouveau/bios: return actual size of the buffer retrieved via _ROM").
> - https://bugs.freedesktop.org/show_bug.cgi?id=90626#c24 - removing the fast
> loading option (As far as I understand this one has been also necessary to
> make the HP ZBook 15 work. I can't see this officially. Is it obsolete or
> should just owners of that special hardware apply this patch?)

Comment #45 seems to indicate that the patch carried upstream should be sufficient to fix this bug, but please test and report when successful.
Comment 50 vdanjean@free.fr 2016-05-31 18:51:13 UTC
  Hi,

  As requested, I can confirm that upstream kernel works (in my case, these are Debian packaged kernels). I cannot tell exactly from which version it works, but 4.4-rc3 looks possible to me. The Debian bug report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772716) marks it fixed in the 4.3.1-1 version (i.e. the patch was probably backported to the stable series)
  Recently (kernel > 4.5.x), the nouveau kernel driver is not automatically loaded at startup, so I need to run "modprobe nouveau" manually. But this is another bug that I did not investigate (nor report) for now.

  For me, this bug can be closed.

  Regards,
    Vincent
Comment 51 René Krell 2016-06-01 07:20:40 UTC
I was also able to reactivate nouveau on a HP ZBook 15 G2, OpenSUSE Tumbleweed 20160530, kernel 4.5.4-1-default and start X and KDE Plasma 5 on it. The patch seems to work fine.

There are some different issues in several applications, I'll try to address them separately.

Thank you all.
Comment 52 René Krell 2016-06-01 08:51:48 UTC
Just for the record: I'm now affected by https://bugs.freedesktop.org/show_bug.cgi?id=95054 on the same hardware (HP ZBook 15 G2). nouveau is freezing in accelerating Plasma 5 Desktop after a while.
Comment 53 Roy 2016-06-01 10:54:16 UTC
(In reply to René Krell from comment #52)
> Just for the record: I'm now affected by
> https://bugs.freedesktop.org/show_bug.cgi?id=95054 on the same hardware (HP
> ZBook 15 G2). nouveau is freezing in accelerating Plasma 5 Desktop after a
> while.

Thank you for your feedback. We'll discuss the other issues in separate bug reports.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.