kernel 3.4.0 oops

Chris Wilson chris at chris-wilson.co.uk
Tue May 22 02:33:30 PDT 2012


On Tue, 22 May 2012 11:20:44 +0200, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Mon, May 21, 2012 at 07:33:10PM +0300, Andrei Popa wrote:
> > Hi,
> > 
> > With kernel 3.4.0 and xen I got the following oops.
> > 
> > Grub is setup like this:
> > menuentry 'vmlinuz-3.4.0' --class gnu-linux --class gnu --class os {
> >         insmod part_gpt
> >         insmod ext2
> >         set root='(/dev/sda,gpt2)'
> >         search --no-floppy --fs-uuid --set=root
> > 56f0f4f0-eb04-438a-97e4-c955e4b34137
> >         multiboot /boot/xen.gz
> >         module /boot/vmlinuz-3.4.0 root=/dev/sda2 ro
> > libahci.ignore_sss=1 quiet rootfstype=ext4 acpi_sleep=s3_bios
> > usbcore.autosuspend=1 i915.i915_enable_rc6=1 rootdelay=1 fastboot
> > resume=/dev/sdb2 resume2=/dev/sdb2 raid=noautodetect
> > }
> > 
> > ------------[ cut here ]------------
> > WARNING: at drivers/gpu/drm/i915/i915_gem.c:2410
> > i915_gem_object_put_fence+0x9c/0xb0()
> > Hardware name: HP ProBook 4320s
> > Modules linked in: rt2800pci eeprom_93cx6 rt2x00pci rt2800lib rt2x00lib
> > mac80211 psmouse cfg80211 r8169
> > Pid: 1034, comm: X Not tainted 3.4.0 #2
> > Call Trace:
> > [<ffffffff8107ae0b>] ? warn_slowpath_common+0x7b/0xc0
> > [<ffffffff814629dc>] ? i915_gem_object_put_fence+0x9c/0xb0
> > [<ffffffff81463e81>] ? i915_gem_object_unbind+0x91/0x1f0
> > [<ffffffff81463ff9>] ? i915_gem_free_object_tail+0x19/0xc0
> > [<ffffffff8146faa8>] ? intel_user_framebuffer_destroy+0x68/0x70
> > [<ffffffff8144e1d3>] ? drm_fb_release+0x73/0x90
> > [<ffffffff8143f888>] ? drm_release+0x5c8/0x6f0
> > [<ffffffff817cb654>] ? _raw_spin_lock+0x14/0x20
> > [<ffffffff8112c9bd>] ? fput+0xdd/0x260
> > [<ffffffff81128d8f>] ? filp_close+0x5f/0x90
> > [<ffffffff8107e5cd>] ? put_files_struct+0xbd/0x140
> > [<ffffffff81372787>] ? call_rwsem_wake+0x17/0x30
> > [<ffffffff8107edc4>] ? do_exit+0x684/0x8e0
> > [<ffffffff817cb654>] ? _raw_spin_lock+0x14/0x20
> > [<ffffffff81140bf8>] ? dput+0x198/0x1a0
> > [<ffffffff811469c4>] ? vfsmount_lock_local_lock+0x24/0x30
> > [<ffffffff8107f2b3>] ? do_group_exit+0x53/0xc0
> > [<ffffffff8107f332>] ? sys_exit_group+0x12/0x20
> > [<ffffffff817cc34a>] ? error_exit+0x2a/0x60
> > [<ffffffff817cc639>] ? system_call_fastpath+0x16/0x1b
> > ---[ end trace 73252172cb6d3543 ]---
> 
> Can you please attach the complete dmesg that contains this WARN
> backtrace? Depending upon how we ended up here, we should get more stuff
> (which would be pretty important to know to correctly diagnose the bug).

I think I encountered this bug whilst developing "drm/i915:
Asynchronously unpin the old framebuffer after the next vblank". Try

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index afab263..9b94871 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1865,6 +1865,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
 		goto err_unpin;
 
 	i915_gem_object_pin_fence(obj);
+	drm_gem_object_reference(&obj->base);
 
 	dev_priv->mm.interruptible = true;
 	return 0;
@@ -1880,6 +1881,7 @@ void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
 {
 	i915_gem_object_unpin_fence(obj);
 	i915_gem_object_unpin(obj);
+	drm_gem_object_unreference(&obj->base);
 }
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the dri-devel mailing list