In v3.3, the gma500 drm driver moved from staging to drm group by
Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
brightness well and don't need gma500 stub driver anymore.
So, my plan is remove gma500 stub driver at Dec. 2012.
Signed-off-by: Lee, Chun-Yi <jlee(a)suse.com>
---
Documentation/feature-removal-schedule.txt | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-…
[View More]removal-schedule.txt
index a0ffac0..219d6f1 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -524,3 +524,14 @@ Files: arch/arm/mach-at91/at91cap9.c
Why: The code is not actively maintained and platforms are now hard to find.
Who: Nicolas Ferre <nicolas.ferre(a)atmel.com>
Jean-Christophe PLAGNIOL-VILLARD <plagnioj(a)jcrosoft.com>
+
+----------------------------
+
+What: Intel GMA500 Stub Driver
+When: December 2012
+Why: In v3.3, the gma500 drm driver moved from staging to drm group by
+ Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
+ brightness well and don't need gma500 stub driver anymore.
+
+ So, my plan is remove gma500 stub driver at Dec. 2012.
+Who: Lee, Chun-Yi <jlee(a)novell.com>
--
1.6.0.2
[View Less]
> If the API was to also be used for synchronization it would have to
> include an atomic "prepare multiple" ioctl which blocked until all
> the buffers listed by the application were available. In the same
Too slow already. You are now serializing stuff while what we want to do
really is
nobody_else_gets_buffers_next([list])
on available(buffer)
dispatch_work(buffer)
so that you can maximise parallelism without allowing deadlocks. If
you've got a high memory bandwith and 8+ …
[View More]cores the 'stop everything'
model isn't great.
> This might be a good argument for keeping synchronization and cache
> maintenance separate, though even ignoring synchronization I would
> think being able to issue cache maintenance operations for multiple
> buffers in a single ioctl might present some small efficiency gains.
> However as Rob points out, CPU access is already in slow/legacy
> territory.
Dangerous assumption. I do think they should be separate. For one it
makes the case of synchronization needed but hardware cache management
much easier to split cleanly. Assuming CPU access is slow/legacy reflects
a certain model of relatively slow CPU and accelerators where falling off
the acceleration path is bad. On a higher end processor falling off the
acceleration path isn't a performance matter so much as a power concern.
> KDS we differentiated jobs which needed "exclusive access" to a
> buffer and jobs which needed "shared access" to a buffer. Multiple
> jobs could access a buffer at the same time if those jobs all
Makes sense as it's a reader/writer lock and it reflects MESI/MOESI
caching and cache policy in some hardware/software assists.
> display controller will be reading the front buffer, but the GPU
> might also need to read that front buffer. So perhaps adding
> "read-only" & "read-write" access flags to prepare could also be
> interpreted as shared & exclusive accesses, if we went down this
> route for synchronization that is. :-)
mmap includes read/write info so probably using that works out. It also
means that you have the stuff mapped in a way that will bus error or
segfault anyone who goofs rather than give them the usual 'deep
weirdness' behaviour you get with mishandling of caching bits.
Alan
[View Less]
Guys,
I don't know if these kinds of things have been forwarded to you, but
there's apparently been several things like this going on - with the
finger pointing to the i915 driver apparently clearing random memory.
Often the end result seems to be list corruption or a NULL pointer
dereference in the filesystem layer.
Linus
---------- Forwarded message ----------
From: Jiri Kosina <jkosina(a)suse.cz>
Date: Fri, Mar 16, 2012 at 8:25 AM
Subject: Re: Oops in …
[View More]ext3_block_to_path.isra.40+0x26/0x11b
To: George Spelvin <linux(a)horizon.com>
Cc: jack(a)suse.cz, linux-ext4(a)vger.kernel.org,
linux-kernel(a)vger.kernel.org, torvalds(a)linux-foundation.org
On Fri, 16 Mar 2012, George Spelvin wrote:
> > I am not aware of anything, but I have a question -- George, did the
> > machine get suspended/resumed before this happened?
>
> I'm pretty sure it didn't. It's a desktop machine, and I don't ever
> suspend it. It had been up for a while, and /sys/power/state exists, and
> *maybe* I played with it sometime since boot, but the backup runs nightly
> and I *definitely* did not suspend it the day (or even several days)
> before the oops.
>
> (I tried to preserve the machine state, but processes started getting
> stuck in the kernel a few hours after the report, so I had to reboot it.)
>
> Jan Kara asked:
> > And by any chance, do you use i915 driver? Because that one seems to
> > cause corruption - see: https://lkml.org/lkml/2012/3/9/217. I believe
> > Jiri's corruption is likely caused by that...
>
> Yes! lspci -nn and abbreviated .config attached. But, as mentioned, the machine
> hasn't been suspended...
So it might be the culprit. As the reason of the corruption is not yet
understood, it might be that suspend/resume cycle is not necessary
pre-requisite for this to trigger, it might just make it more likely.
And the corruption is observed to be indeed several writes of 0x00000000,
so it could easily lead to null pointer dereferences all over the place.
Are you able to reproduce the problem if you turn kernel modesetting off?
--
Jiri Kosina
SUSE Labs
[View Less]
> > dma-buf file descriptor. Userspace access to the buffer should be
> > bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to
> > give the exporting driver a chance to deal with cache synchronization
> > and such for cached userspace mappings without resorting to page
There should be flags indicating if this is necessary. We don't want extra
syscalls on hardware that doesn't need it. The other question is what
info is needed as you may only want to poke …
[View More]a few pages out of cache and
the prepare/finish on its own gives no info.
> E.g. If another device was writing to the buffer, the prepare ioctl
> could block until that device had finished accessing that buffer.
How do you avoid deadlocks on this ? We need very clear ways to ensure
things always complete in some form given multiple buffer
owner/requestors and the fact this API has no "prepare-multiple-buffers"
support.
Alan
[View Less]
From: Julia Lawall <Julia.Lawall(a)lip6.fr>
The function radeon_cs_parser_init is only called from two places, in
drivers/gpu/drm/radeon/radeon_cs.c and drivers/gpu/drm/radeon/r600_cs.c.
In each case, if the call fails another function is called that frees all
of the kdata and dpage information in the chunks array. So this
information should not be freed in radeon_cs_parser_init as well.
Signed-off-by: Julia Lawall <Julia.Lawall(a)lip6.fr>
---
drivers/gpu/drm/radeon/radeon_cs.c …
[View More]| 16 ++--------------
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c
index 9b4124e..d9d9f5a 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -243,20 +243,11 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data)
if ((p->cs_flags & RADEON_CS_USE_VM) &&
!p->rdev->vm_manager.enabled) {
DRM_ERROR("VM not active on asic!\n");
- if (p->chunk_relocs_idx != -1)
- kfree(p->chunks[p->chunk_relocs_idx].kdata);
- if (p->chunk_flags_idx != -1)
- kfree(p->chunks[p->chunk_flags_idx].kdata);
return -EINVAL;
}
- if (radeon_cs_get_ring(p, ring, priority)) {
- if (p->chunk_relocs_idx != -1)
- kfree(p->chunks[p->chunk_relocs_idx].kdata);
- if (p->chunk_flags_idx != -1)
- kfree(p->chunks[p->chunk_flags_idx].kdata);
+ if (radeon_cs_get_ring(p, ring, priority))
return -EINVAL;
- }
/* deal with non-vm */
@@ -271,11 +262,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data)
p->chunks[p->chunk_ib_idx].kpage[0] = kmalloc(PAGE_SIZE, GFP_KERNEL);
p->chunks[p->chunk_ib_idx].kpage[1] = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (p->chunks[p->chunk_ib_idx].kpage[0] == NULL ||
- p->chunks[p->chunk_ib_idx].kpage[1] == NULL) {
- kfree(p->chunks[p->chunk_ib_idx].kpage[0]);
- kfree(p->chunks[p->chunk_ib_idx].kpage[1]);
+ p->chunks[p->chunk_ib_idx].kpage[1] == NULL)
return -ENOMEM;
- }
p->chunks[p->chunk_ib_idx].kpage_idx[0] = -1;
p->chunks[p->chunk_ib_idx].kpage_idx[1] = -1;
p->chunks[p->chunk_ib_idx].last_copied_page = -1;
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=38471
Summary: Ryzom don´t works
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r600
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: linuxdonald(a)linuxdonald.de
Ryzom don´t works.
[linuxdonald@myhost games]$ gdb ./ryzom_client
GNU gdb (GDB) 7.2
…
[View More]Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/local/games/ryzom_client...done.
(gdb) run
Starting program: /opt/local/games/ryzom_client
[Thread debugging using libthread_db enabled]
INF f7fb8720 client.cpp 554 main <Unknown> : Pre-Login Init of Ryzom...
INF f7fb8720 init.cpp 404 displayCPUInfo <Unknown> : CPUInfo: CPUMask before
change: 3f, after change: 1, CPUID: 0, hasHyperThreading: NO
INF f7fb8720 init.cpp 737 prelogInit <Unknown> : RYZOM VERSION : FV RYZOM CORE
(Jun 19 2011 11:37:16)
DBG f7fb8720 config_file.cpp 392 reparse <Unknown> : CF: Adding config file
'/home/linuxdonald/.ryzom/client.cfg' in the config file
INF f7fb8720 config_file.cpp 467 reparse <Unknown> : CF: RootConfigFilename
variable found in the '/home/linuxdonald/.ryzom/client.cfg' config file, parse
the root config file '/opt/local/etc/ryzom/client_default.cfg'
DBG f7fb8720 config_file.cpp 392 reparse <Unknown> : CF: Adding config file
'/opt/local/etc/ryzom/client_default.cfg' in the config file
INF f7fb8720 client_cfg.cpp 721 setValuesOnFileChange <Unknown> : reloading the
config file!
WRN f7fb8720 client_cfg.cpp 1972 init <Unknown> : There's no ClientVersion
variable in the config file!
[New Thread 0x7fffee283700 (LWP 6009)]
INF f7fb8720 path.cpp 958 addSearchPath <Unknown> : PATH:
CPath::addSearchPath(user, 1, 0): adding the path 'user/'
INF f7fb8720 path.cpp 936 addSearchPath <Unknown> : PATH:
CPath::addSearchPath(patch, recursive, not alternative): 'patch' is not a
directory, I'll call addSearchFile()
WRN f7fb8720 path.cpp 1077 addSearchFile <Unknown> : PATH:
CPath::addSearchFile(patch, 0, ''): 'patch' is not found, skip it (current dir
is '/home/linuxdonald/.ryzom'
INF f7fb8720 path.cpp 936 addSearchPath <Unknown> : PATH:
CPath::addSearchPath(examples, recursive, not alternative): 'examples' is not a
directory, I'll call addSearchFile()
WRN f7fb8720 path.cpp 1077 addSearchFile <Unknown> : PATH:
CPath::addSearchFile(examples, 0, ''): 'examples' is not found, skip it
(current dir is '/home/linuxdonald/.ryzom'
INF f7fb8720 path.cpp 958 addSearchPath <Unknown> : PATH:
CPath::addSearchPath(/opt/local/share/ryzom/data/fonts, 1, 0): adding the path
'/opt/local/share/ryzom/data/fonts/'
INF f7fb8720 path.cpp 936 addSearchPath <Unknown> : PATH:
CPath::addSearchPath(/opt/local/share/ryzom/data/gamedev.bnp, recursive, not
alternative): '/opt/local/share/ryzom/data/gamedev.bnp' is not a directory,
I'll call addSearchFile()
DBG ee283700 http_client.cpp 57 connect <Unknown> : Connected to web server
'su1.ryzom.com:50000'
DBG ee283700 http_client.cpp 57 connect <Unknown> : Connected to web server
'su1.ryzom.com:50000'
WRN f7fb8720 path.cpp 516 lookup <Unknown> : PATH: File
(classificationtype_words_de.txt) not found (classificationtype_words_de.txt)
WRN f7fb8720 init.cpp 533 checkDriverVersion <Unknown> : Can't check video
driver version
DBG f7fb8720 dynloadlib.cpp 203 loadLibrary <Unknown> : Loading dynamic library
'/opt/local/lib/nel/libnel_drv_opengl.so'
INF f7fb8720 dru.cpp 105 createGlDriver <Unknown> : Using the library
'nel_drv_opengl' that is in the directory:
'/opt/local/lib/nel/libnel_drv_opengl.so'
DBG f7fb8720 driver_opengl_window.cpp 337 init <Unknown> : 3D: XOpenDisplay on
':0.0' OK
INF f7fb8720 driver_opengl_window.cpp 348 init <Unknown> : 3D: XRandR 1.3 found
INF f7fb8720 driver_opengl_window.cpp 359 init <Unknown> : 3D: XF86VidMode 2.2
found
INF f7fb8720 driver_opengl_window.cpp 373 init <Unknown> : 3D: XRender 0.11
found
DBG f7fb8720 driver_opengl_window.cpp 377 init <Unknown> : 3D: Available X
Extensions:
3D: MIT-SCREEN-SAVER XFree86-VidModeExtension XFree86-DGA DPMS XVideo
3D: XVideo-MotionCompensation X-Resource DOUBLE-BUFFER RECORD DRI2
3D: Generic Event Extension SHAPE MIT-SHM XInputExtension XTEST
3D: BIG-REQUESTS SYNC XKEYBOARD XC-MISC SECURITY
3D: XFIXES RENDER RANDR XINERAMA Composite
3D: DAMAGE GLX SGI-GLX
INF f7fb8720 driver_opengl_window.cpp 2121 getCurrentScreenMode <Unknown> : 3D:
Current XRandR mode 0: 1680x1050, 24bit
Program received signal SIGSEGV, Segmentation fault.
0x0000000100000000 in ?? ()
(gdb) bt
#0 0x0000000100000000 in ?? ()
#1 0x00007ffff11954a1 in XML_Parse () from /usr/lib/libxmlparse.so.0
#2 0x00007fffea2e76ac in driParseOptionInfo () from
/usr/lib/xorg/modules/dri/r600_dri.so
#3 0x00007fffea304767 in ?? () from /usr/lib/xorg/modules/dri/r600_dri.so
#4 0x00007fffea3038f2 in ?? () from /usr/lib/xorg/modules/dri/r600_dri.so
#5 0x00007fffea2e4e63 in ?? () from /usr/lib/xorg/modules/dri/r600_dri.so
#6 0x00007fffece86c8f in ?? () from /usr/lib/libGL.so.1
#7 0x00007fffece63d29 in ?? () from /usr/lib/libGL.so.1
#8 0x00007fffece60c18 in ?? () from /usr/lib/libGL.so.1
#9 0x00007fffece60dbd in glXChooseVisual () from /usr/lib/libGL.so.1
#10 0x00007fffed165002 in NL3D::CDriverGL::setDisplay (this=0x283e340, wnd=0,
mode=..., show=false, resizeable=true)
at
/backup/dev/ryzom/code/nel/src/3d/driver/opengl/driver_opengl_window.cpp:1063
#11 0x00007ffff63a84df in NL3D::CDriverUser::setDisplay (this=0x25690c0, wnd=0,
mode=..., show=false, resizeable=true)
at /backup/dev/ryzom/code/nel/src/3d/driver_user.cpp:237
#12 0x00007ffff63a83e0 in NL3D::CDriverUser::setDisplay (this=0x25690c0,
mode=..., show=false, resizeable=true)
at /backup/dev/ryzom/code/nel/src/3d/driver_user.cpp:228
#13 0x0000000000eaea58 in prelogInit () at
/backup/dev/ryzom/code/ryzom/client/src/init.cpp:886
#14 0x0000000000edf304 in main (argc=1, argv=0x7fffffffe7a8) at
/backup/dev/ryzom/code/ryzom/client/src/client.cpp:555
(gdb)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=46323
Bug #: 46323
Summary: RS480 is not capable of gles blur anymore after update
to mesa 8.0
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/r300
AssignedTo: dri-devel(a)lists.freedesktop.…
[View More]org
ReportedBy: benoit.gouhier(a)gmail.com
Upon upgrading to mesa 8.0, kwin_gles is not able anymore to perform blur effect.
Cf. kde bug 294468
https://bugs.kde.org/show_bug.cgi?id=294468
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]