[Bug 34709] with r300 (rv530) kms loaded cannot suspend kernel 2.6.37+ with uswsusp
https://bugs.freedesktop.org/show_bug.cgi?id=34709 --- Comment #5 from Michal Suchanek 2011-03-17 02:31:49 PDT --- hmm, so it does not happen on rv515gl hopefully can bisect with the rv530 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Oops at i915_gem_retire_requests_ring
(please CC me if replying)
Hi,
recently I saw a report about an oops in 2.6.38-rc7 in i915, attached at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/733780
Unfortunately the oops is cut (without call trace):
[126167.230394] BUG: unable to handle kernel paging request at 00100104
[126167.230699] IP: [] i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.231042] *pdpt = 314c1001 *pde =
[126167.231314] Oops: 0002 [#1] SMP
[126167.231471] last sysfs file:
/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now
[126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs
zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs
exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt
vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant
snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi
snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev
iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper
snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid
sky2 sdhci_pci ahci sdhci libahci
[126167.232018]
[126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae
#34-Ubuntu Gateway MC7833U /
[126167.232018] EIP: 0060:[] EFLAGS: 00213246 CPU: 0
[126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 0040 EDX: 00100100
[126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0
[126167.232018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500
task.ti=ef4d6000)
[126167.232018] Stack:
[126167.232018] f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b
0058bd85
[126167.232018] f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc
f6b3a040
[126167.232018] f1522cc0 00db f1ba6500 ffa1 0001
f1a29214
[126167.232018] Call Trace:
But we already can see some things. After downloading the debug symbols
for kernel above [1] and extracting the files (dpkg-deb -x), setting up
the source files, in gdb we can get this:
(gdb) l *(i915_gem_retire_requests_ring+0xd4)
0x17e74 is in i915_gem_retire_requests_ring
(/build/buildd/linux-2.6.38/include/linux/list.h:88).
warning: Source file is more recent than executable.
83 * This is only for internal list manipulation where we know
84 * the prev/next entries already!
85 */
86 static inline void __list_del(struct list_head * prev, struct list_head
* next)
87 {
88 next->prev = prev;
89 prev->next = next;
90 }
91
92 /**
So the oops is in a list_del call. And looking at the EDX and
dereferenced value, it's LIST_POISON1 + 4, as
p &((struct list_head *)0)->prev == 0x4
So indeed the oops is happening on __list_del at next->prev = prev,
called from i915_gem_retire_requests_ring, probably from the
i915_gem_request_remove_from_client call, going back in the code for
example:
(gdb) l *(i915_gem_retire_requests_ring+0xc6)
0x17e66 is in i915_gem_retire_requests_ring
(/build/buildd/linux-2.6.38/drivers/gpu/drm/i915/i915_gem.c:1748).
warning: Source file is more recent than executable.
1743static inline void
1744i915_gem_request_remove_from_client(struct drm_i915_gem_request
*request)
1745{
1746struct drm_i915_file_private *file_priv = request->file_priv;
1747
1748if (!file_priv)
1749return;
1750
1751spin_lock(&file_priv->mm.lock);
1752list_del(&request->client_list);
But without the call trace no way to know for certain. Anyway the oops
with LIST_POISON1 means we are trying to delete from the list an already
deleted item. As I can see in the code (I'm not used to that code, so
may be there is something I don't see), it seems we indeed have the
possibility to remove an request->client_list twice, which would cause
the above, we do list_del(&request->client_list) on both
i915_gem_request_remove_from_client and i915_gem_release
I don't know if it's the most correct fix, but perhaps the simple fix
is needed in the code. It's against latest Linus tree. We may have an
already removed client_list, or we didn't add any item to client_list
(file_priv NULL in i915_add_request)
Signed-off-by: Herton Ronaldo Krzesinski
---
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 36e66cc..6077c0d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1749,8 +1749,10 @@ i915_gem_request_remove_from_client(struct
drm_i915_gem_request *request)
return;
spin_lock(&file_priv->mm.lock);
- list_del(&request->client_list);
- request->file_priv = NULL;
+ if (request->file_priv
[Bug 34972] [nouveau] Screen blinking on dualhead
https://bugs.freedesktop.org/show_bug.cgi?id=34972 --- Comment #1 from Nikolay Rysev 2011-03-17 05:54:36 PDT --- 2.6.38 — bug still present -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Oops at i915_gem_retire_requests_ring
On Thu, 17 Mar 2011 09:39:07 -0300, Herton Ronaldo Krzesinski
wrote:
> I don't know if it's the most correct fix, but perhaps the simple fix
> is needed in the code. It's against latest Linus tree. We may have an
> already removed client_list, or we didn't add any item to client_list
> (file_priv NULL in i915_add_request)
>
> Signed-off-by: Herton Ronaldo Krzesinski
> ---
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 36e66cc..6077c0d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1749,8 +1749,10 @@ i915_gem_request_remove_from_client(struct
> drm_i915_gem_request *request)
> return;
>
> spin_lock(&file_priv->mm.lock);
> - list_del(&request->client_list);
> - request->file_priv = NULL;
> + if (request->file_priv) {
> + list_del(&request->client_list);
> + request->file_priv = NULL;
> + }
> spin_unlock(&file_priv->mm.lock);
> }
This is the single chunk required. I had thought that the actual
insertion/deletion was serialised under the struct mutex and the intention
of the spinlock was to protect the unlocked list traversal during
throttling. However, I missed that i915_gem_release() is also called
without struct mutex and so we do need the double check for
i915_gem_request_remove_from_client().
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Oops at i915_gem_retire_requests_ring
On Thu, Mar 17, 2011 at 01:46:34PM +, Chris Wilson wrote:
> On Thu, 17 Mar 2011 09:39:07 -0300, Herton Ronaldo Krzesinski
> wrote:
> > I don't know if it's the most correct fix, but perhaps the simple fix
> > is needed in the code. It's against latest Linus tree. We may have an
> > already removed client_list, or we didn't add any item to client_list
> > (file_priv NULL in i915_add_request)
> >
> > Signed-off-by: Herton Ronaldo Krzesinski
> > ---
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 36e66cc..6077c0d 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1749,8 +1749,10 @@ i915_gem_request_remove_from_client(struct
> > drm_i915_gem_request *request)
> > return;
> >
> > spin_lock(&file_priv->mm.lock);
> > - list_del(&request->client_list);
> > - request->file_priv = NULL;
> > + if (request->file_priv) {
> > + list_del(&request->client_list);
> > + request->file_priv = NULL;
> > + }
> > spin_unlock(&file_priv->mm.lock);
> > }
>
> This is the single chunk required. I had thought that the actual
> insertion/deletion was serialised under the struct mutex and the intention
> of the spinlock was to protect the unlocked list traversal during
> throttling. However, I missed that i915_gem_release() is also called
> without struct mutex and so we do need the double check for
> i915_gem_request_remove_from_client().
Ok. I just still have one doubt though, if in i915_add_request
file/file_priv is NULL, wouldn't be possible to have an oops also in
i915_gem_release without the check? As in this case,
request->client_list wouldn't have mm.request_list added to it, and if
an error occurs and i915_reset is called, which ends up calling
i915_gem_release, we would try to do a list_del on request->client_list
without items.
If the check really isn't needed in i915_gem_release, then please
consider this patch:
From: Herton Ronaldo Krzesinski
Avoid oops in i915_gem_request_remove_from_client client_list removal
When i915_gem_retire_requests_ring calls i915_gem_request_remove_from_client,
the client_list for that request may already be removed in i915_gem_release.
So we may call twice list_del(&request->client_list), resulting in an
oops like this report:
[126167.230394] BUG: unable to handle kernel paging request at 00100104
[126167.230699] IP: [] i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.231042] *pdpt = 314c1001 *pde =
[126167.231314] Oops: 0002 [#1] SMP
[126167.231471] last sysfs file:
/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now
[126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs
zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs
exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt
vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant
snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi
snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev
iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper
snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid
sky2 sdhci_pci ahci sdhci libahci
[126167.232018]
[126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae
#34-Ubuntu Gateway MC7833U /
[126167.232018] EIP: 0060:[] EFLAGS: 00213246 CPU: 0
[126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 0040 EDX: 00100100
[126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0
[126167.232018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500
task.ti=ef4d6000)
[126167.232018] Stack:
[126167.232018] f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b
0058bd85
[126167.232018] f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc
f6b3a040
[126167.232018] f1522cc0 00db f1ba6500 ffa1 0001
f1a29214
[126167.232018] Call Trace:
Unfortunately the call trace reported was cut, but looking at debug
symbols the crash is at __list_del, when probably list_del is called
twice on the same request->client_list, as the dereferenced value is
LIST_POISON1 + 4, and by looking more at the debug symbols before
list_del call it should have being called by
i915_gem_request_remove_from_client
And as I can see in the code, it seems we indeed have the possibility
to remove a request->client_list twice, which would cause the above,
because we do list_del(&request->client_list) on both
i915_gem_request_remove_from_client and i915_gem_release
As Chris Wilson pointed out, it's indeed the case:
"(...) I had thought that the actual insertion/deletion was serialised
under the struct mutex and the int
Re: Oops at i915_gem_retire_requests_ring
On Thu, 17 Mar 2011 13:54:45 -0300, Herton Ronaldo Krzesinski wrote: > On Thu, Mar 17, 2011 at 01:46:34PM +, Chris Wilson wrote: > > This is the single chunk required. I had thought that the actual > > insertion/deletion was serialised under the struct mutex and the intention > > of the spinlock was to protect the unlocked list traversal during > > throttling. However, I missed that i915_gem_release() is also called > > without struct mutex and so we do need the double check for > > i915_gem_request_remove_from_client(). > > Ok. I just still have one doubt though, if in i915_add_request > file/file_priv is NULL, wouldn't be possible to have an oops also in > i915_gem_release without the check? As in this case, > request->client_list wouldn't have mm.request_list added to it, and if > an error occurs and i915_reset is called, which ends up calling > i915_gem_release, we would try to do a list_del on request->client_list > without items. If the file_priv is NULL, then the request is not added to the client mm.request_list and so it is not seen during i915_gem_release. The list is file_priv->mm.request_list, the nodes within that are request->client_list. > If the check really isn't needed in i915_gem_release, then please > consider this patch: Done, thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35396] New: [mesa] black window when running glxgears after resume from suspend on ATI Radeon X800 SE
https://bugs.freedesktop.org/show_bug.cgi?id=35396 Summary: [mesa] black window when running glxgears after resume from suspend on ATI Radeon X800 SE Product: Mesa Version: 7.10 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: jfrie...@hotmail.com Description of problem: When running glxgears after resume from suspend on a system equipped with an ATI Radeon X800 SE (R430), all I get is a black window. Moreover, it does not react to keyboard input, namely pressing . The application windows just stays there, even after pressing in the terminal window from which it had been launched. Version-Release number of selected component (if applicable): mesa-7.10-0.29.fc15 How reproducible: Always. Steps to Reproduce: 1. Run glxgears. 2. Suspend and resume. 3. Run glxgears. Actual results: Application window is black and does not respond to keyboard input. Expected results: Application window shows turning gears. Additional info: * Vendor bug reference https://bugzilla.redhat.com/show_bug.cgi?id=643700 * This issue is -critical- for GNOME3 which is using a GL based desktop environment. In this case, the desktop is -frozen- after resume from suspend making the system unusable. Only the mouse pointer can be moved. The system needs to be rebooted or switched to a non-accelerated window manager like metacity. * Upgrading to mesa-7.11-0.20110315.0.fc16 has no effect. * Issue is absent for driver R300 TCL DRI2. * Installed packages include: - kernel-2.6.38-1.fc15 - libdrm-2.4.24-1.fc15 - xorg-x11-drv-ati-6.14.0-7.20110316gitcdfc007ec.fc15 - xorg-x11-server-1.10.0-4.fc15 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix use-after-free in drm_gem_vm_close()
As we may release the last reference, we need to store the device in a
local variable in order to unlock afterwards.
[ 60.140768] BUG: unable to handle kernel paging request at 6b6b6b9f
[ 60.140973] IP: [] __mutex_unlock_slowpath+0x5a/0x111
[ 60.141014] *pdpt = 24a54001 *pde =
[ 60.141014] Oops: 0002 [#1] PREEMPT SMP
[ 60.141014] last sysfs file:
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/voltage_now
[ 60.141014] Modules linked in: uvcvideo ath9k pegasus ath9k_common ath9k_hw
hid_egalax ath3k joydev asus_laptop sparse_keymap battery input_polldev
[ 60.141014]
[ 60.141014] Pid: 771, comm: meego-ux-daemon Not tainted 2.6.37.2-7.1 #1
EXOPC EXOPG06411/EXOPG06411
[ 60.141014] EIP: 0060:[] EFLAGS: 00010046 CPU: 0
[ 60.141014] EIP is at __mutex_unlock_slowpath+0x5a/0x111
[ 60.141014] EAX: 0100 EBX: 6b6b6b9b ECX: e9b4a1b0 EDX: e4a4e580
[ 60.141014] ESI: db162558 EDI: 0246 EBP: e480be50 ESP: e480be44
[ 60.141014] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
[ 60.141014] Process meego-ux-daemon (pid: 771, ti=e480a000 task=e9b4a1b0
task.ti=e480a000)
[ 60.141014] Stack:
[ 60.141014] e4a4e580 db162558 f5a2f838 e480be58 c1536dd0 e480be68 c125ab1b
db162558
[ 60.141014] db1624e0 e480be78 c10ba071 db162558 f760241c e480be94 c10bb0bc
000155fe
[ 60.141014] f760241c f5a2f838 f5a2f8c8 e480bea4 c1037c24
f5a2f838
[ 60.141014] Call Trace:
[ 60.141014] [] ? mutex_unlock+0x8/0xa
[ 60.141014] [] ? drm_gem_vm_close+0x39/0x3d
[ 60.141014] [] ? remove_vma+0x2d/0x58
[ 60.141014] [] ? exit_mmap+0x126/0x13f
[ 60.141014] [] ? mmput+0x37/0x9a
[ 60.141014] [] ? exec_mmap+0x178/0x19c
[ 60.141014] [] ? _raw_spin_unlock+0x1d/0x36
[ 60.141014] [] ? flush_old_exec+0x42/0x75
[ 60.141014] [] ? load_elf_binary+0x32a/0x922
[ 60.141014] [] ? search_binary_handler+0x200/0x2ea
[ 60.141014] [] ? search_binary_handler+0x159/0x2ea
[ 60.141014] [] ? load_elf_binary+0x0/0x922
[ 60.141014] [] ? do_execve+0x1ff/0x2e6
[ 60.141014] [] ? sys_execve+0x2d/0x55
[ 60.141014] [] ? ptregs_execve+0x12/0x18
[ 60.141014] [] ? sysenter_do_call+0x12/0x3c
[ 60.141014] [] ? init_centaur+0x9c/0x1ba
[ 60.141014] Code: c1 00 75 0f ba 38 01 00 00 b8 8c 3a 6c c1 e8 cc 2e b0 ff
9c 58 8d 74 26 00 89 c7 fa 90 8d 74 26 00 e8 d2 b4 b2 ff b8 00 01 00 00 66
0f c1 43 04 38 e0 74 07 f3 90 8a 43 04 eb f5 83 3d 64 ef
[ 60.141014] EIP: [] __mutex_unlock_slowpath+0x5a/0x111 SS:ESP
0068:e480be44
[ 60.141014] CR2: 6b6b6b9f
Reported-by: Rusty Lynch
Signed-off-by: Chris Wilson
Cc: sta...@kernel.org
---
drivers/gpu/drm/drm_gem.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 57ce27c..74e4ff5 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -499,11 +499,12 @@ EXPORT_SYMBOL(drm_gem_vm_open);
void drm_gem_vm_close(struct vm_area_struct *vma)
{
struct drm_gem_object *obj = vma->vm_private_data;
+ struct drm_device *dev = obj->dev;
- mutex_lock(&obj->dev->struct_mutex);
+ mutex_lock(&dev->struct_mutex);
drm_vm_close_locked(vma);
drm_gem_object_unreference(obj);
- mutex_unlock(&obj->dev->struct_mutex);
+ mutex_unlock(&dev->struct_mutex);
}
EXPORT_SYMBOL(drm_gem_vm_close);
--
1.7.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm next tree
Hi Linus, since I see drm named in two other pull threads (staging + bkl) I suppose I should send my pull req. Highlights: core: drop i830 driver and BKL, add support to drm core to allow USB drm drivers, generic unaccelerated buffer create/map fns for simple fbdev applications (like plymouth), generic drm capabilities ioctl. ttm: add support for Xen Dom0 radeon: cayman GPU support (fw is in linux-firmware), r600 tiling + predication support nouveau: pageflipping, Z compression i915: big 855 fix, lots of output setup refactoring, lots of misc fixes. Dave. The following changes since commit 5359533801e3dd3abca5b7d3d985b0b33fd9fe8b: drm/radeon: fix problem with changing active VRAM size. (v2) (2011-03-14 12:51:04 +1000) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-core-next Alex Deucher (17): drm/radeon/kms: add cayman chip family drm/radeon/kms: add ucode loader for cayman drm/radeon/kms: add gpu_init function for cayman drm/radeon/kms: add support for cayman gart setup drm/radeon/kms: add support for CP setup on cayman asics drm/radeon/kms: add support for cayman irqs drm/radeon/kms: add cayman asic reset support drm/radeon/kms/cayman: add asic init/startup/fini/suspend/resume functions drm/radeon/kms: add cayman safe regs drm/radeon/kms: add radeon_asic entry for cayman drm/radeon/kms: add cayman CS check support drm/radeon/kms: additional default context regs for cayman drm/radeon/kms/cayman: always set certain VGT regs at CP init drm/radeon/kms: cayman/evergreen cs checker updates drm/radeon/kms: add cayman pci ids drm/radeon/kms: allow max clock of 340 Mhz on hdmi 1.3+ drm/radeon/kms: fix typo in atom overscan setup Alexander Lam (1): drm/i915: allow 945 to control self refresh (CxSR) automatically Arnd Bergmann (2): drm: remove i830 driver drm/i810: remove the BKL Ben Skeggs (46): drm/ttm: call driver move_notify() when doing system->tt bo moves Merge remote-tracking branch 'airlied/drm-core-next' into drm-nouveau-next drm/nouveau: move + rename some stuff in nouveau_sgdma.c drm/nouveau: introduce new gart type, and name _SGDMA more appropriately drm/nv40: implement support for on-chip PCIEGART drm/nv40: support for 39-bit dma addresses on native PCIE chipsets drm/nv84: switch to new-style semaphores drm/nvc0/pfifo: semi-handle a couple more irqs drm/nvc0: implement semaphores for inter-channel sync drm/nouveau: silence some compiler warnings drm/nv50: 0x50 needs semaphore yields too drm/nv84: use vm offsets for semaphores drm/nv50: drop explicit yields in favour of smaller PFIFO timeslice drm/nv50-nvc0: move non-sharable display state into private structure drm/nv50-nvc0: rename disp->evo to disp->master drm/nv50-nvc0: disp channels have fixed purposes, don't "allocate" them drm/nv50-nvc0: fix ramht entries for multiple evo channels drm/nv50-nvc0: tidy evo init failure paths drm/nv50-nvc0: include nv50_display in evo debugging drm/nouveau: make vbios parser runnable from an atomic context drm/nv50-nvc0: switch to tasklet for display isr bh drm/nv50-nvc0: request and wait on notification of modeset completion drm/nv50-nvc0: tidy evo object creation some more drm/nv50-nvc0: precalculate some fb state when creating them drm/nv50-nvc0: initialise display sync channels drm/nv50-nvc0: activate/update ds channel's framebuffer on modesets drm/nv50: enable page flipping drm/nvc0: support for sw methods + enable page flipping drm/nouveau/vbios: parse more gpio tag bits from connector table drm/nouveau: remove no_vm/mappable flags from nouveau_bo drm/nv50: simplify bo moves now that they're all through the vm drm/nouveau: pass domain rather than ttm flags to gem_new() drm/nv50-nvc0: restrict memtype to those specified at creation time drm/nv50-nvc0: move vm bind/unbind to move_notify hook drm/nv50-nvc0: unmap buffers from the vm when they're evicted drm/nvc0: allow creation of buffers with any non-compressed memtype drm/nouveau: rename nouveau_vram to nouveau_mem drm/nv50-nvc0: delay GART binding until move_notify time drm/nv50: support for compression drm/nv50: flesh out ZCULL init and match nvidia on later chipsets drm/core: add ioctl to query device/driver capabilities drm/nvc0: remove vm hack forcing large/small pages to not share a PDE drm/nouveau: add nouveau_enum_find() util function drm/nv50: decode vm faults some more drm/nv50: check for vm traps on every gr irq drm/nv40: attempt to reserve just enough vram for all 32 channels Benjamin Franzke (1): drm/nouveau: Fix pageflip event Bryan Freed (2): drm/i915: Honou
[Bug 34709] with r300 (rv530) kms loaded cannot suspend kernel 2.6.37+ with uswsusp
https://bugs.freedesktop.org/show_bug.cgi?id=34709 --- Comment #5 from Michal Suchanek 2011-03-17 02:31:49 PDT --- hmm, so it does not happen on rv515gl hopefully can bisect with the rv530 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Oops at i915_gem_retire_requests_ring
(please CC me if replying)
Hi,
recently I saw a report about an oops in 2.6.38-rc7 in i915, attached at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/733780
Unfortunately the oops is cut (without call trace):
[126167.230394] BUG: unable to handle kernel paging request at 00100104
[126167.230699] IP: [] i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.231042] *pdpt = 314c1001 *pde =
[126167.231314] Oops: 0002 [#1] SMP
[126167.231471] last sysfs file:
/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now
[126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs
zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs
exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt
vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant
snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi
snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev
iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper
snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid
sky2 sdhci_pci ahci sdhci libahci
[126167.232018]
[126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae
#34-Ubuntu Gateway MC7833U /
[126167.232018] EIP: 0060:[] EFLAGS: 00213246 CPU: 0
[126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 0040 EDX: 00100100
[126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0
[126167.232018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500
task.ti=ef4d6000)
[126167.232018] Stack:
[126167.232018] f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b
0058bd85
[126167.232018] f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc
f6b3a040
[126167.232018] f1522cc0 00db f1ba6500 ffa1 0001
f1a29214
[126167.232018] Call Trace:
But we already can see some things. After downloading the debug symbols
for kernel above [1] and extracting the files (dpkg-deb -x), setting up
the source files, in gdb we can get this:
(gdb) l *(i915_gem_retire_requests_ring+0xd4)
0x17e74 is in i915_gem_retire_requests_ring
(/build/buildd/linux-2.6.38/include/linux/list.h:88).
warning: Source file is more recent than executable.
83 * This is only for internal list manipulation where we know
84 * the prev/next entries already!
85 */
86 static inline void __list_del(struct list_head * prev, struct list_head
* next)
87 {
88 next->prev = prev;
89 prev->next = next;
90 }
91
92 /**
So the oops is in a list_del call. And looking at the EDX and
dereferenced value, it's LIST_POISON1 + 4, as
p &((struct list_head *)0)->prev == 0x4
So indeed the oops is happening on __list_del at next->prev = prev,
called from i915_gem_retire_requests_ring, probably from the
i915_gem_request_remove_from_client call, going back in the code for
example:
(gdb) l *(i915_gem_retire_requests_ring+0xc6)
0x17e66 is in i915_gem_retire_requests_ring
(/build/buildd/linux-2.6.38/drivers/gpu/drm/i915/i915_gem.c:1748).
warning: Source file is more recent than executable.
1743static inline void
1744i915_gem_request_remove_from_client(struct drm_i915_gem_request
*request)
1745{
1746struct drm_i915_file_private *file_priv = request->file_priv;
1747
1748if (!file_priv)
1749return;
1750
1751spin_lock(&file_priv->mm.lock);
1752list_del(&request->client_list);
But without the call trace no way to know for certain. Anyway the oops
with LIST_POISON1 means we are trying to delete from the list an already
deleted item. As I can see in the code (I'm not used to that code, so
may be there is something I don't see), it seems we indeed have the
possibility to remove an request->client_list twice, which would cause
the above, we do list_del(&request->client_list) on both
i915_gem_request_remove_from_client and i915_gem_release
I don't know if it's the most correct fix, but perhaps the simple fix
is needed in the code. It's against latest Linus tree. We may have an
already removed client_list, or we didn't add any item to client_list
(file_priv NULL in i915_add_request)
Signed-off-by: Herton Ronaldo Krzesinski
---
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 36e66cc..6077c0d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1749,8 +1749,10 @@ i915_gem_request_remove_from_client(struct
drm_i915_gem_request *request)
return;
spin_lock(&file_priv->mm.lock);
- list_del(&request->client_list);
- request->file_priv = NULL;
+ if (request->file_priv)
[Bug 34972] [nouveau] Screen blinking on dualhead
https://bugs.freedesktop.org/show_bug.cgi?id=34972 --- Comment #1 from Nikolay Rysev 2011-03-17 05:54:36 PDT --- 2.6.38 ? bug still present -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Oops at i915_gem_retire_requests_ring
On Thu, 17 Mar 2011 09:39:07 -0300, Herton Ronaldo Krzesinski
wrote:
> I don't know if it's the most correct fix, but perhaps the simple fix
> is needed in the code. It's against latest Linus tree. We may have an
> already removed client_list, or we didn't add any item to client_list
> (file_priv NULL in i915_add_request)
>
> Signed-off-by: Herton Ronaldo Krzesinski
> ---
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 36e66cc..6077c0d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1749,8 +1749,10 @@ i915_gem_request_remove_from_client(struct
> drm_i915_gem_request *request)
> return;
>
> spin_lock(&file_priv->mm.lock);
> - list_del(&request->client_list);
> - request->file_priv = NULL;
> + if (request->file_priv) {
> + list_del(&request->client_list);
> + request->file_priv = NULL;
> + }
> spin_unlock(&file_priv->mm.lock);
> }
This is the single chunk required. I had thought that the actual
insertion/deletion was serialised under the struct mutex and the intention
of the spinlock was to protect the unlocked list traversal during
throttling. However, I missed that i915_gem_release() is also called
without struct mutex and so we do need the double check for
i915_gem_request_remove_from_client().
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Oops at i915_gem_retire_requests_ring
On Thu, Mar 17, 2011 at 01:46:34PM +, Chris Wilson wrote:
> On Thu, 17 Mar 2011 09:39:07 -0300, Herton Ronaldo Krzesinski
> wrote:
> > I don't know if it's the most correct fix, but perhaps the simple fix
> > is needed in the code. It's against latest Linus tree. We may have an
> > already removed client_list, or we didn't add any item to client_list
> > (file_priv NULL in i915_add_request)
> >
> > Signed-off-by: Herton Ronaldo Krzesinski > canonical.com>
> > ---
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 36e66cc..6077c0d 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1749,8 +1749,10 @@ i915_gem_request_remove_from_client(struct
> > drm_i915_gem_request *request)
> > return;
> >
> > spin_lock(&file_priv->mm.lock);
> > - list_del(&request->client_list);
> > - request->file_priv = NULL;
> > + if (request->file_priv) {
> > + list_del(&request->client_list);
> > + request->file_priv = NULL;
> > + }
> > spin_unlock(&file_priv->mm.lock);
> > }
>
> This is the single chunk required. I had thought that the actual
> insertion/deletion was serialised under the struct mutex and the intention
> of the spinlock was to protect the unlocked list traversal during
> throttling. However, I missed that i915_gem_release() is also called
> without struct mutex and so we do need the double check for
> i915_gem_request_remove_from_client().
Ok. I just still have one doubt though, if in i915_add_request
file/file_priv is NULL, wouldn't be possible to have an oops also in
i915_gem_release without the check? As in this case,
request->client_list wouldn't have mm.request_list added to it, and if
an error occurs and i915_reset is called, which ends up calling
i915_gem_release, we would try to do a list_del on request->client_list
without items.
If the check really isn't needed in i915_gem_release, then please
consider this patch:
From: Herton Ronaldo Krzesinski
Avoid oops in i915_gem_request_remove_from_client client_list removal
When i915_gem_retire_requests_ring calls i915_gem_request_remove_from_client,
the client_list for that request may already be removed in i915_gem_release.
So we may call twice list_del(&request->client_list), resulting in an
oops like this report:
[126167.230394] BUG: unable to handle kernel paging request at 00100104
[126167.230699] IP: [] i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.231042] *pdpt = 314c1001 *pde =
[126167.231314] Oops: 0002 [#1] SMP
[126167.231471] last sysfs file:
/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now
[126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs
zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs
exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt
vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant
snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi
snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev
iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper
snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid
sky2 sdhci_pci ahci sdhci libahci
[126167.232018]
[126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae
#34-Ubuntu Gateway MC7833U /
[126167.232018] EIP: 0060:[] EFLAGS: 00213246 CPU: 0
[126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 0040 EDX: 00100100
[126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0
[126167.232018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500
task.ti=ef4d6000)
[126167.232018] Stack:
[126167.232018] f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b
0058bd85
[126167.232018] f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc
f6b3a040
[126167.232018] f1522cc0 00db f1ba6500 ffa1 0001
f1a29214
[126167.232018] Call Trace:
Unfortunately the call trace reported was cut, but looking at debug
symbols the crash is at __list_del, when probably list_del is called
twice on the same request->client_list, as the dereferenced value is
LIST_POISON1 + 4, and by looking more at the debug symbols before
list_del call it should have being called by
i915_gem_request_remove_from_client
And as I can see in the code, it seems we indeed have the possibility
to remove a request->client_list twice, which would cause the above,
because we do list_del(&request->client_list) on both
i915_gem_request_remove_from_client and i915_gem_release
As Chris Wilson pointed out, it's indeed the case:
"(...) I had thought that the actual insertion/deletion was serialised
under the struct
Oops at i915_gem_retire_requests_ring
On Thu, 17 Mar 2011 13:54:45 -0300, Herton Ronaldo Krzesinski wrote: > On Thu, Mar 17, 2011 at 01:46:34PM +, Chris Wilson wrote: > > This is the single chunk required. I had thought that the actual > > insertion/deletion was serialised under the struct mutex and the intention > > of the spinlock was to protect the unlocked list traversal during > > throttling. However, I missed that i915_gem_release() is also called > > without struct mutex and so we do need the double check for > > i915_gem_request_remove_from_client(). > > Ok. I just still have one doubt though, if in i915_add_request > file/file_priv is NULL, wouldn't be possible to have an oops also in > i915_gem_release without the check? As in this case, > request->client_list wouldn't have mm.request_list added to it, and if > an error occurs and i915_reset is called, which ends up calling > i915_gem_release, we would try to do a list_del on request->client_list > without items. If the file_priv is NULL, then the request is not added to the client mm.request_list and so it is not seen during i915_gem_release. The list is file_priv->mm.request_list, the nodes within that are request->client_list. > If the check really isn't needed in i915_gem_release, then please > consider this patch: Done, thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 35396] New: [mesa] black window when running glxgears after resume from suspend on ATI Radeon X800 SE
https://bugs.freedesktop.org/show_bug.cgi?id=35396 Summary: [mesa] black window when running glxgears after resume from suspend on ATI Radeon X800 SE Product: Mesa Version: 7.10 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: jfrieben at hotmail.com Description of problem: When running glxgears after resume from suspend on a system equipped with an ATI Radeon X800 SE (R430), all I get is a black window. Moreover, it does not react to keyboard input, namely pressing . The application windows just stays there, even after pressing in the terminal window from which it had been launched. Version-Release number of selected component (if applicable): mesa-7.10-0.29.fc15 How reproducible: Always. Steps to Reproduce: 1. Run glxgears. 2. Suspend and resume. 3. Run glxgears. Actual results: Application window is black and does not respond to keyboard input. Expected results: Application window shows turning gears. Additional info: * Vendor bug reference https://bugzilla.redhat.com/show_bug.cgi?id=643700 * This issue is -critical- for GNOME3 which is using a GL based desktop environment. In this case, the desktop is -frozen- after resume from suspend making the system unusable. Only the mouse pointer can be moved. The system needs to be rebooted or switched to a non-accelerated window manager like metacity. * Upgrading to mesa-7.11-0.20110315.0.fc16 has no effect. * Issue is absent for driver R300 TCL DRI2. * Installed packages include: - kernel-2.6.38-1.fc15 - libdrm-2.4.24-1.fc15 - xorg-x11-drv-ati-6.14.0-7.20110316gitcdfc007ec.fc15 - xorg-x11-server-1.10.0-4.fc15 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm: Fix use-after-free in drm_gem_vm_close()
As we may release the last reference, we need to store the device in a
local variable in order to unlock afterwards.
[ 60.140768] BUG: unable to handle kernel paging request at 6b6b6b9f
[ 60.140973] IP: [] __mutex_unlock_slowpath+0x5a/0x111
[ 60.141014] *pdpt = 24a54001 *pde =
[ 60.141014] Oops: 0002 [#1] PREEMPT SMP
[ 60.141014] last sysfs file:
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/voltage_now
[ 60.141014] Modules linked in: uvcvideo ath9k pegasus ath9k_common ath9k_hw
hid_egalax ath3k joydev asus_laptop sparse_keymap battery input_polldev
[ 60.141014]
[ 60.141014] Pid: 771, comm: meego-ux-daemon Not tainted 2.6.37.2-7.1 #1
EXOPC EXOPG06411/EXOPG06411
[ 60.141014] EIP: 0060:[] EFLAGS: 00010046 CPU: 0
[ 60.141014] EIP is at __mutex_unlock_slowpath+0x5a/0x111
[ 60.141014] EAX: 0100 EBX: 6b6b6b9b ECX: e9b4a1b0 EDX: e4a4e580
[ 60.141014] ESI: db162558 EDI: 0246 EBP: e480be50 ESP: e480be44
[ 60.141014] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
[ 60.141014] Process meego-ux-daemon (pid: 771, ti=e480a000 task=e9b4a1b0
task.ti=e480a000)
[ 60.141014] Stack:
[ 60.141014] e4a4e580 db162558 f5a2f838 e480be58 c1536dd0 e480be68 c125ab1b
db162558
[ 60.141014] db1624e0 e480be78 c10ba071 db162558 f760241c e480be94 c10bb0bc
000155fe
[ 60.141014] f760241c f5a2f838 f5a2f8c8 e480bea4 c1037c24
f5a2f838
[ 60.141014] Call Trace:
[ 60.141014] [] ? mutex_unlock+0x8/0xa
[ 60.141014] [] ? drm_gem_vm_close+0x39/0x3d
[ 60.141014] [] ? remove_vma+0x2d/0x58
[ 60.141014] [] ? exit_mmap+0x126/0x13f
[ 60.141014] [] ? mmput+0x37/0x9a
[ 60.141014] [] ? exec_mmap+0x178/0x19c
[ 60.141014] [] ? _raw_spin_unlock+0x1d/0x36
[ 60.141014] [] ? flush_old_exec+0x42/0x75
[ 60.141014] [] ? load_elf_binary+0x32a/0x922
[ 60.141014] [] ? search_binary_handler+0x200/0x2ea
[ 60.141014] [] ? search_binary_handler+0x159/0x2ea
[ 60.141014] [] ? load_elf_binary+0x0/0x922
[ 60.141014] [] ? do_execve+0x1ff/0x2e6
[ 60.141014] [] ? sys_execve+0x2d/0x55
[ 60.141014] [] ? ptregs_execve+0x12/0x18
[ 60.141014] [] ? sysenter_do_call+0x12/0x3c
[ 60.141014] [] ? init_centaur+0x9c/0x1ba
[ 60.141014] Code: c1 00 75 0f ba 38 01 00 00 b8 8c 3a 6c c1 e8 cc 2e b0 ff
9c 58 8d 74 26 00 89 c7 fa 90 8d 74 26 00 e8 d2 b4 b2 ff b8 00 01 00 00 66
0f c1 43 04 38 e0 74 07 f3 90 8a 43 04 eb f5 83 3d 64 ef
[ 60.141014] EIP: [] __mutex_unlock_slowpath+0x5a/0x111 SS:ESP
0068:e480be44
[ 60.141014] CR2: 6b6b6b9f
Reported-by: Rusty Lynch
Signed-off-by: Chris Wilson
Cc: stable at kernel.org
---
drivers/gpu/drm/drm_gem.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 57ce27c..74e4ff5 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -499,11 +499,12 @@ EXPORT_SYMBOL(drm_gem_vm_open);
void drm_gem_vm_close(struct vm_area_struct *vma)
{
struct drm_gem_object *obj = vma->vm_private_data;
+ struct drm_device *dev = obj->dev;
- mutex_lock(&obj->dev->struct_mutex);
+ mutex_lock(&dev->struct_mutex);
drm_vm_close_locked(vma);
drm_gem_object_unreference(obj);
- mutex_unlock(&obj->dev->struct_mutex);
+ mutex_unlock(&dev->struct_mutex);
}
EXPORT_SYMBOL(drm_gem_vm_close);
--
1.7.2.3
