| Message ID | 537F4425.70205@redhat.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 23 May 2014 13:50, Hans de Goede <hdegoede@redhat.com> wrote: > Hi Lewis et all, > > On 05/23/2014 02:07 PM, Lewis Toohey wrote: >> On 23 May 2014 02:34, Aaron Lu <aaron.lu@intel.com> wrote: >>> On 05/21/2014 09:02 PM, Lewis Toohey wrote: >>>> Hi Aaron >>>> >>>> I followed your instructions and can report some limited success. I >>>> have two interfaces listed in /sys/class/backlight namely: >>>> acpi_video0 radeon_bl0 >>>> >>>> max_brightness for acpi_video0 is 11. Echo-ing new values to >>>> brightness appears to have no effect. >>>> >>>> max_brightness for radeon_bl0 is 255. Echo-ing new values to >>>> brightness does adjust the screen brightness as you would expect. >>>> >>>> Results are the same on both battery and powered. >>>> >>>> I hope that is useful. >>> >>> I think Hans' patchset should solve your problem, can you please give it >>> a try? You will need to pass the video.use_native_backlight=1 to kernel >>> cmdline when testing, thanks. >>> >>> [PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau >>> http://www.spinics.net/lists/dri-devel/msg59941.html >>> >>> -Aaron >> >> Aaron >> >> Thank you for this. Unfortunately I am going to have to ask you for a >> bit of help here as I am now, officially, "out of my depth". I >> appreciate this is a pain as you will have to take time explaining it >> to me and I apologise for that. >> >> I have figured out how to pass the kernel command line argument, this >> is not an issue. >> >> I have located the patch you refer to here: >> https://bugzilla.redhat.com/attachment.cgi?id=894577 >> (which I believe is correct) but I cannot figure out how to apply it. > > That is not the right patch, you need a set of 2 patches. I've attached > them to this mail. Note please ignore the numbering starting at 6, these > are the 2 patches you need. You will need to build a Linux kernel with > these 2 patches applied, see your distributions documentation on how > to build a kernel from source. > > I don't know which distro you are using, I've a Fedora kernel with this > patches included available here: > > http://people.fedoraproject.org/~jwrdegoede/rhbz1093171/ > > Regards, > > Hans Hans Thank you for this. Apparently my understanding was way off! Building a kernel is new territory for me, however, there appears to be a relatively straightforward guide here: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel. I will attempt to follow this tonight and apply the patches that you have kindly provided. Assuming I manage it I will then report back to yourself and Aaron. Many thanks
On 23 May 2014 13:50, Hans de Goede <hdegoede@redhat.com> wrote: > Hi Lewis et all, > > On 05/23/2014 02:07 PM, Lewis Toohey wrote: >> On 23 May 2014 02:34, Aaron Lu <aaron.lu@intel.com> wrote: >>> On 05/21/2014 09:02 PM, Lewis Toohey wrote: >>>> Hi Aaron >>>> >>>> I followed your instructions and can report some limited success. I >>>> have two interfaces listed in /sys/class/backlight namely: >>>> acpi_video0 radeon_bl0 >>>> >>>> max_brightness for acpi_video0 is 11. Echo-ing new values to >>>> brightness appears to have no effect. >>>> >>>> max_brightness for radeon_bl0 is 255. Echo-ing new values to >>>> brightness does adjust the screen brightness as you would expect. >>>> >>>> Results are the same on both battery and powered. >>>> >>>> I hope that is useful. >>> >>> I think Hans' patchset should solve your problem, can you please give it >>> a try? You will need to pass the video.use_native_backlight=1 to kernel >>> cmdline when testing, thanks. >>> >>> [PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau >>> http://www.spinics.net/lists/dri-devel/msg59941.html >>> >>> -Aaron >> >> Aaron >> >> Thank you for this. Unfortunately I am going to have to ask you for a >> bit of help here as I am now, officially, "out of my depth". I >> appreciate this is a pain as you will have to take time explaining it >> to me and I apologise for that. >> >> I have figured out how to pass the kernel command line argument, this >> is not an issue. >> >> I have located the patch you refer to here: >> https://bugzilla.redhat.com/attachment.cgi?id=894577 >> (which I believe is correct) but I cannot figure out how to apply it. > > That is not the right patch, you need a set of 2 patches. I've attached > them to this mail. Note please ignore the numbering starting at 6, these > are the 2 patches you need. You will need to build a Linux kernel with > these 2 patches applied, see your distributions documentation on how > to build a kernel from source. > > I don't know which distro you are using, I've a Fedora kernel with this > patches included available here: > > http://people.fedoraproject.org/~jwrdegoede/rhbz1093171/ > > Regards, > > Hans Hans / Aaron Just by way of an update, I am trying to test this but have run into another gap in my knowledge. Essentially I can compile the standard ubuntu kernel (3.13) but the patch breaks this (I assume because the patch was written for a more recent kernel version). I don't know how to compile upstream kernels for ubuntu and have asked for help here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1315834/comments/21 I will let you know when I make some progress. Thank you again for your efforts here. Much appreciated.
On 23 May 2014 13:50, Hans de Goede <hdegoede@redhat.com> wrote: > Hi Lewis et all, > > On 05/23/2014 02:07 PM, Lewis Toohey wrote: >> On 23 May 2014 02:34, Aaron Lu <aaron.lu@intel.com> wrote: >>> On 05/21/2014 09:02 PM, Lewis Toohey wrote: >>>> Hi Aaron >>>> >>>> I followed your instructions and can report some limited success. I >>>> have two interfaces listed in /sys/class/backlight namely: >>>> acpi_video0 radeon_bl0 >>>> >>>> max_brightness for acpi_video0 is 11. Echo-ing new values to >>>> brightness appears to have no effect. >>>> >>>> max_brightness for radeon_bl0 is 255. Echo-ing new values to >>>> brightness does adjust the screen brightness as you would expect. >>>> >>>> Results are the same on both battery and powered. >>>> >>>> I hope that is useful. >>> >>> I think Hans' patchset should solve your problem, can you please give it >>> a try? You will need to pass the video.use_native_backlight=1 to kernel >>> cmdline when testing, thanks. >>> >>> [PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau >>> http://www.spinics.net/lists/dri-devel/msg59941.html >>> >>> -Aaron >> >> Aaron >> >> Thank you for this. Unfortunately I am going to have to ask you for a >> bit of help here as I am now, officially, "out of my depth". I >> appreciate this is a pain as you will have to take time explaining it >> to me and I apologise for that. >> >> I have figured out how to pass the kernel command line argument, this >> is not an issue. >> >> I have located the patch you refer to here: >> https://bugzilla.redhat.com/attachment.cgi?id=894577 >> (which I believe is correct) but I cannot figure out how to apply it. > > That is not the right patch, you need a set of 2 patches. I've attached > them to this mail. Note please ignore the numbering starting at 6, these > are the 2 patches you need. You will need to build a Linux kernel with > these 2 patches applied, see your distributions documentation on how > to build a kernel from source. > > I don't know which distro you are using, I've a Fedora kernel with this > patches included available here: > > http://people.fedoraproject.org/~jwrdegoede/rhbz1093171/ > > Regards, > > Hans Hans Unfortunately I am unable to apply these patches against the latest mainline kernel. I get two fails when applying the second patch file and then the kernel will not compile. Please see output information below. Can you advise? Many thanks ===APPLYING PATCHES TO LATEST MAINLINE KERNEL==== lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < 0006-backlight-Add-backlight-device-un-registration-notif.patch (Stripping trailing CRs from patch; use --binary to disable.) patching file drivers/video/backlight/backlight.c (Stripping trailing CRs from patch; use --binary to disable.) patching file include/linux/backlight.h lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < 0007-acpi-video-Unregister-the-backlight-device-if-a-raw-.patch (Stripping trailing CRs from patch; use --binary to disable.) patching file drivers/acpi/video.c Hunk #1 FAILED at 151. Hunk #2 succeeded at 161 (offset -1 lines). Hunk #3 FAILED at 1837. Hunk #4 succeeded at 1868 (offset -113 lines). Hunk #5 succeeded at 1999 (offset -113 lines). Hunk #6 succeeded at 2023 (offset -113 lines). 2 out of 6 hunks FAILED -- saving rejects to file drivers/acpi/video.c.rej ==LAST LINES OF BUILD BEFORE FAIL=== CC [M] fs/xfs/xfs_ioctl32.o LD [M] fs/xfs/xfs.o make[1]: Leaving directory `/home/lewis/KernelTesting/Kernel/linux' make: *** [debian/stamp/build/kernel] Error 2 lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$
On 05/26/2014 04:42 AM, Lewis Toohey wrote: > On 23 May 2014 13:50, Hans de Goede <hdegoede@redhat.com> wrote: >> Hi Lewis et all, >> >> On 05/23/2014 02:07 PM, Lewis Toohey wrote: >>> On 23 May 2014 02:34, Aaron Lu <aaron.lu@intel.com> wrote: >>>> On 05/21/2014 09:02 PM, Lewis Toohey wrote: >>>>> Hi Aaron >>>>> >>>>> I followed your instructions and can report some limited success. I >>>>> have two interfaces listed in /sys/class/backlight namely: >>>>> acpi_video0 radeon_bl0 >>>>> >>>>> max_brightness for acpi_video0 is 11. Echo-ing new values to >>>>> brightness appears to have no effect. >>>>> >>>>> max_brightness for radeon_bl0 is 255. Echo-ing new values to >>>>> brightness does adjust the screen brightness as you would expect. >>>>> >>>>> Results are the same on both battery and powered. >>>>> >>>>> I hope that is useful. >>>> >>>> I think Hans' patchset should solve your problem, can you please give it >>>> a try? You will need to pass the video.use_native_backlight=1 to kernel >>>> cmdline when testing, thanks. >>>> >>>> [PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau >>>> http://www.spinics.net/lists/dri-devel/msg59941.html >>>> >>>> -Aaron >>> >>> Aaron >>> >>> Thank you for this. Unfortunately I am going to have to ask you for a >>> bit of help here as I am now, officially, "out of my depth". I >>> appreciate this is a pain as you will have to take time explaining it >>> to me and I apologise for that. >>> >>> I have figured out how to pass the kernel command line argument, this >>> is not an issue. >>> >>> I have located the patch you refer to here: >>> https://bugzilla.redhat.com/attachment.cgi?id=894577 >>> (which I believe is correct) but I cannot figure out how to apply it. >> >> That is not the right patch, you need a set of 2 patches. I've attached >> them to this mail. Note please ignore the numbering starting at 6, these >> are the 2 patches you need. You will need to build a Linux kernel with >> these 2 patches applied, see your distributions documentation on how >> to build a kernel from source. >> >> I don't know which distro you are using, I've a Fedora kernel with this >> patches included available here: >> >> http://people.fedoraproject.org/~jwrdegoede/rhbz1093171/ >> >> Regards, >> >> Hans > > Hans > > Unfortunately I am unable to apply these patches against the latest > mainline kernel. I get two fails when applying the second patch file > and then the kernel will not compile. Please see output information > below. I've prepared a git branch for you: https://github.com/aaronlu/linux.git for-lewis It's based on Rafael's linux-next plus Hans' patch 2 and 3. Thanks, Aaron > > Can you advise? > > Many thanks > > ===APPLYING PATCHES TO LATEST MAINLINE KERNEL==== > > lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < > 0006-backlight-Add-backlight-device-un-registration-notif.patch > (Stripping trailing CRs from patch; use --binary to disable.) > patching file drivers/video/backlight/backlight.c > (Stripping trailing CRs from patch; use --binary to disable.) > patching file include/linux/backlight.h > lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < > 0007-acpi-video-Unregister-the-backlight-device-if-a-raw-.patch > (Stripping trailing CRs from patch; use --binary to disable.) > patching file drivers/acpi/video.c > Hunk #1 FAILED at 151. > Hunk #2 succeeded at 161 (offset -1 lines). > Hunk #3 FAILED at 1837. > Hunk #4 succeeded at 1868 (offset -113 lines). > Hunk #5 succeeded at 1999 (offset -113 lines). > Hunk #6 succeeded at 2023 (offset -113 lines). > 2 out of 6 hunks FAILED -- saving rejects to file drivers/acpi/video.c.rej > > > ==LAST LINES OF BUILD BEFORE FAIL=== > > CC [M] fs/xfs/xfs_ioctl32.o > LD [M] fs/xfs/xfs.o > make[1]: Leaving directory `/home/lewis/KernelTesting/Kernel/linux' > make: *** [debian/stamp/build/kernel] Error 2 > lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ > > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 26 May 2014 06:48, Aaron Lu <aaron.lu@intel.com> wrote: > On 05/26/2014 04:42 AM, Lewis Toohey wrote: >> On 23 May 2014 13:50, Hans de Goede <hdegoede@redhat.com> wrote: >>> Hi Lewis et all, >>> >>> On 05/23/2014 02:07 PM, Lewis Toohey wrote: >>>> On 23 May 2014 02:34, Aaron Lu <aaron.lu@intel.com> wrote: >>>>> On 05/21/2014 09:02 PM, Lewis Toohey wrote: >>>>>> Hi Aaron >>>>>> >>>>>> I followed your instructions and can report some limited success. I >>>>>> have two interfaces listed in /sys/class/backlight namely: >>>>>> acpi_video0 radeon_bl0 >>>>>> >>>>>> max_brightness for acpi_video0 is 11. Echo-ing new values to >>>>>> brightness appears to have no effect. >>>>>> >>>>>> max_brightness for radeon_bl0 is 255. Echo-ing new values to >>>>>> brightness does adjust the screen brightness as you would expect. >>>>>> >>>>>> Results are the same on both battery and powered. >>>>>> >>>>>> I hope that is useful. >>>>> >>>>> I think Hans' patchset should solve your problem, can you please give it >>>>> a try? You will need to pass the video.use_native_backlight=1 to kernel >>>>> cmdline when testing, thanks. >>>>> >>>>> [PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau >>>>> http://www.spinics.net/lists/dri-devel/msg59941.html >>>>> >>>>> -Aaron >>>> >>>> Aaron >>>> >>>> Thank you for this. Unfortunately I am going to have to ask you for a >>>> bit of help here as I am now, officially, "out of my depth". I >>>> appreciate this is a pain as you will have to take time explaining it >>>> to me and I apologise for that. >>>> >>>> I have figured out how to pass the kernel command line argument, this >>>> is not an issue. >>>> >>>> I have located the patch you refer to here: >>>> https://bugzilla.redhat.com/attachment.cgi?id=894577 >>>> (which I believe is correct) but I cannot figure out how to apply it. >>> >>> That is not the right patch, you need a set of 2 patches. I've attached >>> them to this mail. Note please ignore the numbering starting at 6, these >>> are the 2 patches you need. You will need to build a Linux kernel with >>> these 2 patches applied, see your distributions documentation on how >>> to build a kernel from source. >>> >>> I don't know which distro you are using, I've a Fedora kernel with this >>> patches included available here: >>> >>> http://people.fedoraproject.org/~jwrdegoede/rhbz1093171/ >>> >>> Regards, >>> >>> Hans >> >> Hans >> >> Unfortunately I am unable to apply these patches against the latest >> mainline kernel. I get two fails when applying the second patch file >> and then the kernel will not compile. Please see output information >> below. > > I've prepared a git branch for you: > https://github.com/aaronlu/linux.git for-lewis > > It's based on Rafael's linux-next plus Hans' patch 2 and 3. > > Thanks, > Aaron > >> >> Can you advise? >> >> Many thanks >> >> ===APPLYING PATCHES TO LATEST MAINLINE KERNEL==== >> >> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < >> 0006-backlight-Add-backlight-device-un-registration-notif.patch >> (Stripping trailing CRs from patch; use --binary to disable.) >> patching file drivers/video/backlight/backlight.c >> (Stripping trailing CRs from patch; use --binary to disable.) >> patching file include/linux/backlight.h >> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < >> 0007-acpi-video-Unregister-the-backlight-device-if-a-raw-.patch >> (Stripping trailing CRs from patch; use --binary to disable.) >> patching file drivers/acpi/video.c >> Hunk #1 FAILED at 151. >> Hunk #2 succeeded at 161 (offset -1 lines). >> Hunk #3 FAILED at 1837. >> Hunk #4 succeeded at 1868 (offset -113 lines). >> Hunk #5 succeeded at 1999 (offset -113 lines). >> Hunk #6 succeeded at 2023 (offset -113 lines). >> 2 out of 6 hunks FAILED -- saving rejects to file drivers/acpi/video.c.rej >> >> >> ==LAST LINES OF BUILD BEFORE FAIL=== >> >> CC [M] fs/xfs/xfs_ioctl32.o >> LD [M] fs/xfs/xfs.o >> make[1]: Leaving directory `/home/lewis/KernelTesting/Kernel/linux' >> make: *** [debian/stamp/build/kernel] Error 2 >> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ >> >> > Aaron Many thanks for this. I can confirm that booting with this kernel and passing the video.use_native_backlight = 1 argument means that the backlight works perfectly on my laptop (both using the keyboard hot keys and the gnome/unity settings applet). I'll post to the ubuntu launchpad page later with instructions for other people to do this. I assume its presence in the linux-next tree means that it will be fixed in an upcoming kernel release? (sorry, I don't know quite how the process works). If I can provide more information or do some more useful testing please do not hesitate to let me know. Thank you both for your help - really appreciated.
On 26 May 2014 13:18, Lewis Toohey <lewis@toohey.co.uk> wrote: > On 26 May 2014 06:48, Aaron Lu <aaron.lu@intel.com> wrote: >> On 05/26/2014 04:42 AM, Lewis Toohey wrote: >>> On 23 May 2014 13:50, Hans de Goede <hdegoede@redhat.com> wrote: >>>> Hi Lewis et all, >>>> >>>> On 05/23/2014 02:07 PM, Lewis Toohey wrote: >>>>> On 23 May 2014 02:34, Aaron Lu <aaron.lu@intel.com> wrote: >>>>>> On 05/21/2014 09:02 PM, Lewis Toohey wrote: >>>>>>> Hi Aaron >>>>>>> >>>>>>> I followed your instructions and can report some limited success. I >>>>>>> have two interfaces listed in /sys/class/backlight namely: >>>>>>> acpi_video0 radeon_bl0 >>>>>>> >>>>>>> max_brightness for acpi_video0 is 11. Echo-ing new values to >>>>>>> brightness appears to have no effect. >>>>>>> >>>>>>> max_brightness for radeon_bl0 is 255. Echo-ing new values to >>>>>>> brightness does adjust the screen brightness as you would expect. >>>>>>> >>>>>>> Results are the same on both battery and powered. >>>>>>> >>>>>>> I hope that is useful. >>>>>> >>>>>> I think Hans' patchset should solve your problem, can you please give it >>>>>> a try? You will need to pass the video.use_native_backlight=1 to kernel >>>>>> cmdline when testing, thanks. >>>>>> >>>>>> [PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau >>>>>> http://www.spinics.net/lists/dri-devel/msg59941.html >>>>>> >>>>>> -Aaron >>>>> >>>>> Aaron >>>>> >>>>> Thank you for this. Unfortunately I am going to have to ask you for a >>>>> bit of help here as I am now, officially, "out of my depth". I >>>>> appreciate this is a pain as you will have to take time explaining it >>>>> to me and I apologise for that. >>>>> >>>>> I have figured out how to pass the kernel command line argument, this >>>>> is not an issue. >>>>> >>>>> I have located the patch you refer to here: >>>>> https://bugzilla.redhat.com/attachment.cgi?id=894577 >>>>> (which I believe is correct) but I cannot figure out how to apply it. >>>> >>>> That is not the right patch, you need a set of 2 patches. I've attached >>>> them to this mail. Note please ignore the numbering starting at 6, these >>>> are the 2 patches you need. You will need to build a Linux kernel with >>>> these 2 patches applied, see your distributions documentation on how >>>> to build a kernel from source. >>>> >>>> I don't know which distro you are using, I've a Fedora kernel with this >>>> patches included available here: >>>> >>>> http://people.fedoraproject.org/~jwrdegoede/rhbz1093171/ >>>> >>>> Regards, >>>> >>>> Hans >>> >>> Hans >>> >>> Unfortunately I am unable to apply these patches against the latest >>> mainline kernel. I get two fails when applying the second patch file >>> and then the kernel will not compile. Please see output information >>> below. >> >> I've prepared a git branch for you: >> https://github.com/aaronlu/linux.git for-lewis >> >> It's based on Rafael's linux-next plus Hans' patch 2 and 3. >> >> Thanks, >> Aaron >> >>> >>> Can you advise? >>> >>> Many thanks >>> >>> ===APPLYING PATCHES TO LATEST MAINLINE KERNEL==== >>> >>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < >>> 0006-backlight-Add-backlight-device-un-registration-notif.patch >>> (Stripping trailing CRs from patch; use --binary to disable.) >>> patching file drivers/video/backlight/backlight.c >>> (Stripping trailing CRs from patch; use --binary to disable.) >>> patching file include/linux/backlight.h >>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < >>> 0007-acpi-video-Unregister-the-backlight-device-if-a-raw-.patch >>> (Stripping trailing CRs from patch; use --binary to disable.) >>> patching file drivers/acpi/video.c >>> Hunk #1 FAILED at 151. >>> Hunk #2 succeeded at 161 (offset -1 lines). >>> Hunk #3 FAILED at 1837. >>> Hunk #4 succeeded at 1868 (offset -113 lines). >>> Hunk #5 succeeded at 1999 (offset -113 lines). >>> Hunk #6 succeeded at 2023 (offset -113 lines). >>> 2 out of 6 hunks FAILED -- saving rejects to file drivers/acpi/video.c.rej >>> >>> >>> ==LAST LINES OF BUILD BEFORE FAIL=== >>> >>> CC [M] fs/xfs/xfs_ioctl32.o >>> LD [M] fs/xfs/xfs.o >>> make[1]: Leaving directory `/home/lewis/KernelTesting/Kernel/linux' >>> make: *** [debian/stamp/build/kernel] Error 2 >>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ >>> >>> >> > > Aaron > > Many thanks for this. I can confirm that booting with this kernel and > passing the video.use_native_backlight = 1 argument means that the > backlight works perfectly on my laptop (both using the keyboard hot > keys and the gnome/unity settings applet). > > I'll post to the ubuntu launchpad page later with instructions for > other people to do this. I assume its presence in the linux-next tree > means that it will be fixed in an upcoming kernel release? (sorry, I > don't know quite how the process works). > > If I can provide more information or do some more useful testing > please do not hesitate to let me know. > > Thank you both for your help - really appreciated. > > -- > Lewis > Aaron Just one final point in case it is relevant / useful - although it fixes the backlight issue this kernel version breaks the suspend resume functionality for me (the system will suspend but cannot come back from it). Not asking for a fix (appreciate it is a testing base), just thought it might be useful to know. Thanks again
On 05/27/2014 03:09 AM, Lewis Toohey wrote: > On 26 May 2014 13:18, Lewis Toohey <lewis@toohey.co.uk> wrote: >> On 26 May 2014 06:48, Aaron Lu <aaron.lu@intel.com> wrote: >>> On 05/26/2014 04:42 AM, Lewis Toohey wrote: >>>> On 23 May 2014 13:50, Hans de Goede <hdegoede@redhat.com> wrote: >>>>> Hi Lewis et all, >>>>> >>>>> On 05/23/2014 02:07 PM, Lewis Toohey wrote: >>>>>> On 23 May 2014 02:34, Aaron Lu <aaron.lu@intel.com> wrote: >>>>>>> On 05/21/2014 09:02 PM, Lewis Toohey wrote: >>>>>>>> Hi Aaron >>>>>>>> >>>>>>>> I followed your instructions and can report some limited success. I >>>>>>>> have two interfaces listed in /sys/class/backlight namely: >>>>>>>> acpi_video0 radeon_bl0 >>>>>>>> >>>>>>>> max_brightness for acpi_video0 is 11. Echo-ing new values to >>>>>>>> brightness appears to have no effect. >>>>>>>> >>>>>>>> max_brightness for radeon_bl0 is 255. Echo-ing new values to >>>>>>>> brightness does adjust the screen brightness as you would expect. >>>>>>>> >>>>>>>> Results are the same on both battery and powered. >>>>>>>> >>>>>>>> I hope that is useful. >>>>>>> >>>>>>> I think Hans' patchset should solve your problem, can you please give it >>>>>>> a try? You will need to pass the video.use_native_backlight=1 to kernel >>>>>>> cmdline when testing, thanks. >>>>>>> >>>>>>> [PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau >>>>>>> http://www.spinics.net/lists/dri-devel/msg59941.html >>>>>>> >>>>>>> -Aaron >>>>>> >>>>>> Aaron >>>>>> >>>>>> Thank you for this. Unfortunately I am going to have to ask you for a >>>>>> bit of help here as I am now, officially, "out of my depth". I >>>>>> appreciate this is a pain as you will have to take time explaining it >>>>>> to me and I apologise for that. >>>>>> >>>>>> I have figured out how to pass the kernel command line argument, this >>>>>> is not an issue. >>>>>> >>>>>> I have located the patch you refer to here: >>>>>> https://bugzilla.redhat.com/attachment.cgi?id=894577 >>>>>> (which I believe is correct) but I cannot figure out how to apply it. >>>>> >>>>> That is not the right patch, you need a set of 2 patches. I've attached >>>>> them to this mail. Note please ignore the numbering starting at 6, these >>>>> are the 2 patches you need. You will need to build a Linux kernel with >>>>> these 2 patches applied, see your distributions documentation on how >>>>> to build a kernel from source. >>>>> >>>>> I don't know which distro you are using, I've a Fedora kernel with this >>>>> patches included available here: >>>>> >>>>> http://people.fedoraproject.org/~jwrdegoede/rhbz1093171/ >>>>> >>>>> Regards, >>>>> >>>>> Hans >>>> >>>> Hans >>>> >>>> Unfortunately I am unable to apply these patches against the latest >>>> mainline kernel. I get two fails when applying the second patch file >>>> and then the kernel will not compile. Please see output information >>>> below. >>> >>> I've prepared a git branch for you: >>> https://github.com/aaronlu/linux.git for-lewis >>> >>> It's based on Rafael's linux-next plus Hans' patch 2 and 3. >>> >>> Thanks, >>> Aaron >>> >>>> >>>> Can you advise? >>>> >>>> Many thanks >>>> >>>> ===APPLYING PATCHES TO LATEST MAINLINE KERNEL==== >>>> >>>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < >>>> 0006-backlight-Add-backlight-device-un-registration-notif.patch >>>> (Stripping trailing CRs from patch; use --binary to disable.) >>>> patching file drivers/video/backlight/backlight.c >>>> (Stripping trailing CRs from patch; use --binary to disable.) >>>> patching file include/linux/backlight.h >>>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < >>>> 0007-acpi-video-Unregister-the-backlight-device-if-a-raw-.patch >>>> (Stripping trailing CRs from patch; use --binary to disable.) >>>> patching file drivers/acpi/video.c >>>> Hunk #1 FAILED at 151. >>>> Hunk #2 succeeded at 161 (offset -1 lines). >>>> Hunk #3 FAILED at 1837. >>>> Hunk #4 succeeded at 1868 (offset -113 lines). >>>> Hunk #5 succeeded at 1999 (offset -113 lines). >>>> Hunk #6 succeeded at 2023 (offset -113 lines). >>>> 2 out of 6 hunks FAILED -- saving rejects to file drivers/acpi/video.c.rej >>>> >>>> >>>> ==LAST LINES OF BUILD BEFORE FAIL=== >>>> >>>> CC [M] fs/xfs/xfs_ioctl32.o >>>> LD [M] fs/xfs/xfs.o >>>> make[1]: Leaving directory `/home/lewis/KernelTesting/Kernel/linux' >>>> make: *** [debian/stamp/build/kernel] Error 2 >>>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ >>>> >>>> >>> >> >> Aaron >> >> Many thanks for this. I can confirm that booting with this kernel and >> passing the video.use_native_backlight = 1 argument means that the >> backlight works perfectly on my laptop (both using the keyboard hot >> keys and the gnome/unity settings applet). >> >> I'll post to the ubuntu launchpad page later with instructions for >> other people to do this. I assume its presence in the linux-next tree >> means that it will be fixed in an upcoming kernel release? (sorry, I >> don't know quite how the process works). >> >> If I can provide more information or do some more useful testing >> please do not hesitate to let me know. >> >> Thank you both for your help - really appreciated. >> >> -- >> Lewis >> > > Aaron > > Just one final point in case it is relevant / useful - although it > fixes the backlight issue this kernel version breaks the suspend > resume functionality for me (the system will suspend but cannot come > back from it). That sounds like a regression somewhere and a git bisect would be great if that's possible for you. Thanks, Aaron > > Not asking for a fix (appreciate it is a testing base), just thought > it might be useful to know. > > Thanks again > > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aaron I am in the process of performing this bisection, however, I need a bit of advice. I have got a mix of results following suspend right through from (i) system reboot; (ii) "low graphics mode" error; (iii) restore but sluggish performance; and (iv) restore but *very* sluggish performance. What should qualify as a bad commit? Anything other than a "perfect" restore? Many thanks On 27 May 2014 02:12, Aaron Lu <aaron.lu@intel.com> wrote: > On 05/27/2014 03:09 AM, Lewis Toohey wrote: >> On 26 May 2014 13:18, Lewis Toohey <lewis@toohey.co.uk> wrote: >>> On 26 May 2014 06:48, Aaron Lu <aaron.lu@intel.com> wrote: >>>> On 05/26/2014 04:42 AM, Lewis Toohey wrote: >>>>> On 23 May 2014 13:50, Hans de Goede <hdegoede@redhat.com> wrote: >>>>>> Hi Lewis et all, >>>>>> >>>>>> On 05/23/2014 02:07 PM, Lewis Toohey wrote: >>>>>>> On 23 May 2014 02:34, Aaron Lu <aaron.lu@intel.com> wrote: >>>>>>>> On 05/21/2014 09:02 PM, Lewis Toohey wrote: >>>>>>>>> Hi Aaron >>>>>>>>> >>>>>>>>> I followed your instructions and can report some limited success. I >>>>>>>>> have two interfaces listed in /sys/class/backlight namely: >>>>>>>>> acpi_video0 radeon_bl0 >>>>>>>>> >>>>>>>>> max_brightness for acpi_video0 is 11. Echo-ing new values to >>>>>>>>> brightness appears to have no effect. >>>>>>>>> >>>>>>>>> max_brightness for radeon_bl0 is 255. Echo-ing new values to >>>>>>>>> brightness does adjust the screen brightness as you would expect. >>>>>>>>> >>>>>>>>> Results are the same on both battery and powered. >>>>>>>>> >>>>>>>>> I hope that is useful. >>>>>>>> >>>>>>>> I think Hans' patchset should solve your problem, can you please give it >>>>>>>> a try? You will need to pass the video.use_native_backlight=1 to kernel >>>>>>>> cmdline when testing, thanks. >>>>>>>> >>>>>>>> [PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau >>>>>>>> http://www.spinics.net/lists/dri-devel/msg59941.html >>>>>>>> >>>>>>>> -Aaron >>>>>>> >>>>>>> Aaron >>>>>>> >>>>>>> Thank you for this. Unfortunately I am going to have to ask you for a >>>>>>> bit of help here as I am now, officially, "out of my depth". I >>>>>>> appreciate this is a pain as you will have to take time explaining it >>>>>>> to me and I apologise for that. >>>>>>> >>>>>>> I have figured out how to pass the kernel command line argument, this >>>>>>> is not an issue. >>>>>>> >>>>>>> I have located the patch you refer to here: >>>>>>> https://bugzilla.redhat.com/attachment.cgi?id=894577 >>>>>>> (which I believe is correct) but I cannot figure out how to apply it. >>>>>> >>>>>> That is not the right patch, you need a set of 2 patches. I've attached >>>>>> them to this mail. Note please ignore the numbering starting at 6, these >>>>>> are the 2 patches you need. You will need to build a Linux kernel with >>>>>> these 2 patches applied, see your distributions documentation on how >>>>>> to build a kernel from source. >>>>>> >>>>>> I don't know which distro you are using, I've a Fedora kernel with this >>>>>> patches included available here: >>>>>> >>>>>> http://people.fedoraproject.org/~jwrdegoede/rhbz1093171/ >>>>>> >>>>>> Regards, >>>>>> >>>>>> Hans >>>>> >>>>> Hans >>>>> >>>>> Unfortunately I am unable to apply these patches against the latest >>>>> mainline kernel. I get two fails when applying the second patch file >>>>> and then the kernel will not compile. Please see output information >>>>> below. >>>> >>>> I've prepared a git branch for you: >>>> https://github.com/aaronlu/linux.git for-lewis >>>> >>>> It's based on Rafael's linux-next plus Hans' patch 2 and 3. >>>> >>>> Thanks, >>>> Aaron >>>> >>>>> >>>>> Can you advise? >>>>> >>>>> Many thanks >>>>> >>>>> ===APPLYING PATCHES TO LATEST MAINLINE KERNEL==== >>>>> >>>>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < >>>>> 0006-backlight-Add-backlight-device-un-registration-notif.patch >>>>> (Stripping trailing CRs from patch; use --binary to disable.) >>>>> patching file drivers/video/backlight/backlight.c >>>>> (Stripping trailing CRs from patch; use --binary to disable.) >>>>> patching file include/linux/backlight.h >>>>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < >>>>> 0007-acpi-video-Unregister-the-backlight-device-if-a-raw-.patch >>>>> (Stripping trailing CRs from patch; use --binary to disable.) >>>>> patching file drivers/acpi/video.c >>>>> Hunk #1 FAILED at 151. >>>>> Hunk #2 succeeded at 161 (offset -1 lines). >>>>> Hunk #3 FAILED at 1837. >>>>> Hunk #4 succeeded at 1868 (offset -113 lines). >>>>> Hunk #5 succeeded at 1999 (offset -113 lines). >>>>> Hunk #6 succeeded at 2023 (offset -113 lines). >>>>> 2 out of 6 hunks FAILED -- saving rejects to file drivers/acpi/video.c.rej >>>>> >>>>> >>>>> ==LAST LINES OF BUILD BEFORE FAIL=== >>>>> >>>>> CC [M] fs/xfs/xfs_ioctl32.o >>>>> LD [M] fs/xfs/xfs.o >>>>> make[1]: Leaving directory `/home/lewis/KernelTesting/Kernel/linux' >>>>> make: *** [debian/stamp/build/kernel] Error 2 >>>>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ >>>>> >>>>> >>>> >>> >>> Aaron >>> >>> Many thanks for this. I can confirm that booting with this kernel and >>> passing the video.use_native_backlight = 1 argument means that the >>> backlight works perfectly on my laptop (both using the keyboard hot >>> keys and the gnome/unity settings applet). >>> >>> I'll post to the ubuntu launchpad page later with instructions for >>> other people to do this. I assume its presence in the linux-next tree >>> means that it will be fixed in an upcoming kernel release? (sorry, I >>> don't know quite how the process works). >>> >>> If I can provide more information or do some more useful testing >>> please do not hesitate to let me know. >>> >>> Thank you both for your help - really appreciated. >>> >>> -- >>> Lewis >>> >> >> Aaron >> >> Just one final point in case it is relevant / useful - although it >> fixes the backlight issue this kernel version breaks the suspend >> resume functionality for me (the system will suspend but cannot come >> back from it). > > That sounds like a regression somewhere and a git bisect would be great > if that's possible for you. > > Thanks, > Aaron > >> >> Not asking for a fix (appreciate it is a testing base), just thought >> it might be useful to know. >> >> Thanks again >> >> >
On 05/30/2014 09:12 PM, Lewis Toohey wrote: > Aaron > > I am in the process of performing this bisection, however, I need a > bit of advice. > > I have got a mix of results following suspend right through from (i) > system reboot; (ii) "low graphics mode" error; (iii) restore but > sluggish performance; and (iv) restore but *very* sluggish > performance. Is the sluggish performance experienced with a GUI environment? > > What should qualify as a bad commit? Anything other than a "perfect" restore? I think ii/iii/iv all qualify as bad, if there is no such problem in previous kernels. And yes, a perfect restore is expected, assume the system is able to do a perfect restore with old kernels. Thanks, Aaron > > Many thanks > > On 27 May 2014 02:12, Aaron Lu <aaron.lu@intel.com> wrote: >> On 05/27/2014 03:09 AM, Lewis Toohey wrote: >>> On 26 May 2014 13:18, Lewis Toohey <lewis@toohey.co.uk> wrote: >>>> On 26 May 2014 06:48, Aaron Lu <aaron.lu@intel.com> wrote: >>>>> On 05/26/2014 04:42 AM, Lewis Toohey wrote: >>>>>> On 23 May 2014 13:50, Hans de Goede <hdegoede@redhat.com> wrote: >>>>>>> Hi Lewis et all, >>>>>>> >>>>>>> On 05/23/2014 02:07 PM, Lewis Toohey wrote: >>>>>>>> On 23 May 2014 02:34, Aaron Lu <aaron.lu@intel.com> wrote: >>>>>>>>> On 05/21/2014 09:02 PM, Lewis Toohey wrote: >>>>>>>>>> Hi Aaron >>>>>>>>>> >>>>>>>>>> I followed your instructions and can report some limited success. I >>>>>>>>>> have two interfaces listed in /sys/class/backlight namely: >>>>>>>>>> acpi_video0 radeon_bl0 >>>>>>>>>> >>>>>>>>>> max_brightness for acpi_video0 is 11. Echo-ing new values to >>>>>>>>>> brightness appears to have no effect. >>>>>>>>>> >>>>>>>>>> max_brightness for radeon_bl0 is 255. Echo-ing new values to >>>>>>>>>> brightness does adjust the screen brightness as you would expect. >>>>>>>>>> >>>>>>>>>> Results are the same on both battery and powered. >>>>>>>>>> >>>>>>>>>> I hope that is useful. >>>>>>>>> >>>>>>>>> I think Hans' patchset should solve your problem, can you please give it >>>>>>>>> a try? You will need to pass the video.use_native_backlight=1 to kernel >>>>>>>>> cmdline when testing, thanks. >>>>>>>>> >>>>>>>>> [PATCH resend 0/4] Make video.use_native_backlight=1 work properly with nouveau >>>>>>>>> http://www.spinics.net/lists/dri-devel/msg59941.html >>>>>>>>> >>>>>>>>> -Aaron >>>>>>>> >>>>>>>> Aaron >>>>>>>> >>>>>>>> Thank you for this. Unfortunately I am going to have to ask you for a >>>>>>>> bit of help here as I am now, officially, "out of my depth". I >>>>>>>> appreciate this is a pain as you will have to take time explaining it >>>>>>>> to me and I apologise for that. >>>>>>>> >>>>>>>> I have figured out how to pass the kernel command line argument, this >>>>>>>> is not an issue. >>>>>>>> >>>>>>>> I have located the patch you refer to here: >>>>>>>> https://bugzilla.redhat.com/attachment.cgi?id=894577 >>>>>>>> (which I believe is correct) but I cannot figure out how to apply it. >>>>>>> >>>>>>> That is not the right patch, you need a set of 2 patches. I've attached >>>>>>> them to this mail. Note please ignore the numbering starting at 6, these >>>>>>> are the 2 patches you need. You will need to build a Linux kernel with >>>>>>> these 2 patches applied, see your distributions documentation on how >>>>>>> to build a kernel from source. >>>>>>> >>>>>>> I don't know which distro you are using, I've a Fedora kernel with this >>>>>>> patches included available here: >>>>>>> >>>>>>> http://people.fedoraproject.org/~jwrdegoede/rhbz1093171/ >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Hans >>>>>> >>>>>> Hans >>>>>> >>>>>> Unfortunately I am unable to apply these patches against the latest >>>>>> mainline kernel. I get two fails when applying the second patch file >>>>>> and then the kernel will not compile. Please see output information >>>>>> below. >>>>> >>>>> I've prepared a git branch for you: >>>>> https://github.com/aaronlu/linux.git for-lewis >>>>> >>>>> It's based on Rafael's linux-next plus Hans' patch 2 and 3. >>>>> >>>>> Thanks, >>>>> Aaron >>>>> >>>>>> >>>>>> Can you advise? >>>>>> >>>>>> Many thanks >>>>>> >>>>>> ===APPLYING PATCHES TO LATEST MAINLINE KERNEL==== >>>>>> >>>>>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < >>>>>> 0006-backlight-Add-backlight-device-un-registration-notif.patch >>>>>> (Stripping trailing CRs from patch; use --binary to disable.) >>>>>> patching file drivers/video/backlight/backlight.c >>>>>> (Stripping trailing CRs from patch; use --binary to disable.) >>>>>> patching file include/linux/backlight.h >>>>>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ patch -p1 < >>>>>> 0007-acpi-video-Unregister-the-backlight-device-if-a-raw-.patch >>>>>> (Stripping trailing CRs from patch; use --binary to disable.) >>>>>> patching file drivers/acpi/video.c >>>>>> Hunk #1 FAILED at 151. >>>>>> Hunk #2 succeeded at 161 (offset -1 lines). >>>>>> Hunk #3 FAILED at 1837. >>>>>> Hunk #4 succeeded at 1868 (offset -113 lines). >>>>>> Hunk #5 succeeded at 1999 (offset -113 lines). >>>>>> Hunk #6 succeeded at 2023 (offset -113 lines). >>>>>> 2 out of 6 hunks FAILED -- saving rejects to file drivers/acpi/video.c.rej >>>>>> >>>>>> >>>>>> ==LAST LINES OF BUILD BEFORE FAIL=== >>>>>> >>>>>> CC [M] fs/xfs/xfs_ioctl32.o >>>>>> LD [M] fs/xfs/xfs.o >>>>>> make[1]: Leaving directory `/home/lewis/KernelTesting/Kernel/linux' >>>>>> make: *** [debian/stamp/build/kernel] Error 2 >>>>>> lewis@HappyFunMeaowMeaow:~/KernelTesting/Kernel/linux$ >>>>>> >>>>>> >>>>> >>>> >>>> Aaron >>>> >>>> Many thanks for this. I can confirm that booting with this kernel and >>>> passing the video.use_native_backlight = 1 argument means that the >>>> backlight works perfectly on my laptop (both using the keyboard hot >>>> keys and the gnome/unity settings applet). >>>> >>>> I'll post to the ubuntu launchpad page later with instructions for >>>> other people to do this. I assume its presence in the linux-next tree >>>> means that it will be fixed in an upcoming kernel release? (sorry, I >>>> don't know quite how the process works). >>>> >>>> If I can provide more information or do some more useful testing >>>> please do not hesitate to let me know. >>>> >>>> Thank you both for your help - really appreciated. >>>> >>>> -- >>>> Lewis >>>> >>> >>> Aaron >>> >>> Just one final point in case it is relevant / useful - although it >>> fixes the backlight issue this kernel version breaks the suspend >>> resume functionality for me (the system will suspend but cannot come >>> back from it). >> >> That sounds like a regression somewhere and a git bisect would be great >> if that's possible for you. >> >> Thanks, >> Aaron >> >>> >>> Not asking for a fix (appreciate it is a testing base), just thought >>> it might be useful to know. >>> >>> Thanks again >>> >>> >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 3 June 2014 02:22, Aaron Lu <aaron.lu@intel.com> wrote: > On 05/30/2014 09:12 PM, Lewis Toohey wrote: >> Aaron >> >> I am in the process of performing this bisection, however, I need a >> bit of advice. >> >> I have got a mix of results following suspend right through from (i) >> system reboot; (ii) "low graphics mode" error; (iii) restore but >> sluggish performance; and (iv) restore but *very* sluggish >> performance. > > Is the sluggish performance experienced with a GUI environment? > >> >> What should qualify as a bad commit? Anything other than a "perfect" restore? > > I think ii/iii/iv all qualify as bad, if there is no such problem > in previous kernels. And yes, a perfect restore is expected, assume > the system is able to do a perfect restore with old kernels. > > Thanks, > Aaron > >> >> Many thanks >> Hi Aaron Firstly, yes the sluggish performance I was referring to is experienced in the GUI environment. Jerky graphics and CPU fan appears to max out and stay there. Old kernels (e.g. the Ubuntu default kernel) do not do this and just restore perfectly. I have completed the bisect as requested. Please find the full log below. I am slightly unconvinced, as building the previous commit in the log still seems to have the same problem, however, that commit is a "merge" and I don't really know what this means. Many thanks Bisect Log: git bisect start # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c # bad: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1 git bisect bad c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 # good: [cd6362befe4cc7bf589a5236d2a780af2d47bcc9] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect good cd6362befe4cc7bf589a5236d2a780af2d47bcc9 # good: [d2b150d0647e055d7a71b1c33140280550b27dd6] Merge tag 'sh-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good d2b150d0647e055d7a71b1c33140280550b27dd6 # good: [5fb6b953bb7aa86a9c8ea760934982cedc45c52b] include/linux/syscalls.h: add sys_renameat2() prototype git bisect good 5fb6b953bb7aa86a9c8ea760934982cedc45c52b # bad: [ffddc5fd19b219f557fd4a81168ce8784a4faced] fs/ncpfs/dir.c: fix indenting in ncp_lookup() git bisect bad ffddc5fd19b219f557fd4a81168ce8784a4faced # bad: [978c6050165bba52eab7ef3581d447eb215def77] Merge branch 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next git bisect bad 978c6050165bba52eab7ef3581d447eb215def77 # bad: [262de1453184f65e5ccfe45790f93d41f7339d49] drm/i915: Directly return the vma from bind_to_vm git bisect bad 262de1453184f65e5ccfe45790f93d41f7339d49 # bad: [031994ee8dedfa69d3a7caa43e93f3c282bc38f9] drm/i915: Implement WaIncreaseL3CreditsForVLVB0:vlv git bisect bad 031994ee8dedfa69d3a7caa43e93f3c282bc38f9 # bad: [f72d21eddfa900bfa2674195dcc0203e18d0cc62] drm/i915: Place the Global GTT VM first in the list of VM git bisect bad f72d21eddfa900bfa2674195dcc0203e18d0cc62 # bad: [d6660add648d10e7e35085d8c7d2653e0f9f61b7] drm/i915: Generalize PPGTT init git bisect bad d6660add648d10e7e35085d8c7d2653e0f9f61b7 # bad: [b731d33d05dd5ce6b387cbadb0d9d24cb3732b40] drm/i915: relax context alignment git bisect bad b731d33d05dd5ce6b387cbadb0d9d24cb3732b40 # bad: [a7b910789f77afa40ae0816d22339e9d25723c6e] drm/i915: Add vm to error BO capture git bisect bad a7b910789f77afa40ae0816d22339e9d25723c6e # bad: [6e164c3382314a1f63526fa7a4322a17318d0e32] drm/i915: Allow ggtt lookups to not WARN git bisect bad 6e164c3382314a1f63526fa7a4322a17318d0e32 # bad: [6f425321e02a1b6c5e90b70f8fab7c140fcaeefb] drm/i915: Don't unconditionally try to deref aliasing ppgtt git bisect bad 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb # bad: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide PDP updates via MMIO git bisect bad e178f7057b81c87a7ceaae0ca204487b6f7eedcf # first bad commit: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide PDP updates via MMIO -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
+Ben Widawsky & Daniel Vetter On 06/09/2014 03:38 PM, Lewis Toohey wrote: > On 3 June 2014 02:22, Aaron Lu <aaron.lu@intel.com> wrote: >> On 05/30/2014 09:12 PM, Lewis Toohey wrote: >>> Aaron >>> >>> I am in the process of performing this bisection, however, I need a >>> bit of advice. >>> >>> I have got a mix of results following suspend right through from (i) >>> system reboot; (ii) "low graphics mode" error; (iii) restore but >>> sluggish performance; and (iv) restore but *very* sluggish >>> performance. >> >> Is the sluggish performance experienced with a GUI environment? >> >>> >>> What should qualify as a bad commit? Anything other than a "perfect" restore? >> >> I think ii/iii/iv all qualify as bad, if there is no such problem >> in previous kernels. And yes, a perfect restore is expected, assume >> the system is able to do a perfect restore with old kernels. >> >> Thanks, >> Aaron >> >>> >>> Many thanks >>> > > Hi Aaron > > Firstly, yes the sluggish performance I was referring to is > experienced in the GUI environment. Jerky graphics and CPU fan appears > to max out and stay there. Old kernels (e.g. the Ubuntu default > kernel) do not do this and just restore perfectly. > > I have completed the bisect as requested. Please find the full log > below. I am slightly unconvinced, as building the previous commit in > the log still seems to have the same problem, however, that commit is > a "merge" and I don't really know what this means. > > Many thanks > > Bisect Log: > git bisect start > # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 > git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c > # bad: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1 > git bisect bad c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 > # good: [cd6362befe4cc7bf589a5236d2a780af2d47bcc9] Merge > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next > git bisect good cd6362befe4cc7bf589a5236d2a780af2d47bcc9 > # good: [d2b150d0647e055d7a71b1c33140280550b27dd6] Merge tag 'sh-3.15' > of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc > git bisect good d2b150d0647e055d7a71b1c33140280550b27dd6 > # good: [5fb6b953bb7aa86a9c8ea760934982cedc45c52b] > include/linux/syscalls.h: add sys_renameat2() prototype > git bisect good 5fb6b953bb7aa86a9c8ea760934982cedc45c52b > # bad: [ffddc5fd19b219f557fd4a81168ce8784a4faced] fs/ncpfs/dir.c: fix > indenting in ncp_lookup() > git bisect bad ffddc5fd19b219f557fd4a81168ce8784a4faced > # bad: [978c6050165bba52eab7ef3581d447eb215def77] Merge branch > 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next > git bisect bad 978c6050165bba52eab7ef3581d447eb215def77 > # bad: [262de1453184f65e5ccfe45790f93d41f7339d49] drm/i915: Directly > return the vma from bind_to_vm > git bisect bad 262de1453184f65e5ccfe45790f93d41f7339d49 > # bad: [031994ee8dedfa69d3a7caa43e93f3c282bc38f9] drm/i915: Implement > WaIncreaseL3CreditsForVLVB0:vlv > git bisect bad 031994ee8dedfa69d3a7caa43e93f3c282bc38f9 > # bad: [f72d21eddfa900bfa2674195dcc0203e18d0cc62] drm/i915: Place the > Global GTT VM first in the list of VM > git bisect bad f72d21eddfa900bfa2674195dcc0203e18d0cc62 > # bad: [d6660add648d10e7e35085d8c7d2653e0f9f61b7] drm/i915: Generalize > PPGTT init > git bisect bad d6660add648d10e7e35085d8c7d2653e0f9f61b7 > # bad: [b731d33d05dd5ce6b387cbadb0d9d24cb3732b40] drm/i915: relax > context alignment > git bisect bad b731d33d05dd5ce6b387cbadb0d9d24cb3732b40 > # bad: [a7b910789f77afa40ae0816d22339e9d25723c6e] drm/i915: Add vm to > error BO capture > git bisect bad a7b910789f77afa40ae0816d22339e9d25723c6e > # bad: [6e164c3382314a1f63526fa7a4322a17318d0e32] drm/i915: Allow ggtt > lookups to not WARN > git bisect bad 6e164c3382314a1f63526fa7a4322a17318d0e32 > # bad: [6f425321e02a1b6c5e90b70f8fab7c140fcaeefb] drm/i915: Don't > unconditionally try to deref aliasing ppgtt > git bisect bad 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb > # bad: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide > PDP updates via MMIO > git bisect bad e178f7057b81c87a7ceaae0ca204487b6f7eedcf > # first bad commit: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] > drm/i915: Provide PDP updates via MMIO > The commit looks like related, I've added the commit author. Ben, Do you have any suggestions? Does the above commit have any chance of causing sluggish performance problem after a resume? Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 10, 2014 at 01:33:51PM +0800, Aaron Lu wrote: > +Ben Widawsky & Daniel Vetter > > On 06/09/2014 03:38 PM, Lewis Toohey wrote: > > On 3 June 2014 02:22, Aaron Lu <aaron.lu@intel.com> wrote: > >> On 05/30/2014 09:12 PM, Lewis Toohey wrote: > >>> Aaron > >>> > >>> I am in the process of performing this bisection, however, I need a > >>> bit of advice. > >>> > >>> I have got a mix of results following suspend right through from (i) > >>> system reboot; (ii) "low graphics mode" error; (iii) restore but > >>> sluggish performance; and (iv) restore but *very* sluggish > >>> performance. > >> > >> Is the sluggish performance experienced with a GUI environment? > >> > >>> > >>> What should qualify as a bad commit? Anything other than a "perfect" restore? > >> > >> I think ii/iii/iv all qualify as bad, if there is no such problem > >> in previous kernels. And yes, a perfect restore is expected, assume > >> the system is able to do a perfect restore with old kernels. > >> > >> Thanks, > >> Aaron > >> > >>> > >>> Many thanks > >>> > > > > Hi Aaron > > > > Firstly, yes the sluggish performance I was referring to is > > experienced in the GUI environment. Jerky graphics and CPU fan appears > > to max out and stay there. Old kernels (e.g. the Ubuntu default > > kernel) do not do this and just restore perfectly. > > > > I have completed the bisect as requested. Please find the full log > > below. I am slightly unconvinced, as building the previous commit in > > the log still seems to have the same problem, however, that commit is > > a "merge" and I don't really know what this means. > > > > Many thanks > > > > Bisect Log: > > git bisect start > > # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 > > git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c > > # bad: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1 > > git bisect bad c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 > > # good: [cd6362befe4cc7bf589a5236d2a780af2d47bcc9] Merge > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next > > git bisect good cd6362befe4cc7bf589a5236d2a780af2d47bcc9 > > # good: [d2b150d0647e055d7a71b1c33140280550b27dd6] Merge tag 'sh-3.15' > > of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc > > git bisect good d2b150d0647e055d7a71b1c33140280550b27dd6 > > # good: [5fb6b953bb7aa86a9c8ea760934982cedc45c52b] > > include/linux/syscalls.h: add sys_renameat2() prototype > > git bisect good 5fb6b953bb7aa86a9c8ea760934982cedc45c52b > > # bad: [ffddc5fd19b219f557fd4a81168ce8784a4faced] fs/ncpfs/dir.c: fix > > indenting in ncp_lookup() > > git bisect bad ffddc5fd19b219f557fd4a81168ce8784a4faced > > # bad: [978c6050165bba52eab7ef3581d447eb215def77] Merge branch > > 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next > > git bisect bad 978c6050165bba52eab7ef3581d447eb215def77 > > # bad: [262de1453184f65e5ccfe45790f93d41f7339d49] drm/i915: Directly > > return the vma from bind_to_vm > > git bisect bad 262de1453184f65e5ccfe45790f93d41f7339d49 > > # bad: [031994ee8dedfa69d3a7caa43e93f3c282bc38f9] drm/i915: Implement > > WaIncreaseL3CreditsForVLVB0:vlv > > git bisect bad 031994ee8dedfa69d3a7caa43e93f3c282bc38f9 > > # bad: [f72d21eddfa900bfa2674195dcc0203e18d0cc62] drm/i915: Place the > > Global GTT VM first in the list of VM > > git bisect bad f72d21eddfa900bfa2674195dcc0203e18d0cc62 > > # bad: [d6660add648d10e7e35085d8c7d2653e0f9f61b7] drm/i915: Generalize > > PPGTT init > > git bisect bad d6660add648d10e7e35085d8c7d2653e0f9f61b7 > > # bad: [b731d33d05dd5ce6b387cbadb0d9d24cb3732b40] drm/i915: relax > > context alignment > > git bisect bad b731d33d05dd5ce6b387cbadb0d9d24cb3732b40 > > # bad: [a7b910789f77afa40ae0816d22339e9d25723c6e] drm/i915: Add vm to > > error BO capture > > git bisect bad a7b910789f77afa40ae0816d22339e9d25723c6e > > # bad: [6e164c3382314a1f63526fa7a4322a17318d0e32] drm/i915: Allow ggtt > > lookups to not WARN > > git bisect bad 6e164c3382314a1f63526fa7a4322a17318d0e32 > > # bad: [6f425321e02a1b6c5e90b70f8fab7c140fcaeefb] drm/i915: Don't > > unconditionally try to deref aliasing ppgtt > > git bisect bad 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb > > # bad: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide > > PDP updates via MMIO > > git bisect bad e178f7057b81c87a7ceaae0ca204487b6f7eedcf > > # first bad commit: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] > > drm/i915: Provide PDP updates via MMIO > > > > The commit looks like related, I've added the commit author. > > Ben, > Do you have any suggestions? Does the above commit have any chance of > causing sluggish performance problem after a resume? > > Thanks, > Aaron What this comment actually does is use MMIO writes for the page tables after a GPU hang/reset. (What a poorly named commit message). Can you please provide the full dmesg with the drm.debug=0x2?
On 10 June 2014 17:58, Ben Widawsky <ben@bwidawsk.net> wrote: > On Tue, Jun 10, 2014 at 01:33:51PM +0800, Aaron Lu wrote: >> +Ben Widawsky & Daniel Vetter >> >> On 06/09/2014 03:38 PM, Lewis Toohey wrote: >> > On 3 June 2014 02:22, Aaron Lu <aaron.lu@intel.com> wrote: >> >> On 05/30/2014 09:12 PM, Lewis Toohey wrote: >> >>> Aaron >> >>> >> >>> I am in the process of performing this bisection, however, I need a >> >>> bit of advice. >> >>> >> >>> I have got a mix of results following suspend right through from (i) >> >>> system reboot; (ii) "low graphics mode" error; (iii) restore but >> >>> sluggish performance; and (iv) restore but *very* sluggish >> >>> performance. >> >> >> >> Is the sluggish performance experienced with a GUI environment? >> >> >> >>> >> >>> What should qualify as a bad commit? Anything other than a "perfect" restore? >> >> >> >> I think ii/iii/iv all qualify as bad, if there is no such problem >> >> in previous kernels. And yes, a perfect restore is expected, assume >> >> the system is able to do a perfect restore with old kernels. >> >> >> >> Thanks, >> >> Aaron >> >> >> >>> >> >>> Many thanks >> >>> >> > >> > Hi Aaron >> > >> > Firstly, yes the sluggish performance I was referring to is >> > experienced in the GUI environment. Jerky graphics and CPU fan appears >> > to max out and stay there. Old kernels (e.g. the Ubuntu default >> > kernel) do not do this and just restore perfectly. >> > >> > I have completed the bisect as requested. Please find the full log >> > below. I am slightly unconvinced, as building the previous commit in >> > the log still seems to have the same problem, however, that commit is >> > a "merge" and I don't really know what this means. >> > >> > Many thanks >> > >> > Bisect Log: >> > git bisect start >> > # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 >> > git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c >> > # bad: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1 >> > git bisect bad c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 >> > # good: [cd6362befe4cc7bf589a5236d2a780af2d47bcc9] Merge >> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next >> > git bisect good cd6362befe4cc7bf589a5236d2a780af2d47bcc9 >> > # good: [d2b150d0647e055d7a71b1c33140280550b27dd6] Merge tag 'sh-3.15' >> > of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc >> > git bisect good d2b150d0647e055d7a71b1c33140280550b27dd6 >> > # good: [5fb6b953bb7aa86a9c8ea760934982cedc45c52b] >> > include/linux/syscalls.h: add sys_renameat2() prototype >> > git bisect good 5fb6b953bb7aa86a9c8ea760934982cedc45c52b >> > # bad: [ffddc5fd19b219f557fd4a81168ce8784a4faced] fs/ncpfs/dir.c: fix >> > indenting in ncp_lookup() >> > git bisect bad ffddc5fd19b219f557fd4a81168ce8784a4faced >> > # bad: [978c6050165bba52eab7ef3581d447eb215def77] Merge branch >> > 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next >> > git bisect bad 978c6050165bba52eab7ef3581d447eb215def77 >> > # bad: [262de1453184f65e5ccfe45790f93d41f7339d49] drm/i915: Directly >> > return the vma from bind_to_vm >> > git bisect bad 262de1453184f65e5ccfe45790f93d41f7339d49 >> > # bad: [031994ee8dedfa69d3a7caa43e93f3c282bc38f9] drm/i915: Implement >> > WaIncreaseL3CreditsForVLVB0:vlv >> > git bisect bad 031994ee8dedfa69d3a7caa43e93f3c282bc38f9 >> > # bad: [f72d21eddfa900bfa2674195dcc0203e18d0cc62] drm/i915: Place the >> > Global GTT VM first in the list of VM >> > git bisect bad f72d21eddfa900bfa2674195dcc0203e18d0cc62 >> > # bad: [d6660add648d10e7e35085d8c7d2653e0f9f61b7] drm/i915: Generalize >> > PPGTT init >> > git bisect bad d6660add648d10e7e35085d8c7d2653e0f9f61b7 >> > # bad: [b731d33d05dd5ce6b387cbadb0d9d24cb3732b40] drm/i915: relax >> > context alignment >> > git bisect bad b731d33d05dd5ce6b387cbadb0d9d24cb3732b40 >> > # bad: [a7b910789f77afa40ae0816d22339e9d25723c6e] drm/i915: Add vm to >> > error BO capture >> > git bisect bad a7b910789f77afa40ae0816d22339e9d25723c6e >> > # bad: [6e164c3382314a1f63526fa7a4322a17318d0e32] drm/i915: Allow ggtt >> > lookups to not WARN >> > git bisect bad 6e164c3382314a1f63526fa7a4322a17318d0e32 >> > # bad: [6f425321e02a1b6c5e90b70f8fab7c140fcaeefb] drm/i915: Don't >> > unconditionally try to deref aliasing ppgtt >> > git bisect bad 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb >> > # bad: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide >> > PDP updates via MMIO >> > git bisect bad e178f7057b81c87a7ceaae0ca204487b6f7eedcf >> > # first bad commit: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] >> > drm/i915: Provide PDP updates via MMIO >> > >> >> The commit looks like related, I've added the commit author. >> >> Ben, >> Do you have any suggestions? Does the above commit have any chance of >> causing sluggish performance problem after a resume? >> >> Thanks, >> Aaron > > What this comment actually does is use MMIO writes for the page tables > after a GPU hang/reset. (What a poorly named commit message). > > Can you please provide the full dmesg with the drm.debug=0x2? > Hi Ben Thank you for responding. Just to verify that I have done this correctly, I added "drm.debug=0x2" to the kernel command line (in Grub), booted, suspended and resumed, and then ran Dmesg. I wasn't sure exactly where to put it, so please find a copy of the output here: http://www.toohey.co.uk/dmesg I hope that is helpful. If you need any further information please let me know. Many thanks
On Tue, Jun 10, 2014 at 08:59:32PM +0100, Lewis Toohey wrote: > On 10 June 2014 17:58, Ben Widawsky <ben@bwidawsk.net> wrote: > > On Tue, Jun 10, 2014 at 01:33:51PM +0800, Aaron Lu wrote: > >> +Ben Widawsky & Daniel Vetter > >> > >> On 06/09/2014 03:38 PM, Lewis Toohey wrote: > >> > On 3 June 2014 02:22, Aaron Lu <aaron.lu@intel.com> wrote: > >> >> On 05/30/2014 09:12 PM, Lewis Toohey wrote: > >> >>> Aaron > >> >>> > >> >>> I am in the process of performing this bisection, however, I need a > >> >>> bit of advice. > >> >>> > >> >>> I have got a mix of results following suspend right through from (i) > >> >>> system reboot; (ii) "low graphics mode" error; (iii) restore but > >> >>> sluggish performance; and (iv) restore but *very* sluggish > >> >>> performance. > >> >> > >> >> Is the sluggish performance experienced with a GUI environment? > >> >> > >> >>> > >> >>> What should qualify as a bad commit? Anything other than a "perfect" restore? > >> >> > >> >> I think ii/iii/iv all qualify as bad, if there is no such problem > >> >> in previous kernels. And yes, a perfect restore is expected, assume > >> >> the system is able to do a perfect restore with old kernels. > >> >> > >> >> Thanks, > >> >> Aaron > >> >> > >> >>> > >> >>> Many thanks > >> >>> > >> > > >> > Hi Aaron > >> > > >> > Firstly, yes the sluggish performance I was referring to is > >> > experienced in the GUI environment. Jerky graphics and CPU fan appears > >> > to max out and stay there. Old kernels (e.g. the Ubuntu default > >> > kernel) do not do this and just restore perfectly. > >> > > >> > I have completed the bisect as requested. Please find the full log > >> > below. I am slightly unconvinced, as building the previous commit in > >> > the log still seems to have the same problem, however, that commit is > >> > a "merge" and I don't really know what this means. > >> > > >> > Many thanks > >> > > >> > Bisect Log: > >> > git bisect start > >> > # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 > >> > git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c > >> > # bad: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1 > >> > git bisect bad c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 > >> > # good: [cd6362befe4cc7bf589a5236d2a780af2d47bcc9] Merge > >> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next > >> > git bisect good cd6362befe4cc7bf589a5236d2a780af2d47bcc9 > >> > # good: [d2b150d0647e055d7a71b1c33140280550b27dd6] Merge tag 'sh-3.15' > >> > of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc > >> > git bisect good d2b150d0647e055d7a71b1c33140280550b27dd6 > >> > # good: [5fb6b953bb7aa86a9c8ea760934982cedc45c52b] > >> > include/linux/syscalls.h: add sys_renameat2() prototype > >> > git bisect good 5fb6b953bb7aa86a9c8ea760934982cedc45c52b > >> > # bad: [ffddc5fd19b219f557fd4a81168ce8784a4faced] fs/ncpfs/dir.c: fix > >> > indenting in ncp_lookup() > >> > git bisect bad ffddc5fd19b219f557fd4a81168ce8784a4faced > >> > # bad: [978c6050165bba52eab7ef3581d447eb215def77] Merge branch > >> > 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next > >> > git bisect bad 978c6050165bba52eab7ef3581d447eb215def77 > >> > # bad: [262de1453184f65e5ccfe45790f93d41f7339d49] drm/i915: Directly > >> > return the vma from bind_to_vm > >> > git bisect bad 262de1453184f65e5ccfe45790f93d41f7339d49 > >> > # bad: [031994ee8dedfa69d3a7caa43e93f3c282bc38f9] drm/i915: Implement > >> > WaIncreaseL3CreditsForVLVB0:vlv > >> > git bisect bad 031994ee8dedfa69d3a7caa43e93f3c282bc38f9 > >> > # bad: [f72d21eddfa900bfa2674195dcc0203e18d0cc62] drm/i915: Place the > >> > Global GTT VM first in the list of VM > >> > git bisect bad f72d21eddfa900bfa2674195dcc0203e18d0cc62 > >> > # bad: [d6660add648d10e7e35085d8c7d2653e0f9f61b7] drm/i915: Generalize > >> > PPGTT init > >> > git bisect bad d6660add648d10e7e35085d8c7d2653e0f9f61b7 > >> > # bad: [b731d33d05dd5ce6b387cbadb0d9d24cb3732b40] drm/i915: relax > >> > context alignment > >> > git bisect bad b731d33d05dd5ce6b387cbadb0d9d24cb3732b40 > >> > # bad: [a7b910789f77afa40ae0816d22339e9d25723c6e] drm/i915: Add vm to > >> > error BO capture > >> > git bisect bad a7b910789f77afa40ae0816d22339e9d25723c6e > >> > # bad: [6e164c3382314a1f63526fa7a4322a17318d0e32] drm/i915: Allow ggtt > >> > lookups to not WARN > >> > git bisect bad 6e164c3382314a1f63526fa7a4322a17318d0e32 > >> > # bad: [6f425321e02a1b6c5e90b70f8fab7c140fcaeefb] drm/i915: Don't > >> > unconditionally try to deref aliasing ppgtt > >> > git bisect bad 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb > >> > # bad: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide > >> > PDP updates via MMIO > >> > git bisect bad e178f7057b81c87a7ceaae0ca204487b6f7eedcf > >> > # first bad commit: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] > >> > drm/i915: Provide PDP updates via MMIO > >> > > >> > >> The commit looks like related, I've added the commit author. > >> > >> Ben, > >> Do you have any suggestions? Does the above commit have any chance of > >> causing sluggish performance problem after a resume? > >> > >> Thanks, > >> Aaron > > > > What this comment actually does is use MMIO writes for the page tables > > after a GPU hang/reset. (What a poorly named commit message). > > > > Can you please provide the full dmesg with the drm.debug=0x2? > > > > Hi Ben > > Thank you for responding. > > Just to verify that I have done this correctly, I added > "drm.debug=0x2" to the kernel command line (in Grub), booted, > suspended and resumed, and then ran Dmesg. > > I wasn't sure exactly where to put it, so please find a copy of the output here: > http://www.toohey.co.uk/dmesg > > I hope that is helpful. If you need any further information please let me know. > > Many thanks > > > I only see radeon stuff in that dmesg. But you did the right thing to grub.
On 06/11/2014 06:54 AM, Ben Widawsky wrote: > On Tue, Jun 10, 2014 at 08:59:32PM +0100, Lewis Toohey wrote: >> On 10 June 2014 17:58, Ben Widawsky <ben@bwidawsk.net> wrote: >>> On Tue, Jun 10, 2014 at 01:33:51PM +0800, Aaron Lu wrote: >>>> +Ben Widawsky & Daniel Vetter >>>> >>>> On 06/09/2014 03:38 PM, Lewis Toohey wrote: >>>>> >>>>> Hi Aaron >>>>> >>>>> Firstly, yes the sluggish performance I was referring to is >>>>> experienced in the GUI environment. Jerky graphics and CPU fan appears >>>>> to max out and stay there. Old kernels (e.g. the Ubuntu default >>>>> kernel) do not do this and just restore perfectly. >>>>> >>>>> I have completed the bisect as requested. Please find the full log >>>>> below. I am slightly unconvinced, as building the previous commit in >>>>> the log still seems to have the same problem, however, that commit is >>>>> a "merge" and I don't really know what this means. >>>>> >>>>> Many thanks >>>>> >>>>> Bisect Log: >>>>> git bisect start >>>>> # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 >>>>> git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c >>>>> # bad: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1 >>>>> git bisect bad c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 >>>>> # good: [cd6362befe4cc7bf589a5236d2a780af2d47bcc9] Merge >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next >>>>> git bisect good cd6362befe4cc7bf589a5236d2a780af2d47bcc9 >>>>> # good: [d2b150d0647e055d7a71b1c33140280550b27dd6] Merge tag 'sh-3.15' >>>>> of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc >>>>> git bisect good d2b150d0647e055d7a71b1c33140280550b27dd6 >>>>> # good: [5fb6b953bb7aa86a9c8ea760934982cedc45c52b] >>>>> include/linux/syscalls.h: add sys_renameat2() prototype >>>>> git bisect good 5fb6b953bb7aa86a9c8ea760934982cedc45c52b >>>>> # bad: [ffddc5fd19b219f557fd4a81168ce8784a4faced] fs/ncpfs/dir.c: fix >>>>> indenting in ncp_lookup() >>>>> git bisect bad ffddc5fd19b219f557fd4a81168ce8784a4faced >>>>> # bad: [978c6050165bba52eab7ef3581d447eb215def77] Merge branch >>>>> 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next >>>>> git bisect bad 978c6050165bba52eab7ef3581d447eb215def77 >>>>> # bad: [262de1453184f65e5ccfe45790f93d41f7339d49] drm/i915: Directly >>>>> return the vma from bind_to_vm >>>>> git bisect bad 262de1453184f65e5ccfe45790f93d41f7339d49 >>>>> # bad: [031994ee8dedfa69d3a7caa43e93f3c282bc38f9] drm/i915: Implement >>>>> WaIncreaseL3CreditsForVLVB0:vlv >>>>> git bisect bad 031994ee8dedfa69d3a7caa43e93f3c282bc38f9 >>>>> # bad: [f72d21eddfa900bfa2674195dcc0203e18d0cc62] drm/i915: Place the >>>>> Global GTT VM first in the list of VM >>>>> git bisect bad f72d21eddfa900bfa2674195dcc0203e18d0cc62 >>>>> # bad: [d6660add648d10e7e35085d8c7d2653e0f9f61b7] drm/i915: Generalize >>>>> PPGTT init >>>>> git bisect bad d6660add648d10e7e35085d8c7d2653e0f9f61b7 >>>>> # bad: [b731d33d05dd5ce6b387cbadb0d9d24cb3732b40] drm/i915: relax >>>>> context alignment >>>>> git bisect bad b731d33d05dd5ce6b387cbadb0d9d24cb3732b40 >>>>> # bad: [a7b910789f77afa40ae0816d22339e9d25723c6e] drm/i915: Add vm to >>>>> error BO capture >>>>> git bisect bad a7b910789f77afa40ae0816d22339e9d25723c6e >>>>> # bad: [6e164c3382314a1f63526fa7a4322a17318d0e32] drm/i915: Allow ggtt >>>>> lookups to not WARN >>>>> git bisect bad 6e164c3382314a1f63526fa7a4322a17318d0e32 >>>>> # bad: [6f425321e02a1b6c5e90b70f8fab7c140fcaeefb] drm/i915: Don't >>>>> unconditionally try to deref aliasing ppgtt >>>>> git bisect bad 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb >>>>> # bad: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide >>>>> PDP updates via MMIO >>>>> git bisect bad e178f7057b81c87a7ceaae0ca204487b6f7eedcf >>>>> # first bad commit: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] >>>>> drm/i915: Provide PDP updates via MMIO >>>>> >>>> >>>> The commit looks like related, I've added the commit author. >>>> >>>> Ben, >>>> Do you have any suggestions? Does the above commit have any chance of >>>> causing sluggish performance problem after a resume? >>> >>> What this comment actually does is use MMIO writes for the page tables >>> after a GPU hang/reset. (What a poorly named commit message). >>> >>> Can you please provide the full dmesg with the drm.debug=0x2? >>> >> >> Hi Ben >> >> Thank you for responding. >> >> Just to verify that I have done this correctly, I added >> "drm.debug=0x2" to the kernel command line (in Grub), booted, >> suspended and resumed, and then ran Dmesg. >> >> I wasn't sure exactly where to put it, so please find a copy of the output here: >> http://www.toohey.co.uk/dmesg >> >> I hope that is helpful. If you need any further information please let me know. >> >> Many thanks > > I only see radeon stuff in that dmesg. But you did the right thing to > grub. Oh yes, this is a AMD graphics card so the bisected commit can't be the culprit. No ideas now, Lewis, I'm afraid you will need try harder to find the bad commit. Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11 June 2014 08:03, Aaron Lu <aaron.lu@intel.com> wrote: > On 06/11/2014 06:54 AM, Ben Widawsky wrote: >> On Tue, Jun 10, 2014 at 08:59:32PM +0100, Lewis Toohey wrote: >>> On 10 June 2014 17:58, Ben Widawsky <ben@bwidawsk.net> wrote: >>>> On Tue, Jun 10, 2014 at 01:33:51PM +0800, Aaron Lu wrote: >>>>> +Ben Widawsky & Daniel Vetter >>>>> >>>>> On 06/09/2014 03:38 PM, Lewis Toohey wrote: >>>>>> >>>>>> Hi Aaron >>>>>> >>>>>> Firstly, yes the sluggish performance I was referring to is >>>>>> experienced in the GUI environment. Jerky graphics and CPU fan appears >>>>>> to max out and stay there. Old kernels (e.g. the Ubuntu default >>>>>> kernel) do not do this and just restore perfectly. >>>>>> >>>>>> I have completed the bisect as requested. Please find the full log >>>>>> below. I am slightly unconvinced, as building the previous commit in >>>>>> the log still seems to have the same problem, however, that commit is >>>>>> a "merge" and I don't really know what this means. >>>>>> >>>>>> Many thanks >>>>>> >>>>>> Bisect Log: >>>>>> git bisect start >>>>>> # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 >>>>>> git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c >>>>>> # bad: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1 >>>>>> git bisect bad c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 >>>>>> # good: [cd6362befe4cc7bf589a5236d2a780af2d47bcc9] Merge >>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next >>>>>> git bisect good cd6362befe4cc7bf589a5236d2a780af2d47bcc9 >>>>>> # good: [d2b150d0647e055d7a71b1c33140280550b27dd6] Merge tag 'sh-3.15' >>>>>> of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc >>>>>> git bisect good d2b150d0647e055d7a71b1c33140280550b27dd6 >>>>>> # good: [5fb6b953bb7aa86a9c8ea760934982cedc45c52b] >>>>>> include/linux/syscalls.h: add sys_renameat2() prototype >>>>>> git bisect good 5fb6b953bb7aa86a9c8ea760934982cedc45c52b >>>>>> # bad: [ffddc5fd19b219f557fd4a81168ce8784a4faced] fs/ncpfs/dir.c: fix >>>>>> indenting in ncp_lookup() >>>>>> git bisect bad ffddc5fd19b219f557fd4a81168ce8784a4faced >>>>>> # bad: [978c6050165bba52eab7ef3581d447eb215def77] Merge branch >>>>>> 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next >>>>>> git bisect bad 978c6050165bba52eab7ef3581d447eb215def77 >>>>>> # bad: [262de1453184f65e5ccfe45790f93d41f7339d49] drm/i915: Directly >>>>>> return the vma from bind_to_vm >>>>>> git bisect bad 262de1453184f65e5ccfe45790f93d41f7339d49 >>>>>> # bad: [031994ee8dedfa69d3a7caa43e93f3c282bc38f9] drm/i915: Implement >>>>>> WaIncreaseL3CreditsForVLVB0:vlv >>>>>> git bisect bad 031994ee8dedfa69d3a7caa43e93f3c282bc38f9 >>>>>> # bad: [f72d21eddfa900bfa2674195dcc0203e18d0cc62] drm/i915: Place the >>>>>> Global GTT VM first in the list of VM >>>>>> git bisect bad f72d21eddfa900bfa2674195dcc0203e18d0cc62 >>>>>> # bad: [d6660add648d10e7e35085d8c7d2653e0f9f61b7] drm/i915: Generalize >>>>>> PPGTT init >>>>>> git bisect bad d6660add648d10e7e35085d8c7d2653e0f9f61b7 >>>>>> # bad: [b731d33d05dd5ce6b387cbadb0d9d24cb3732b40] drm/i915: relax >>>>>> context alignment >>>>>> git bisect bad b731d33d05dd5ce6b387cbadb0d9d24cb3732b40 >>>>>> # bad: [a7b910789f77afa40ae0816d22339e9d25723c6e] drm/i915: Add vm to >>>>>> error BO capture >>>>>> git bisect bad a7b910789f77afa40ae0816d22339e9d25723c6e >>>>>> # bad: [6e164c3382314a1f63526fa7a4322a17318d0e32] drm/i915: Allow ggtt >>>>>> lookups to not WARN >>>>>> git bisect bad 6e164c3382314a1f63526fa7a4322a17318d0e32 >>>>>> # bad: [6f425321e02a1b6c5e90b70f8fab7c140fcaeefb] drm/i915: Don't >>>>>> unconditionally try to deref aliasing ppgtt >>>>>> git bisect bad 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb >>>>>> # bad: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide >>>>>> PDP updates via MMIO >>>>>> git bisect bad e178f7057b81c87a7ceaae0ca204487b6f7eedcf >>>>>> # first bad commit: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] >>>>>> drm/i915: Provide PDP updates via MMIO >>>>>> >>>>> >>>>> The commit looks like related, I've added the commit author. >>>>> >>>>> Ben, >>>>> Do you have any suggestions? Does the above commit have any chance of >>>>> causing sluggish performance problem after a resume? >>>> >>>> What this comment actually does is use MMIO writes for the page tables >>>> after a GPU hang/reset. (What a poorly named commit message). >>>> >>>> Can you please provide the full dmesg with the drm.debug=0x2? >>>> >>> >>> Hi Ben >>> >>> Thank you for responding. >>> >>> Just to verify that I have done this correctly, I added >>> "drm.debug=0x2" to the kernel command line (in Grub), booted, >>> suspended and resumed, and then ran Dmesg. >>> >>> I wasn't sure exactly where to put it, so please find a copy of the output here: >>> http://www.toohey.co.uk/dmesg >>> >>> I hope that is helpful. If you need any further information please let me know. >>> >>> Many thanks >> >> I only see radeon stuff in that dmesg. But you did the right thing to >> grub. > > Oh yes, this is a AMD graphics card so the bisected commit can't > be the culprit. > > No ideas now, Lewis, I'm afraid you will need try harder to find the bad > commit. > > Thanks, > Aaron OK, thank you both. I have a definite good point (v3.14) and a definite bad point (v3.15-rc1), so I just need to figure out why my bisection didn't yield the correct result... let me do some more experimentation and come back you. Many thanks
From b865e1e6ef6e0abcc5b4084d854418ebf7cd7772 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede@redhat.com> Date: Thu, 15 May 2014 15:50:20 +0200 Subject: [PATCH 7/8] acpi-video: Unregister the backlight device if a raw one shows up later When video.use_native_backlight=1 and non intel gfx are in use, the raw backlight device of the gfx driver will show up after acpi-video has done its acpi_video_verify_backlight_support() check. This causes video.use_native_backlight=1 to not have the desired result. This patch fixes this by adding a backlight notifier and when a raw backlight is registered or unregistered re-doing the acpi_video_verify_backlight_support() check. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/acpi/video.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index aee85c4..123f919 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -151,6 +151,7 @@ struct acpi_video_enumerated_device { struct acpi_video_bus { struct acpi_device *device; bool backlight_registered; + bool backlight_notifier_registered; u8 dos_setting; struct acpi_video_enumerated_device *attached_array; u8 attached_count; @@ -162,6 +163,7 @@ struct acpi_video_bus { struct input_dev *input; char phys[32]; /* for input device */ struct notifier_block pm_nb; + struct notifier_block backlight_nb; }; struct acpi_video_device_flags { @@ -1836,6 +1838,9 @@ static int acpi_video_bus_register_backlight(struct acpi_video_bus *video) { struct acpi_video_device *dev; + if (video->backlight_registered) + return 0; + if (!acpi_video_verify_backlight_support()) return 0; @@ -1980,6 +1985,56 @@ static void acpi_video_bus_remove_notify_handler(struct acpi_video_bus *video) video->input = NULL; } +static int acpi_video_backlight_notify(struct notifier_block *nb, + unsigned long val, void *bd) +{ + struct backlight_device *backlight = bd; + struct acpi_video_bus *video; + + /* acpi_video_verify_backlight_support only cares about raw devices */ + if (backlight->props.type != BACKLIGHT_RAW) + return NOTIFY_DONE; + + video = container_of(nb, struct acpi_video_bus, backlight_nb); + + switch (val) { + case BACKLIGHT_REGISTERED: + if (!acpi_video_verify_backlight_support()) + acpi_video_bus_unregister_backlight(video); + break; + case BACKLIGHT_UNREGISTERED: + acpi_video_bus_register_backlight(video); + break; + } + + return NOTIFY_OK; +} + +static int acpi_video_bus_add_backlight_notify_handler( + struct acpi_video_bus *video) +{ + int error; + + video->backlight_nb.notifier_call = acpi_video_backlight_notify; + video->backlight_nb.priority = 0; + error = backlight_register_notifier(&video->backlight_nb); + if (error == 0) + video->backlight_notifier_registered = true; + + return error; +} + +static int acpi_video_bus_remove_backlight_notify_handler( + struct acpi_video_bus *video) +{ + if (!video->backlight_notifier_registered) + return 0; + + video->backlight_notifier_registered = false; + + return backlight_unregister_notifier(&video->backlight_nb); +} + static int acpi_video_bus_put_devices(struct acpi_video_bus *video) { struct acpi_video_device *dev, *next; @@ -2061,6 +2116,7 @@ static int acpi_video_bus_add(struct acpi_device *device) acpi_video_bus_register_backlight(video); acpi_video_bus_add_notify_handler(video); + acpi_video_bus_add_backlight_notify_handler(video); return 0; @@ -2084,6 +2140,7 @@ static int acpi_video_bus_remove(struct acpi_device *device) video = acpi_driver_data(device); + acpi_video_bus_remove_backlight_notify_handler(video); acpi_video_bus_remove_notify_handler(video); acpi_video_bus_unregister_backlight(video); acpi_video_bus_put_devices(video); -- 1.9.0