Bug 22542
| Summary: | [2.6.37-rc1] drm:i195 errors | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Maciej Rutecki (maciej.rutecki) |
| Component: | Video(DRI - Intel) | Assignee: | drivers_video-dri-intel (drivers_video-dri-intel) |
| Status: | CLOSED WILL_NOT_FIX | ||
| Severity: | normal | CC: | brian, bug-track, chris, combuster, eduardo, florian, lucas.de.marchi, maciej.rutecki, rjw, rol, simon.strandman, tshepang, vonbrand, zdenek.kabelac |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.37-rc1 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 21782 | ||
|
Description
Maciej Rutecki
2010-11-09 20:26:19 UTC
[ 31.878256] [drm:intel_panel_get_max_backlight] *ERROR* fixme: max PWM is zero. [ 31.967182] [drm:intel_panel_get_max_backlight] *ERROR* fixme: max PWM is zero. [ 37.217174] [drm:intel_panel_get_max_backlight] *ERROR* fixme: max PWM is zero. I see this still on 2.6.37-rc2... GM965 here. I'm having exactly the same issue with intel GM45. This message comes from drivers/gpu/drm/i915/intel_panel.c and it was introduced in a95735569312f2ab0c80425e2cd1e5cb0b4e1870. A bit weird, there's a comment there: /* XXX add code here to query mode clock or hardware clock * and program max PWM appropriately. */ Is this supposed to be done in 2.6.37? CCing Chris Wilson, author of that patch. Since it hadn't been done in the decade before, I added the fixme just so that I could see if it needed to be done at all. <Insert usual BIOS rant> same here: intel_stepping Vendor: 0x8086, Device: 0x3582, Revision: 0x02 (??) HW: IBM thinkpad R50e Are there any bad side effects? (I.e.: what is the way forward? Is it urgent?) No side effects AFAIK. I don't know if this is related, but after this I started to see some glitches when scrolling a gnome-terminal, with no change in user space. Can you verify that reverting that patch on top of a current kernel cures thoses glitches? The glitches are unrelated to the backlight, but are likely to be bug 23382 instead. *** This bug has been marked as a duplicate of bug 23382 *** Rafael, why did you close this bug? The glitches were fixed in bug 23382 that indeed I thought were related to this one but they were not as pointed out by Chris. OK, so this is not a duplicate, sorry. Are there any _functional_ problems (other than the glitches fixed in bug #23382) related to the new messages in the log? For the backlight you actually want to check: commit c5027dec02c96964847fa68d512318ee5f6f7a19 Author: Keith Packard <keithp@keithp.com> Date: Fri Nov 26 10:45:59 2010 -0800 drm: record monitor status in output_poll_execute In order to correctly report monitor connected status changes, the previous monitor status must be recorded in the connector->status value instead of being discarded. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com> commit bf9dc102e284a5aa78c73fc9d72e11d5ccd8669f Author: Keith Packard <keithp@keithp.com> Date: Fri Nov 26 10:45:58 2010 -0800 drm: Set connector DPMS status to ON in drm_crtc_helper_set_config When setting a new crtc configuration, force the DPMS state of all connectors to ON. Otherwise, they'll be left at OFF and a future mode set that disables the specified connector will not turn the connector off. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com> On Friday, December 03, 2010, Paul Rolland wrote:
> Hello,
>
> On Fri, 19 Nov 2010 00:42:44 +0100 (CET)
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> > This message has been generated automatically as a part of a summary
> > report of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.36. Please verify if it still should be listed and let the
> > tracking team know (either way).
>
> Still present in 2.6.27-rc4 :
>
> Dec 3 21:31:32 tux kernel: [drm:intel_panel_get_max_backlight] *ERROR*
> fixme: max PWM is zero.
> Dec 3 21:31:32 tux kernel: [drm:intel_panel_get_max_backlight] *ERROR*
> fixme: max PWM is zero.
> Dec 3 21:41:32 tux kernel: [drm:intel_panel_get_max_backlight] *ERROR*
> fixme: max PWM is zero.
> Dec 3 21:41:32 tux kernel: [drm:intel_panel_get_max_backlight] *ERROR*
> fixme: max PWM is zero.
> Dec 3 22:41:18 tux kernel: [drm:intel_panel_get_max_backlight] *ERROR*
> fixme: max PWM is zero.
This is still happening with 2.6.37 rc6. [drm:intel_panel_get_max_backlight] *ERROR* fixme: max PWM is zero. I tried to disable backlight but got: root@anjo:/usr/src/linux-2.6.37-rc6# make scripts/kconfig/conf --silentoldconfig Kconfig warning: (STUB_POULSBO && HAS_IOMEM && PCI && ACPI || FB_BACKLIGHT && HAS_IOMEM && FB || DRM_I915 && <choice> && AGP_INTEL && ACPI || PANEL_SHARP_LS037V7DW01 && HAS_IOMEM && OMAP2_DSS || PANEL_ACX565AKM && HAS_IOMEM && OMAP2_DSS && OMAP2_DSS_SDI && SPI || USB_APPLEDISPLAY && USB_SUPPORT && USB || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || SONY_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && RFKILL || THINKPAD_ACPI && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || ACPI_ASUS && X86 && X86_PLATFORM_DEVICES && ACPI || ACPI_CMPC && X86_PLATFORM_DEVICES && X86 && ACPI && (RFKILL || RFKILL=n)) selects BACKLIGHT_CLASS_DEVICE which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) warning: (STUB_POULSBO && HAS_IOMEM && PCI && ACPI || FB_BACKLIGHT && HAS_IOMEM && FB || DRM_I915 && <choice> && AGP_INTEL && ACPI || PANEL_SHARP_LS037V7DW01 && HAS_IOMEM && OMAP2_DSS || PANEL_ACX565AKM && HAS_IOMEM && OMAP2_DSS && OMAP2_DSS_SDI && SPI || USB_APPLEDISPLAY && USB_SUPPORT && USB || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || SONY_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && RFKILL || THINKPAD_ACPI && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || ACPI_ASUS && X86 && X86_PLATFORM_DEVICES && ACPI || ACPI_CMPC && X86_PLATFORM_DEVICES && X86 && ACPI && (RFKILL || RFKILL=n)) selects BACKLIGHT_CLASS_DEVICE which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) CHK include/linux/version.h CHK include/generated/utsrelease.h CALL scripts/checksyscalls.sh ... FWIW...
Fedora kernel kernel-2.6.37-0.rc6.git5.1.fc15.x86_64
Shows the PWM message once.
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
Subsystem: Toshiba America Info Systems Device ff50
Flags: bus master, fast devsel, latency 0, IRQ 41
Memory at f0000000 (64-bit, non-prefetchable) [size=1M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915
Kernel modules: i915
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
Subsystem: Toshiba America Info Systems Device ff50
Flags: bus master, fast devsel, latency 0
Memory at f0100000 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 3
(In reply to comment #13) > OK, so this is not a duplicate, sorry. > > Are there any _functional_ problems (other than the glitches fixed in > bug #23382) related to the new messages in the log? As of 2.6.37, message is still there, but I couldn't see any functional problem. Chris, what would be needed to implement what's said in that comment? We need to compute the PWM frequency as a function of the panel clock frequency, aiui. Needs digging into the BIOS specification since it the method is not clear from the driver documentation. Chris, I need your advice on this. My LVDS connection is broken on my laptop so I use external LCD monitor hooked up via D-SUB. Since 2.6.37 hit stable, my monitor occasionaly (not related to sleep, it happens anytime, during browsing or whatever) switches off backlight. The monitor itself is still on, when I point a flash light in the panel I can see a debris of my desktop. I have to switch my monitor on and off a few times before it turnes on the backlight. At first I thought that caps on the inverter leaked, but now, reading all these monitor related problems on bugzilla and LKML I have doubts. Could it be, that SSC and PLL patches (or something else but these comes to mind as they have been included between rc8 and stable) caused the feedback circuitry of my monitor to react and to kill the backlight preventively ? So I compiled 2.6.36.3 and I haven't had problems with it so far (for two days now). Switching back to 2.6.37 eventually triggered the problem again. There are no dmesg errors except the one described in this bug report. 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) Samsung 931BF is the monitor model. So is this related to this PWM bug, should I file a new bug report or this is a possible duplicate of existing ones ? Thanks! Oh yeah, with not-so-old kernels (before 2.6.37) I don't remember seeing the PWM error message at all. Is it just that before it was not getting printed? We added some code to handle the various BLC combination modes and in doing so I spotted a case we couldn't handle at all. I get this too after upgrading 2.6.35 to 2.6.37 (on an atom based netbook with a 945GME. I never had it before. Everything seems to work though. I am getting frequent X freezes here, at which time I see quite a few of these "*ERROR* fixme: max PWM is zero." messages. It's not infinite because X gets killed (or crashes, whatever) once it hits, presumably, this bug. Mind you that I used to get the "[drm:init_ring_common] *ERROR* render ring head not reset to zero ctl 00000000 head..." and X frozen, but now I only see this PWM message and X getting killed (it now closes up, while before - e.g. 2.6.36, it used to simply freeze not updating the screen anymore - keyboard would work, etc). So, unless I'm told the problem I'm having is somehow related to my previous error (gpu hung), this PWM error causes an X crash (or vice-versa?). I'm running Tremulous, which may be more "graphics intensive". I'll send my dmesg output later tonight once it crashes again. (In reply to comment #24) > I am getting frequent X freezes here, at which time I see quite a few of > these > "*ERROR* fixme: max PWM is zero." messages. That's due to the GPU reset, which apparently loses this value. Fixed (by restoring the previous value). Different bug. And the cause of the GPU hang is most likely due to some brokenness in mesa. On Thursday, February 03, 2011, Paul Rolland wrote:
> Hello,
>
> [root@tux ~]# uname -a
> Linux tux.DEF.witbe.net 2.6.38-rc3 #1 SMP Tue Feb 1 08:49:29 CET 2011 x86_64
> x86_64 x86_64 GNU/Linux
>
> [root@tux ~]# grep i915 /var/log/messages
> Feb 1 19:27:43 tux kernel: i915 0000:00:02.0: PCI INT A -> GSI 16 (level,
> low) -> IRQ 16
> Feb 1 19:27:43 tux kernel: [drm] Initialized i915 1.6.0 20080730 for
> 0000:00:02.0 on minor 0
> Feb 1 19:45:03 tux kernel: [drm:i915_gem_mmap_gtt_ioctl] *ERROR* Attempting
> to mmap a purgeable buffer
> ...
> Feb 2 18:18:04 tux kernel: [drm:i915_gem_mmap_gtt_ioctl] *ERROR* Attempting
> to mmap a purgeable buffer
> Feb 2 18:18:04 tux kernel: [drm:i915_gem_mmap_gtt_ioctl] *ERROR* Attempting
> to mmap a purgeable buffer
> Feb 2 19:03:34 tux kernel: [drm:i915_gem_object_bind_to_gtt] *ERROR*
> Attempting to bind a purgeable object
> Feb 2 19:03:49 tux kernel: RIP: 0010:[<ffffffff81326378>]
> [<ffffffff81326378>] i915_gem_object_unpin+0xa8/0xb0
> Feb 2 19:03:49 tux kernel: [<ffffffff8131a755>]
> i915_driver_lastclose+0x35/0x70
> Feb 2 19:03:49 tux kernel: RIP [<ffffffff81326378>]
> i915_gem_object_unpin+0xa8/0xb0
>
>
> Hmmm... Even got a crash, probably that's why my KDE session was killed
> yesterday :(
>
> Feb 2 19:03:34 tux kernel: [drm:i915_gem_object_bind_to_gtt] *ERROR*
> Attempting
> to bind a purgeable object
> Feb 2 19:03:36 tux kdm[1426]: X server for display :0 terminated
> unexpectedly
> Feb 2 19:03:49 tux kdm: :0[2103]: Abnormal termination of greeter for
> display :
> 0, code 1, signal 0
> Feb 2 19:03:49 tux kdm: :0[2103]: Fatal X server IO error: Interrupted
> system call
> Feb 2 19:03:49 tux kernel: Kernel BUG at ffffffff81326378 [verbose debug
> info u
> navailable]
> Feb 2 19:03:49 tux kernel: invalid opcode: 0000 [#1] SMP
> Feb 2 19:03:49 tux kernel: last sysfs file:
> /sys/devices/pci0000:00/0000:00:02.
> 1/resource
> Feb 2 19:03:49 tux kernel: CPU 1
> Feb 2 19:03:49 tux kernel: Modules linked in: vboxnetadp vboxnetflt vboxdrv
> snd
> _seq_dummy bluetooth tcp_lp fuse vfat fat coretemp hwmon cpufreq_ondemand
> acpi_c
> pufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ipv6
> dm_cry
> pt ipheth uvcvideo snd_hda_codec_idt ecb snd_hda_intel snd_hda_codec iTCO_wdt
> iw
> l3945 snd_hwdep snd_seq snd_seq_device snd_pcm iwlcore mac80211 cfg80211
> iTCO_ve
> ndor_support r8169 dell_laptop snd_timer mii snd rfkill i2c_i801 soundcore
> micro
> code snd_page_alloc dcdbas mmc_block sdhci_pci sdhci mmc_core firewire_ohci
> fire
> wire_core [last unloaded: ip6_tables]
> Feb 2 19:03:49 tux kernel:
> Feb 2 19:03:49 tux kernel: Pid: 2116, comm: X Not tainted 2.6.38-rc3 #1
> 0T816J/
> Vostro 1520
> Feb 2 19:03:49 tux kernel: RIP: 0010:[<ffffffff81326378>]
> [<ffffffff81326378>]
> i915_gem_object_unpin+0xa8/0xb0
> Feb 2 19:03:49 tux kernel: RSP: 0018:ffff88011f7ddcc8 EFLAGS: 00010246
> Feb 2 19:03:49 tux kernel: RAX: ffff88013a523800 RBX: ffff88013a523000 RCX:
> fff
> f88013a523c28
> Feb 2 19:03:49 tux kernel: RDX: 00000000000600fa RSI: ffff88013a0c8000 RDI:
> fff
> f88013a15ae00
> Feb 2 19:03:49 tux kernel: RBP: ffff88011f7ddcc8 R08: ffff88013a51b6c8 R09:
> 000
> 0000000000000
> Feb 2 19:03:49 tux kernel: R10: ffff88013a523c40 R11: 0000000000003246 R12:
> fff
> f88013a523820
> Feb 2 19:03:49 tux kernel: R13: ffff88013a523c58 R14: ffff8800ab5d98c0 R15:
> fff
> f88013a523c28
> Feb 2 19:03:49 tux kernel: FS: 00007f374f38c840(0000)
> GS:ffff8800bd500000(0000
> ) knlGS:0000000000000000
> Feb 2 19:03:49 tux kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Feb 2 19:03:49 tux kernel: CR2: 00000000007c9ec4 CR3: 0000000114d07000 CR4:
> 000
> 00000000406e0
> Feb 2 19:03:49 tux kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 000
> 0000000000000
> Feb 2 19:03:49 tux kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 000
> 0000000000400
> Feb 2 19:03:49 tux kdm[1426]: X server died during startup
> Feb 2 19:03:49 tux kdm[1426]: X server for display :0 cannot be started,
> sessin disabled
> Feb 2 19:03:49 tux kernel: Process X (pid: 2116, threadinfo
> ffff88011f7dc000, task ffff880108948500)
> Feb 2 19:03:49 tux kernel: Stack:
> Feb 2 19:03:49 tux kernel: ffff88011f7ddce8 ffffffff81333325
> ffff88013a523000 ffffffff81a3cae0
> Feb 2 19:03:49 tux kernel: ffff88011f7ddd18 ffffffff812ff3bd
> ffff8800ab5d98c0 ffff88013a157988
> Feb 2 19:03:49 tux kernel: ffff8800ab5d98c0 0000000000000000
> ffff88011f7dddd8 ffffffff813004af
> Feb 2 19:03:49 tux kernel: Call Trace:
> Feb 2 19:03:49 tux kernel: [<ffffffff81333325>] intel_crtc_disable+0x45/0x60
> Feb 2 19:03:49 tux kernel: [<ffffffff812ff3bd>]
> drm_helper_disable_unused_functions+0x13d/0x180
> Feb 2 19:03:49 tux kernel: [<ffffffff813004af>]
> drm_crtc_helper_set_config+0x82f/0xa00
> Feb 2 19:03:49 tux kernel: [<ffffffff81304e73>] ? drm_ioctl+0x3d3/0x4e0
> Feb 2 19:03:49 tux kernel: [<ffffffff812fecf9>]
> drm_fb_helper_force_kernel_mode+0x79/0xb0
> Feb 2 19:03:49 tux kernel: [<ffffffff812fed39>]
> drm_fb_helper_restore+0x9/0x30
> Feb 2 19:03:49 tux kernel: [<ffffffff8131a755>]
> i915_driver_lastclose+0x35/0x70
> Feb 2 19:03:49 tux kernel: [<ffffffff81305204>] drm_lastclose+0x44/0x300
> Feb 2 19:03:49 tux kernel: [<ffffffff81305c13>] drm_release+0x503/0x6b0
> Feb 2 19:03:49 tux kernel: [<ffffffff810f7f52>] fput+0xe2/0x260
> Feb 2 19:03:49 tux kernel: [<ffffffff810f4a78>] filp_close+0x58/0x90
> Feb 2 19:03:49 tux kernel: [<ffffffff810f4b40>] sys_close+0x90/0xe0
> Feb 2 19:03:49 tux kernel: [<ffffffff8100243b>]
> system_call_fastpath+0x16/0x1b
> Feb 2 19:03:49 tux kernel: Code: 89 96 d0 15 00 00 48 81 c6 c8 15 00 00 48
> 89 87 b8 00 00 00 48 89 b7 b0 00 00 00 48 89 10 80 a7 e2 00 00 00 f7 c9 c3 0f
> 0b eb fe <0f> 0b eb fe 0f 1f 40 00 55 48 89 f8 48 89 e5 48 8b bf e8 00 00
> Feb 2 19:03:49 tux kernel: RIP [<ffffffff81326378>]
> i915_gem_object_unpin+0xa8/0xb0
> Feb 2 19:03:49 tux kernel: RSP <ffff88011f7ddcc8>
> Feb 2 19:03:49 tux kernel: ---[ end trace 83ffc517ec5d0200 ]---
According to #22652 "*ERROR* Attempting to mmap a purgeable buffer" warns about a userspace error. What userspace versions are you using? (xserver, libdrm, xf86-video-intel, mesa, .. ) Hello Florian, Some versions : X.Org X Server 1.8.2 (from /var/log/Xorg.0.log) Release Date: 2010-07-01 [ 33.072] X Protocol Version 11, Revision 0 [ 33.072] Build Operating System: x86-17 2.6.32-44.el6.x86_64 xorg-x11-server-Xorg.x86_64 1.8.2-4.fc13 @updates [root@tux ~]# yum list installed | grep drm libdrm.i686 2.4.21-2.fc13 @updates libdrm.x86_64 2.4.21-2.fc13 @updates libdrm-devel.x86_64 2.4.21-2.fc13 @updates [root@tux ~]# yum list installed | grep mesa mesa-dri-drivers.i686 7.8.2-1.fc13 @updates mesa-dri-drivers.x86_64 7.8.2-1.fc13 @updates mesa-libGL.i686 7.8.2-1.fc13 @updates mesa-libGL.x86_64 7.8.2-1.fc13 @updates mesa-libGL-devel.x86_64 7.8.2-1.fc13 @updates mesa-libGLU.i686 7.8.2-1.fc13 @updates mesa-libGLU.x86_64 7.8.2-1.fc13 @updates mesa-libGLU-devel.x86_64 7.8.2-1.fc13 @updates [root@tux ~]# yum list installed | grep intel xorg-x11-drv-intel.x86_64 2.11.0-5.fc13 @updates Paul Under the assumption that the crashes and freezes of the xserver are symptoms of those userspace bugs, I'm closing this. p.s.: I hope nobody is offended by me using the will-not-fix tag? I couldn't decide between invalid, documented and will-not-fix and choose one at random. |