dri-devel October 2012

dri-devel@lists.freedesktop.org

139 participants
712 discussions

pipe B assertion failure (expected off, current on)
by Bjørn Mork 11 Oct '12

11 Oct '12

Hello, from time to time, I see the following warning on resume: [ 7022.245347] PM: Syncing filesystems ... done. [ 7022.271923] PM: Preparing system for mem sleep [ 7022.324107] ------------[ cut here ]------------ [ 7022.324154] WARNING: at drivers/gpu/drm/i915/intel_display.c:1225 intel_crtc_disable+0x52/0x86 [i915]() [ 7022.324155] Hardware name: 2776LEG [ 7022.324157] pipe B assertion failure (expected off, current on) [ 7022.324197] Modules linked in: cdc_mbim(O) cdc_ncm(O) usbnet(O) mii usb_storage uas cdc_acm usbhid hid cdc_wdm netconsole configfs xt_multiport iptable_filter ip_tables rfcomm bnep cpufreq_userspace cpufreq_stats cpufreq_conservative cpufreq_powersave xt_hl binfmt_misc ip6table_filter ip6_tables x_tables fuse nfsd nfs_acl nfs lockd fscache sunrpc 8021q garp stp llc tun ext2 loop btusb bluetooth crc16 iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm arc4 snd_page_alloc iwldvm mac80211 snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_timer snd_seq_device uvcvideo videobuf2_vmalloc thinkpad_acpi psmouse iwlwifi acpi_cpufreq videobuf2_memops lpc_ich coretemp videobuf2_core nvram i2c_i801 qcserial usb_wwan kvm_intel usbserial kvm videodev evdev serio_raw cfg80211 mfd_core rfkill snd ac battery wmi i915 soundcore video drm_kms_helper mei mperf drm processor i2c_algo_bit i2c_core button ext3 mbcache jbd sha256_generic ablk_helper cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod nbd sg sd_mod sr_mod cdrom crc_t10dif microcode thermal thermal_sys ahci libahci uhci_hcd libata scsi_mod ehci_hcd e1000e usbcore usb_common [last unloaded: mii] [ 7022.324230] Pid: 5161, comm: Xorg Tainted: G W O 3.6.0 #36 [ 7022.324231] Call Trace: [ 7022.324240] [<ffffffff8103e0ed>] ? warn_slowpath_common+0x78/0x8c [ 7022.324243] [<ffffffff8103e19f>] ? warn_slowpath_fmt+0x45/0x4a [ 7022.324262] [<ffffffffa029cce1>] ? intel_crtc_disable+0x52/0x86 [i915] [ 7022.324271] [<ffffffffa01cbf0a>] ? drm_helper_disable_unused_functions+0xf1/0x133 [drm_kms_helper] [ 7022.324277] [<ffffffffa01ccdd0>] ? drm_crtc_helper_set_config+0x185/0x919 [drm_kms_helper] [ 7022.324286] [<ffffffffa01cb738>] ? drm_fb_helper_set_par+0x64/0xac [drm_kms_helper] [ 7022.324294] [<ffffffffa00fc097>] ? journal_add_journal_head+0xa7/0x123 [jbd] [ 7022.324298] [<ffffffff811f6819>] ? fb_set_var+0x274/0x36d [ 7022.324305] [<ffffffffa00f5609>] ? journal_stop+0x203/0x215 [jbd] [ 7022.324319] [<ffffffffa011aaca>] ? __ext3_journal_stop+0x1f/0x3d [ext3] [ 7022.324327] [<ffffffffa010f5fa>] ? ext3_ordered_write_end+0x14b/0x172 [ext3] [ 7022.324331] [<ffffffff811ff487>] ? fbcon_blank+0x6d/0x234 [ 7022.324335] [<ffffffff8125653a>] ? do_unblank_screen+0xff/0x176 [ 7022.324338] [<ffffffff8124d4d5>] ? complete_change_console+0x4b/0xc0 [ 7022.324341] [<ffffffff8124df87>] ? vt_ioctl+0x936/0xfa6 [ 7022.324352] [<ffffffffa01e66ed>] ? drm_ioctl+0x2ed/0x35c [drm] [ 7022.324355] [<ffffffff81245f13>] ? tty_ioctl+0x98a/0x9f7 [ 7022.324358] [<ffffffff81139430>] ? fsnotify+0x231/0x25b [ 7022.324362] [<ffffffff81118bc0>] ? do_vfs_ioctl+0x44b/0x490 [ 7022.324364] [<ffffffff81118c50>] ? sys_ioctl+0x4b/0x6f [ 7022.324368] [<ffffffff8110b367>] ? sys_write+0x45/0x6e [ 7022.324371] [<ffffffff8136f779>] ? system_call_fastpath+0x16/0x1b [ 7022.324373] ---[ end trace fcdef2bbc6ef4c9d ]--- [ 7022.329771] Freezing user space processes ... (elapsed 0.09 seconds) done. [ 7022.426570] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 7022.442715] PM: Entering mem sleep [ 7022.442803] Suspending console(s) (use no_console_suspend to debug) [ 7022.445364] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D0 It does not seem to harm, so I have been ignoring it so far. But then I thought you might want to know since you put the warning in there :-) Grepping through the backups of my kernel logs shows that this started happening around end of July, about the time when I switched from 3.5.0 release candidates to running kernels based on the to-be-v3.6 linux-next. The first time I saw it I was running next-20120726 from linux-next. But I had a similar warning earlier too: "panel assertion failure, pipe B regs locked" This showed up until mid-March when I switched to version 3.2.12-1 of Debians 3.2.0-2-amd64 kernel, which added stable releases v3.2.11 and v3.2.12. Full output of one of those warnings: Mar 13 09:18:34 nemi kernel: [47373.956730] ------------[ cut here ]------------ Mar 13 09:18:34 nemi kernel: [47373.956776] WARNING: at /build/buildd-linux-2.6_3.2.9-1-amd64-KTPapN/linux-2.6-3.2.9/debian/build/source_amd64_none/drivers/gpu/drm/i915/intel_display.c:915 i9xx_crtc_enable+0x7b/0x1 5a [i915]() Mar 13 09:18:34 nemi kernel: [47373.956780] Hardware name: 2776LEG Mar 13 09:18:34 nemi kernel: [47373.956783] panel assertion failure, pipe B regs locked Mar 13 09:18:34 nemi kernel: [47373.956785] Modules linked in: xt_state ipt_MASQUERADE qmi_wwan(O) bridge iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 nfnetlink_log nfnetlink option usb_wwan usbserial usb_storage uas acpi_cpufreq mperf cpufreq_userspace cpufreq_stats cpufreq_conservative cpufreq_powersave xt_hl ip6t_LOG xt_multiport ip6table_filter iptable_filter ip6_tables ip_tables x_tables parport_pc ppdev lp parport rfcomm bnep binfmt_misc uinput microcode fuse nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc kvm_intel kvm 8021q garp stp tun ext2 coretemp loop btusb bluetooth crc16 snd_hda_codec_conexant joydev snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm thinkpad_acpi snd_seq_midi arc4 snd_rawmidi snd_seq_midi_event iwlwifi snd_seq uvcvideo mac80211 videodev cdc_ether usbnet mii media cdc_wdm(O) snd_timer snd_seq_device cdc_acm v4l2_compat_ioctl32 cfg80211 i915 rfkill evdev drm_kms_helper snd drm i2c_i801 psmouse iTCO_wdt serio_raw iTCO_vendor_support i2c_al Mar 13 09:18:34 nemi kernel: go_bit soundcore snd_page_alloc ac nvram battery power_supply i2c_core wmi video button processor ext3 jbd mbcache sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod nbd sd_mod crc_t10dif sr_mod cdrom uhci_hcd ahci libahci thermal thermal_sys libata ehci_hcd scsi_mod usbcore e1000e usb_common [last unloaded: qmi_wwan] Mar 13 09:18:34 nemi kernel: [47373.956881] Pid: 27929, comm: kworker/1:1 Tainted: G O 3.2.0-2-amd64 #1 Mar 13 09:18:34 nemi kernel: [47373.956884] Call Trace: Mar 13 09:18:34 nemi kernel: [47373.956892] [<ffffffff81046879>] ? warn_slowpath_common+0x78/0x8c Mar 13 09:18:34 nemi kernel: [47373.956897] [<ffffffff81046925>] ? warn_slowpath_fmt+0x45/0x4a Mar 13 09:18:34 nemi kernel: [47373.956918] [<ffffffffa0269810>] ? assert_panel_unlocked+0x7f/0xc2 [i915] Mar 13 09:18:34 nemi kernel: [47373.956936] [<ffffffffa026e63c>] ? i9xx_crtc_enable+0x7b/0x15a [i915] Mar 13 09:18:34 nemi kernel: [47373.956953] [<ffffffffa026935a>] ? intel_crtc_dpms+0x36/0xf5 [i915] Mar 13 09:18:34 nemi kernel: [47373.956964] [<ffffffffa0248cf0>] ? drm_fb_helper_blank+0x75/0x116 [drm_kms_helper] Mar 13 09:18:34 nemi kernel: [47373.956969] [<ffffffff811d05ae>] ? fb_blank+0x36/0x63 Mar 13 09:18:34 nemi kernel: [47373.956975] [<ffffffff811d9a3f>] ? fbcon_blank+0xe7/0x1c7 Mar 13 09:18:34 nemi kernel: [47373.956980] [<ffffffff81070761>] ? arch_local_irq_save+0x11/0x17 Mar 13 09:18:34 nemi kernel: [47373.956985] [<ffffffff81341734>] ? _raw_spin_lock_irqsave+0x9/0x25 Mar 13 09:18:34 nemi kernel: [47373.956991] [<ffffffff81052022>] ? lock_timer_base.isra.29+0x23/0x47 Mar 13 09:18:34 nemi kernel: [47373.956995] [<ffffffff810522de>] ? __mod_timer+0x139/0x14b Mar 13 09:18:34 nemi kernel: [47373.956999] [<ffffffff8122f6b7>] ? poke_blanked_console+0xac/0xac Mar 13 09:18:34 nemi kernel: [47373.957003] [<ffffffff8122f6b7>] ? poke_blanked_console+0xac/0xac Mar 13 09:18:34 nemi kernel: [47373.957008] [<ffffffff8122ed2a>] ? do_unblank_screen+0xeb/0x144 Mar 13 09:18:34 nemi kernel: [47373.957012] [<ffffffff8122f726>] ? console_callback+0x6f/0xef Mar 13 09:18:34 nemi kernel: [47373.957016] [<ffffffff8105ae4d>] ? process_one_work+0x163/0x284 Mar 13 09:18:34 nemi kernel: [47373.957020] [<ffffffff8105be15>] ? worker_thread+0xc2/0x145 Mar 13 09:18:34 nemi kernel: [47373.957024] [<ffffffff8105bd53>] ? manage_workers.isra.23+0x15b/0x15b Mar 13 09:18:34 nemi kernel: [47373.957028] [<ffffffff8105ef51>] ? kthread+0x76/0x7e Mar 13 09:18:34 nemi kernel: [47373.957033] [<ffffffff81348834>] ? kernel_thread_helper+0x4/0x10 Mar 13 09:18:34 nemi kernel: [47373.957038] [<ffffffff8105eedb>] ? kthread_worker_fn+0x139/0x139 Mar 13 09:18:34 nemi kernel: [47373.957041] [<ffffffff81348830>] ? gs_change+0x13/0x13 Mar 13 09:18:34 nemi kernel: [47373.957044] ---[ end trace 6553f1ddb073fd07 ]--- Mar 13 09:18:34 nemi kernel: [47373.992119] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state Mar 13 09:18:34 nemi kernel: [47373.995710] render error detected, EIR: 0x00000010 Mar 13 09:18:34 nemi kernel: [47373.995712] IPEIR: 0x00000000 Mar 13 09:18:34 nemi kernel: [47373.995714] IPEHR: 0x00000000 Mar 13 09:18:34 nemi kernel: [47373.995716] INSTDONE: 0xfffffffe Mar 13 09:18:34 nemi kernel: [47373.995717] INSTPS: 0x00000000 Mar 13 09:18:34 nemi kernel: [47373.995719] INSTDONE1: 0xffffffff Mar 13 09:18:34 nemi kernel: [47373.995721] ACTHD: 0x00000000 Mar 13 09:18:34 nemi kernel: [47373.995723] page table error Mar 13 09:18:34 nemi kernel: [47373.995724] PGTBL_ER: 0x00000000 The hardware is a Lenovo X301 laptop with a panel identified as "LTD133EQ1B" and this controller: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:20e4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 45 Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 1800 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0300c Data: 4152 Capabilities: [d0] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: i915 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem: Lenovo Device [17aa:20e4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at f0400000 (64-bit, non-prefetchable) [size=1M] Capabilities: [d0] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Let me know if you want ot have more details about these warnings. Otherwise I'll just keep ignoring them ;-) Bjørn

2 2

[Patch 0/1]drm_irq: Introducing the irq_thread support
by Liu, Chuansheng 11 Oct '12

11 Oct '12

This patch is for introducing the irq thread support in drm_irq. Why we need irq thread in drm_irq code? In our GPU system, the gpu interrupt handler need some time even > 1ms to finish, in that case, the whole system will stay in irq disable status. One case is: when audio is playing, it sometimes effects the audio quality. So we have to introduce the irq thread in drm_irq, it can help us move some heavy work into irq thread and other irq interrupts can be handled in time. Also the IRQF_ONESHOT is helpful for irq thread. Include one patch: [PATCH 01/1] drm_irq-Introducing-the-irq_thread-support

7 12

[Bug 55047] New: [855gm] Boots noisely with the lid close (but works!)
by bugzilla-daemon＠freedesktop.org 11 Oct '12

11 Oct '12

https://bugs.freedesktop.org/show_bug.cgi?id=55047 Bug #: 55047 Summary: [855gm] Boots noisely with the lid close (but works!) Classification: Unclassified Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: minor Priority: medium Component: DRM/other AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: chris(a)chris-wilson.co.uk Created attachment 67320 --> https://bugs.freedesktop.org/attachment.cgi?id=67320 dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[PATCH] drm: fix returning -EINVAL on setmaster if another master is active
by David Herrmann 11 Oct '12

11 Oct '12

We link every DRM "file_priv" to a "drm_master" structure. Currently, the drmSetMaster() call returns 0 when there is _any_ active master associated with the "drm_master" structure of the calling "file_priv". This means, that after drmSetMaster() we are not guaranteed to be DRM-Master and might not be able to perform mode-setting. A way to reproduce this is by starting weston with the DRM backend from within an X-console (eg., xterm). Because the xserver's "drm_master" is currently active, weston is assigned to the same master but is inactive because its VT is inactive and the xserver is still active. But when "fake-activating" weston, it calls drmSetMaster(). With current behavior this returns "0/success" and weston thinks that it is DRM-Master, even though it is not (as the xserver is still DRM-Master). Expected behavior would be drmSetMaster() to return -EINVAL, because the xserver is still DRM-Master. This patch changes exactly that. The only way this bogus behavior would be useful is for clients to check whether their associated "drm_master" is currently the active DRM-Master. But this logic fails if no DRM-Master is currently active at all. Because then the client itself would become DRM-Master (if it is root) and this makes this whole thing useles. Also note that the second "if-condition": file_priv->minor->master != file_priv->master is always true and can be skipped. Signed-off-by: David Herrmann <dh.herrmann(a)googlemail.com> --- Note: Note that this only removes the "if-clause". The code that performs the setmaster() is actually left unchanged but makes the patch look scarier than it really is. drivers/gpu/drm/drm_stub.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c index c236fd2..581e61d 100644 --- a/drivers/gpu/drm/drm_stub.c +++ b/drivers/gpu/drm/drm_stub.c @@ -221,20 +221,20 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data, if (!file_priv->master) return -EINVAL; - if (!file_priv->minor->master && - file_priv->minor->master != file_priv->master) { - mutex_lock(&dev->struct_mutex); - file_priv->minor->master = drm_master_get(file_priv->master); - file_priv->is_master = 1; - if (dev->driver->master_set) { - ret = dev->driver->master_set(dev, file_priv, false); - if (unlikely(ret != 0)) { - file_priv->is_master = 0; - drm_master_put(&file_priv->minor->master); - } + if (file_priv->minor->master) + return -EINVAL; + + mutex_lock(&dev->struct_mutex); + file_priv->minor->master = drm_master_get(file_priv->master); + file_priv->is_master = 1; + if (dev->driver->master_set) { + ret = dev->driver->master_set(dev, file_priv, false); + if (unlikely(ret != 0)) { + file_priv->is_master = 0; + drm_master_put(&file_priv->minor->master); } - mutex_unlock(&dev->struct_mutex); } + mutex_unlock(&dev->struct_mutex); return 0; } -- 1.7.12.2

2 3

[PATCH 0/3] [RFC] DRM Render Nodes
by Kristian Høgsberg 11 Oct '12

11 Oct '12

Here's the patch to implement render nodes as discussed in the "DRM2" talk at XDC: http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 The core problem is that DRM security is compromised in the face of VT switching and multiple DRM masters. Any local user can access all shared buffers from within any X server on the system, even when that user doesn't have access to any of those X servers. The fix for this is to use dmabuf/prime and fd passing for buffer sharing. That infrastructure is already in place and we need to start using that in user space. Once we're passing buffers between display servers and clients in a point-to-point fashion, we no longer need to authenticate clients. We just need to make sure they can only render and import/export buffers to fds. That's what this patch does, by creating a new type of drm device node. Accessing this node doesn't require authentication (and as such can be used without a master, ie headless), but will only expose the safe, modern (DRI2ish) rendering ioctls. Once userspace is sharing buffers through fd passing, the legacy card0 node can be locked down by unix permissions, for example in a drm-master group, so that only setgid binaries (X, weston, other KMS apps) can access it. Kristian See also: http://wiki.x.org/wiki/Events/XDC2012/Proceedings#Graphics_stack_security https://lwn.net/Articles/517375/

5 10

[PATCH] Android.mk: use LOCAL_COPY_HEADERS to export headers. v2
by Tapani Pälli 11 Oct '12

11 Oct '12

From: Haitao Huang <haitao.huang(a)intel.com> Export necessary header files used by other components for Android, such as libva intel-driver, gralloc, hwcomposer, etc. Signed-off-by: Haitao Huang <haitao.huang(a)intel.com> [chad: Fixed inconsistent indentation.] Signed-off-by: Chad Versace <chad.versace(a)linux.intel.com> --- Android.mk | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/Android.mk b/Android.mk index 1029dc6..68db5df 100644 --- a/Android.mk +++ b/Android.mk @@ -1,5 +1,5 @@ # -# Copyright © 2011 Intel Corporation +# Copyright © 2011-2012 Intel Corporation # # Permission is hereby granted, free of charge, to any person obtaining a # copy of this software and associated documentation files (the "Software"), @@ -45,6 +45,16 @@ LOCAL_C_INCLUDES := \ LOCAL_CFLAGS := \ -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 +LOCAL_COPY_HEADERS := \ + xf86drm.h \ + include/drm/drm_fourcc.h \ + include/drm/drm.h \ + include/drm/drm_mode.h \ + include/drm/drm_sarea.h \ + include/drm/i915_drm.h \ + intel/intel_bufmgr.h \ + +LOCAL_COPY_HEADERS_TO := libdrm include $(BUILD_SHARED_LIBRARY) include $(LOCAL_PATH)/intel/Android.mk -- 1.7.11.7

3 4

re: drm/nouveau: port all engines to new engine module format
by Dan Carpenter 11 Oct '12

11 Oct '12

Hello Ben Skeggs, The patch ebb945a94bba: "drm/nouveau: port all engines to new engine module format" from Jul 20, 2012, leads to the following warning: drivers/gpu/drm/nouveau/nouveau_abi16.c:264 nouveau_abi16_ioctl_channel_alloc() warn: should '1 << init->channel' be a 64 bit type 262 INIT_LIST_HEAD(&chan->notifiers); 263 list_add(&chan->head, &abi16->channels); 264 abi16->handles |= (1 << init->channel); ^^^^^^^^^^^^^^^^^^^^ This will only work for the first 30 channels, otherwise it needs to be: abi16->handles |= (u64)1 << init->channel; 265 But I don't couldn't tell how many channels are actually possible and I was confused by this. 132 /* destroy channel object, all children will be killed too */ 133 if (chan->chan) { 134 abi16->handles &= ~(1 << (chan->chan->handle & 0xffff)); Is that bitwise AND in the right place? Oxff would be enough to hold 0-63. 135 nouveau_channel_del(&chan->chan); 136 } regards, dan carpenter

1 0

[PATCH -next] drm: fix radeon printk format warnings
by Randy Dunlap 10 Oct '12

10 Oct '12

From: Randy Dunlap <rdunlap(a)xenotime.net> Fix printk format warnings in gpu/drm/radeon/: drivers/gpu/drm/radeon/radeon_atpx_handler.c:151:3: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t' drivers/gpu/drm/radeon/radeon_acpi.c:204:3: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t' drivers/gpu/drm/radeon/radeon_acpi.c:488:3: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t' Signed-off-by: Randy Dunlap <rdunlap(a)xenotime.net> Cc: David Airlie <airlied(a)linux.ie> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_acpi.c | 4 ++-- drivers/gpu/drm/radeon/radeon_atpx_handler.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) --- linux-next-20121010.orig/drivers/gpu/drm/radeon/radeon_atpx_handler.c +++ linux-next-20121010/drivers/gpu/drm/radeon/radeon_atpx_handler.c @@ -148,7 +148,7 @@ static int radeon_atpx_verify_interface( size = *(u16 *) info->buffer.pointer; if (size < 8) { - printk("ATPX buffer is too small: %lu\n", size); + printk("ATPX buffer is too small: %zu\n", size); err = -EINVAL; goto out; } --- linux-next-20121010.orig/drivers/gpu/drm/radeon/radeon_acpi.c +++ linux-next-20121010/drivers/gpu/drm/radeon/radeon_acpi.c @@ -201,7 +201,7 @@ static int radeon_atif_verify_interface( size = *(u16 *) info->buffer.pointer; if (size < 12) { - DRM_INFO("ATIF buffer is too small: %lu\n", size); + DRM_INFO("ATIF buffer is too small: %zu\n", size); err = -EINVAL; goto out; } @@ -485,7 +485,7 @@ static int radeon_atcs_verify_interface( size = *(u16 *) info->buffer.pointer; if (size < 8) { - DRM_INFO("ATCS buffer is too small: %lu\n", size); + DRM_INFO("ATCS buffer is too small: %zu\n", size); err = -EINVAL; goto out; }

1 0

[BUG] drm/nouveau: NULL pointer dereference in nouveau_channel_new()
by Ortwin Glück 10 Oct '12

10 Oct '12

Hi, Current nouveau code in Linus' tree oopses with noaccel. Didn't happen in 3.6. Full dmesg attached. Ortwin BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 Oct 10 18:05:49 localhost kernel: IP: [<ffffffff8144082e>] nouveau_channel_new+0x41e/0x670 Oct 10 18:05:49 localhost kernel: PGD 22ddd7067 PUD 22f76f067 PMD 0 Oct 10 18:05:49 localhost kernel: Oops: 0000 [#1] PREEMPT SMP Oct 10 18:05:49 localhost kernel: Modules linked in: Oct 10 18:05:49 localhost kernel: CPU 0 Oct 10 18:05:49 localhost kernel: Pid: 2723, comm: X Not tainted 3.7.0-pre #1 Hewlett-Packard HP EliteBook 8540w/1521 Oct 10 18:05:49 localhost kernel: RIP: 0010:[<ffffffff8144082e>] [<ffffffff8144082e>] nouveau_channel_new+0x41e/0x670 Oct 10 18:05:49 localhost kernel: RSP: 0018:ffff88023026bc68 EFLAGS: 00010202 Oct 10 18:05:49 localhost kernel: RAX: 0000000000000000 RBX: ffff88022ceeca80 RCX: 0000000000000088 Oct 10 18:05:49 localhost kernel: RDX: ffffc900127e408c RSI: ffffc900127e408c RDI: ffff88022ceeca80 Oct 10 18:05:49 localhost kernel: RBP: ffff88023026bce8 R08: 000000000000ffff R09: 0000000000000000 Oct 10 18:05:49 localhost kernel: R10: 0000000000000010 R11: 000000000000000f R12: 0000000000000000 Oct 10 18:05:49 localhost kernel: R13: ffff880231f36800 R14: ffff88022f68ca00 R15: ffff88022f68ca00 Oct 10 18:05:49 localhost kernel: FS: 00007f129a597880(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000 Oct 10 18:05:49 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 10 18:05:49 localhost kernel: CR2: 0000000000000018 CR3: 00000002300a1000 CR4: 00000000000007f0 Oct 10 18:05:49 localhost kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Oct 10 18:05:49 localhost kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Oct 10 18:05:49 localhost kernel: Process X (pid: 2723, threadinfo ffff88023026a000, task ffff880231edbde0) Oct 10 18:05:49 localhost kernel: Stack: Oct 10 18:05:49 localhost kernel: ffff88023026bcb0 ffff88022f68ca00 ffff88022f68caa8 ffff8802311be9c0 Oct 10 18:05:49 localhost kernel: d8000001d8000002 ffff88023026bc98 0000200000000000 0000000000000000 Oct 10 18:05:49 localhost kernel: 000000ffffffffff ffff880231f9afa0 ffffffffffffffff ffff8802323c0840 Oct 10 18:05:49 localhost kernel: Call Trace: Oct 10 18:05:49 localhost kernel: [<ffffffff81448cbc>] nouveau_abi16_ioctl_channel_alloc+0x15c/0x360 Oct 10 18:05:49 localhost kernel: [<ffffffff813a9120>] drm_ioctl+0x2a0/0x4f0 Oct 10 18:05:49 localhost kernel: [<ffffffff81448b60>] ? nouveau_abi16_ioctl_setparam+0x10/0x10 Oct 10 18:05:49 localhost kernel: [<ffffffff81076be4>] ? __do_page_fault+0x1c4/0x490 Oct 10 18:05:49 localhost kernel: [<ffffffff81198eb7>] do_vfs_ioctl+0x97/0x4f0 Oct 10 18:05:49 localhost kernel: [<ffffffff81199367>] sys_ioctl+0x57/0x90 Oct 10 18:05:49 localhost kernel: [<ffffffff818635a2>] system_call_fastpath+0x16/0x1b Oct 10 18:05:49 localhost kernel: Code: e2 02 48 89 df e8 d3 02 00 00 8b 83 80 00 00 00 89 83 84 00 00 00 0f 1f 80 00 00 00 00 48 8b 43 08 48 89 df 48 8b 80 f8 06 00 00 <ff> 50 18 41 89 c4 85 c0 0f 84 65 fd ff ff 0f 1f 40 00 4c 89 ff Oct 10 18:05:49 localhost kernel: RIP [<ffffffff8144082e>] nouveau_channel_new+0x41e/0x670 Oct 10 18:05:49 localhost kernel: RSP <ffff88023026bc68> Oct 10 18:05:49 localhost kernel: CR2: 0000000000000018 Oct 10 18:05:49 localhost kernel: ---[ end trace e23ae1067c361c88 ]---

1 0

RC6 for an Intel GU doesn't always work
by Toralf Förster 10 Oct '12

10 Oct '12

Sometimes - after a reboot or after wakeup from s2disk I'm observed at my ThinkPad T420 (i5-2540M CPU) w/ integrated intel graphic (i915 module) since 3.6-rc(5?), that the temperature is above 80°C (usually it is around/lower than 50 °C). Powertop-2.1 shows, that the all 4 CPU cores are mostly idle, but the GPU is running at 100%. It looks for me that the power saving mode RC6 isn't active. After 1-2 s2ram's however the issue went away. I'm observing the issue both under my Gentoo Linux and under a RH system (kernel 3.6.1 each). It is hard to bisect b/c not reliable. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

1 0

← Newer
1
...
59
60
61
62
63
64
65
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2012