[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #26 from Tom Stellard 2010-10-19 23:42:04 PDT --- Does running with RADEON_DEBUG=noopt fix the problem? If it does, can out post the output of RADEON_DEBUG=vp,fp,noopt? You can just post the stderr output, I don't need any more screenshots. -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #26 from Tom Stellard 2010-10-19 23:42:04 PDT --- Does running with RADEON_DEBUG=noopt fix the problem? If it does, can out post the output of RADEON_DEBUG=vp,fp,noopt? You can just post the stderr output, I don't need any more screenshots. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] Add Intel GMA500(Poulsbo) Stub Driver
On Wed, 2010-10-20 at 13:51 +0800, Lee, Chun-Yi wrote:
> Currently, there have no GMA500(Poulsbo) native video driver to support
> intel opregion. So, use this stub driver to enable the acpi backlight
> control sysfs entry files by requrest acpi_video_register.
[]
> diff --git a/drivers/gpu/stub/poulsbo.c b/drivers/gpu/stub/poulsbo.c
[]
> +static struct pci_device_id pciidlist[] = {
DEFINE_PCI_DEVICE_TABLE
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 08:39:58AM -0400, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > > I might be able to find some hardware still lying around here that uses
> > > > an
> > > > i810. Not sure unless I go hunting it. But I get the impression that if
> > > > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > > > distros offer a non-smp kernel as an installation option in case the
> > > > user
> > > > needs it? So in reality how big a problem is this?
> > >
> > > Not anymore, which is my old point of making a fuss. Nowadays in the
> > > modern distro world, we supply a single kernel that can at runtime
> > > decide if its running on SMP or UP and rewrite the text section
> > > appropriately with locks etc. Its like magic, and something like
> > > marking drivers as BROKEN_ON_SMP at compile time is really wrong when
> > > what you want now is a runtime warning if someone tries to hotplug a
> > > CPU with a known iffy driver loaded or if someone tries to load the
> > > driver when we are already in SMP mode.
> >
> > We could make the driver run-time non-SMP by adding
> >
> > if (num_present_cpus() > 1) {
> > pr_err("i810 no longer supports SMP\n");
> > return -EINVAL;
> > }
> >
> > to the init function. That would cover the vast majority of the
> > users of i810 hardware, I guess.
>
> I think we also need to cover the PREEMPT case too. But that could be a
> compile time check, since you can't boot a preempt kernel and make it
> non preempt.
>
There are enough nameless embedded vendors that have turned a preempt
kernel in to a non-preempt one at run-time by leaking the preempt count,
whether by design or not, so it's certainly possile :-)
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tuesday 19 October 2010 22:41:22 Alan Cox wrote: > > > you still need to switch off preemption. > > > > Hm, how would you do that from within a driver? > > Do we care - unless I misunderstand the current intel DRM driver handles > the i810 as well ? No, it does handle all devices supported by i830.ko (830M, 845M, 854, 855GM, 865G), but not those supported by i810.ko (810, 815). Arnd
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tuesday 19 October 2010 22:29:12 Greg KH wrote:
> On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote:
> > Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH:
> > > > So no need to clean it up for multiprocessor support.
> > > >
> > > > http://download.intel.com/design/chipsets/datashts/29067602.pdf
> > > > http://www.intel.com/design/chipsets/specupdt/29069403.pdf
> > >
> > > Great, we can just drop all calls to lock_kernel() and the like in the
> > > driver and be done with it, right?
> >
> > No,
> >
> > you still need to switch off preemption.
>
> Hm, how would you do that from within a driver?
I think this would do:
---
drm/i810: remove SMP support and BKL
The i810 and i815 chipsets supported by the i810 drm driver were not
officially designed for SMP operation, so the big kernel lock is
only required for kernel preemption. This disables the driver if
preemption is enabled and removes all calls to lock_kernel in it.
If you own an Acorp 6A815EPD mainboard with a i815 chipset and
two Pentium-III sockets, and want to run recent kernels on it,
tell me about it.
Signed-off-by: Arnd Bergmann
---
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b755301..e071bc8 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -73,8 +73,8 @@ source "drivers/gpu/drm/radeon/Kconfig"
config DRM_I810
tristate "Intel I810"
- # BKL usage in order to avoid AB-BA deadlocks, may become BROKEN_ON_SMP
- depends on DRM && AGP && AGP_INTEL && BKL
+ # PREEMPT requires BKL support here, which was removed
+ depends on DRM && AGP && AGP_INTEL && !PREEMPT
help
Choose this option if you have an Intel I810 graphics card. If M is
selected, the module will be called i810. AGP support is required
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index ff33e53..8f371e8 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -37,7 +37,6 @@
#include/* For task queue support */
#include
#include
-#include
#include
#define I810_BUF_FREE 2
@@ -94,7 +93,6 @@ static int i810_mmap_buffers(struct file *filp, struct
vm_area_struct *vma)
struct drm_buf *buf;
drm_i810_buf_priv_t *buf_priv;
- lock_kernel();
dev = priv->minor->dev;
dev_priv = dev->dev_private;
buf = dev_priv->mmap_buffer;
@@ -104,7 +102,6 @@ static int i810_mmap_buffers(struct file *filp, struct
vm_area_struct *vma)
vma->vm_file = filp;
buf_priv->currently_mapped = I810_BUF_MAPPED;
- unlock_kernel();
if (io_remap_pfn_range(vma, vma->vm_start,
vma->vm_pgoff,
@@ -116,7 +113,7 @@ static int i810_mmap_buffers(struct file *filp, struct
vm_area_struct *vma)
static const struct file_operations i810_buffer_fops = {
.open = drm_open,
.release = drm_release,
- .unlocked_ioctl = i810_ioctl,
+ .unlocked_ioctl = drm_ioctl,
.mmap = i810_mmap_buffers,
.fasync = drm_fasync,
.llseek = noop_llseek,
@@ -1242,19 +1239,6 @@ int i810_driver_dma_quiescent(struct drm_device *dev)
return 0;
}
-/*
- * call the drm_ioctl under the big kernel lock because
- * to lock against the i810_mmap_buffers function.
- */
-long i810_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
-{
- int ret;
- lock_kernel();
- ret = drm_ioctl(file, cmd, arg);
- unlock_kernel();
- return ret;
-}
-
struct drm_ioctl_desc i810_ioctls[] = {
DRM_IOCTL_DEF_DRV(I810_INIT, i810_dma_init,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I810_VERTEX, i810_dma_vertex, DRM_AUTH|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/i810/i810_drv.c b/drivers/gpu/drm/i810/i810_drv.c
index 88bcd33..9642d3c 100644
--- a/drivers/gpu/drm/i810/i810_drv.c
+++ b/drivers/gpu/drm/i810/i810_drv.c
@@ -57,7 +57,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.unlocked_ioctl = i810_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
@@ -79,6 +79,10 @@ static struct drm_driver driver = {
static int __init i810_init(void)
{
+ if (num_present_cpus() > 1) {
+ pr_err("drm/i810 does not support SMP\n");
+ return -EINVAL;
+ }
driver.num_ioctls = i810_max_ioctl;
return drm_init(&driver);
}
[Bug 22576] [KMS] mesa demo spectex broken on rv280
https://bugs.freedesktop.org/show_bug.cgi?id=22576 --- Comment #16 from Andrew Randrianasulu 2010-10-19 22:43:28 PDT --- Created an attachment (id=39559) --> (https://bugs.freedesktop.org/attachment.cgi?id=39559) screenshot of corruption -- 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
[Bug 22576] [KMS] mesa demo spectex broken on rv280
https://bugs.freedesktop.org/show_bug.cgi?id=22576 --- Comment #16 from Andrew Randrianasulu 2010-10-19 22:43:28 PDT --- Created an attachment (id=39559) --> (https://bugs.freedesktop.org/attachment.cgi?id=39559) screenshot of corruption -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 22576] [KMS] mesa demo spectex broken on rv280
https://bugs.freedesktop.org/show_bug.cgi?id=22576 --- Comment #15 from Andrew Randrianasulu 2010-10-19 22:42:16 PDT --- (In reply to comment #14) > This could be fixed in mesa master and 7.9 branch: > http://lists.freedesktop.org/archives/mesa-dev/2010-October/003492.html It still broken, but in slightly different way: sphere has few horizontal black stripes now. I'll add screenshot. -- 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
[Bug 22576] [KMS] mesa demo spectex broken on rv280
https://bugs.freedesktop.org/show_bug.cgi?id=22576 --- Comment #15 from Andrew Randrianasulu 2010-10-19 22:42:16 PDT --- (In reply to comment #14) > This could be fixed in mesa master and 7.9 branch: > http://lists.freedesktop.org/archives/mesa-dev/2010-October/003492.html It still broken, but in slightly different way: sphere has few horizontal black stripes now. I'll add screenshot. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29367] [KMS] Assertion `boi->space_accounted' failed. on rv280
https://bugs.freedesktop.org/show_bug.cgi?id=29367
Andrew Randrianasulu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Comment #7 from Andrew Randrianasulu 2010-10-19 22:38:38
PDT ---
Yes, fixed for me in mesa master.
Using mesa - commit 974fb466f299fc569a86097936ab89c8c369f6d2
Author: Chad Versace
Date: Fri Oct 15 14:46:00 2010 -0700
glsl: Commit generated file glsl_lexer.cpp
Changes are due to commit "glsl: Fix lexer rule for ^=".
libdrm - commit 09b1062628f2cbddb3ebae20e7b3b8a0a93acebf
Author: Francisco Jerez
Date: Tue Sep 28 22:45:27 2010 +0200
nouveau: Let the user choose the push buffer size.
Signed-off-by: Francisco Jerez
Acked-by: Ben Skeggs
xf86-video-ati - commit 0921ecc1c751df0dd56e0b1d0b78ab53d7164904
Author: Alex Deucher
Date: Mon Oct 4 12:34:47 2010 -0400
evergreen: use EXACreatePixmap2 if available
plus build patch for new xserver (should update, build issue fixed in newer
git)
xserver - commit 853d7ebfa3e2d281d92890a39010ff5787a00ffd
Author: Adam Jackson
Date: Tue Oct 5 11:24:28 2010 -0400
vbe: Fix copying the mode info block
Just use memcpy, seriously.
Reviewed-by: Rémi Cardona
Signed-off-by: Adam Jackson
Signed-off-by: Keith Packard
kernel -
commit 8fd01d6cfbf75465d84a4e533ed70c5f57b3ff51
Author: Linus Torvalds
Date: Thu Oct 14 19:15:28 2010 -0700
Export dump_{write,seek} to binary loader modules
If you build aout support as a module, you'll want these exported.
Reported-by: Tetsuo Handa
Signed-off-by: Linus Torvalds
(basically 2.6.36-rc8 + 1 commit)
--
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
[Bug 29367] [KMS] Assertion `boi->space_accounted' failed. on rv280
https://bugs.freedesktop.org/show_bug.cgi?id=29367
Andrew Randrianasulu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Comment #7 from Andrew Randrianasulu 2010-10-19
22:38:38 PDT ---
Yes, fixed for me in mesa master.
Using mesa - commit 974fb466f299fc569a86097936ab89c8c369f6d2
Author: Chad Versace
Date: Fri Oct 15 14:46:00 2010 -0700
glsl: Commit generated file glsl_lexer.cpp
Changes are due to commit "glsl: Fix lexer rule for ^=".
libdrm - commit 09b1062628f2cbddb3ebae20e7b3b8a0a93acebf
Author: Francisco Jerez
Date: Tue Sep 28 22:45:27 2010 +0200
nouveau: Let the user choose the push buffer size.
Signed-off-by: Francisco Jerez
Acked-by: Ben Skeggs
xf86-video-ati - commit 0921ecc1c751df0dd56e0b1d0b78ab53d7164904
Author: Alex Deucher
Date: Mon Oct 4 12:34:47 2010 -0400
evergreen: use EXACreatePixmap2 if available
plus build patch for new xserver (should update, build issue fixed in newer
git)
xserver - commit 853d7ebfa3e2d281d92890a39010ff5787a00ffd
Author: Adam Jackson
Date: Tue Oct 5 11:24:28 2010 -0400
vbe: Fix copying the mode info block
Just use memcpy, seriously.
Reviewed-by: R??mi Cardona
Signed-off-by: Adam Jackson
Signed-off-by: Keith Packard
kernel -
commit 8fd01d6cfbf75465d84a4e533ed70c5f57b3ff51
Author: Linus Torvalds
Date: Thu Oct 14 19:15:28 2010 -0700
Export dump_{write,seek} to binary loader modules
If you build aout support as a module, you'll want these exported.
Reported-by: Tetsuo Handa
Signed-off-by: Linus Torvalds
(basically 2.6.36-rc8 + 1 commit)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, 19 Oct 2010, Greg KH wrote: > > > > So no need to clean it up for multiprocessor support. > > > > > > > > http://download.intel.com/design/chipsets/datashts/29067602.pdf > > > > http://www.intel.com/design/chipsets/specupdt/29069403.pdf > > > > > > Great, we can just drop all calls to lock_kernel() and the like in the > > > driver and be done with it, right? > > > > No, > > > > you still need to switch off preemption. > > Hm, how would you do that from within a driver? preempt_disable() -- Jiri Kosina SUSE Labs, Novell Inc.
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
> > you still need to switch off preemption. > > Hm, how would you do that from within a driver? Do we care - unless I misunderstand the current intel DRM driver handles the i810 as well ?
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH: > > So no need to clean it up for multiprocessor support. > > > > http://download.intel.com/design/chipsets/datashts/29067602.pdf > > http://www.intel.com/design/chipsets/specupdt/29069403.pdf > > Great, we can just drop all calls to lock_kernel() and the like in the > driver and be done with it, right? No, you still need to switch off preemption. Regards Oliver
[Bug 25005] radeon RV250: xorg locks up when running glxgears
https://bugs.freedesktop.org/show_bug.cgi?id=25005 --- Comment #8 from Jose 2010-10-19 19:53:47 PDT --- I won't have access to the machine with the ATI card for a while. It may be a couple of weeks before I have a chance to test it. -- 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
[Bug 25005] radeon RV250: xorg locks up when running glxgears
https://bugs.freedesktop.org/show_bug.cgi?id=25005 --- Comment #8 from Jose 2010-10-19 19:53:47 PDT --- I won't have access to the machine with the ATI card for a while. It may be a couple of weeks before I have a chance to test it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27434] [rv710] low 3d perfomance in general
https://bugs.freedesktop.org/show_bug.cgi?id=27434 --- Comment #4 from Alex Deucher 2010-10-19 19:29:58 PDT --- Is this still an issue with mesa 7.9? -- 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
[Bug 27434] [rv710] low 3d perfomance in general
https://bugs.freedesktop.org/show_bug.cgi?id=27434 Alex Deucher changed: What|Removed |Added Product|xorg|Mesa Version|git |unspecified Component|Driver/Radeon |Drivers/DRI/R600 AssignedTo|xorg-driver-...@lists.x.org |dri-de...@lists.freedesktop ||.org QAContact|xorg-t...@lists.x.org | -- 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
[Bug 27434] [rv710] low 3d perfomance in general
https://bugs.freedesktop.org/show_bug.cgi?id=27434 --- Comment #4 from Alex Deucher 2010-10-19 19:29:58 PDT --- Is this still an issue with mesa 7.9? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27434] [rv710] low 3d perfomance in general
https://bugs.freedesktop.org/show_bug.cgi?id=27434 Alex Deucher changed: What|Removed |Added Product|xorg|Mesa Version|git |unspecified Component|Driver/Radeon |Drivers/DRI/R600 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QAContact|xorg-team at lists.x.org | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26479] Loading screen in WoW mirrored across diagonal
https://bugs.freedesktop.org/show_bug.cgi?id=26479 Alex Deucher changed: What|Removed |Added Product|xorg|Mesa Version|7.4 |unspecified Component|Driver/Radeon |Drivers/DRI/R600 AssignedTo|xorg-driver-...@lists.x.org |dri-de...@lists.freedesktop ||.org QAContact|xorg-t...@lists.x.org | -- 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
[Bug 26479] Loading screen in WoW mirrored across diagonal
https://bugs.freedesktop.org/show_bug.cgi?id=26479 Alex Deucher changed: What|Removed |Added Product|xorg|Mesa Version|7.4 |unspecified Component|Driver/Radeon |Drivers/DRI/R600 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QAContact|xorg-team at lists.x.org | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25676] Radeon hangs in RADEONWaitForIdleCP in bubble3d screensaver
https://bugs.freedesktop.org/show_bug.cgi?id=25676 Alex Deucher changed: What|Removed |Added Product|xorg|Mesa Version|7.4 |unspecified Component|Driver/Radeon |Drivers/DRI/r200 AssignedTo|xorg-driver-...@lists.x.org |dri-de...@lists.freedesktop ||.org QAContact|xorg-t...@lists.x.org | --- Comment #1 from Alex Deucher 2010-10-19 18:58:38 PDT --- Is this still an issue with mesa from git? -- 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
[Bug 25676] Radeon hangs in RADEONWaitForIdleCP in bubble3d screensaver
https://bugs.freedesktop.org/show_bug.cgi?id=25676 Alex Deucher changed: What|Removed |Added Product|xorg|Mesa Version|7.4 |unspecified Component|Driver/Radeon |Drivers/DRI/r200 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QAContact|xorg-team at lists.x.org | --- Comment #1 from Alex Deucher 2010-10-19 18:58:38 PDT --- Is this still an issue with mesa from git? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25005] radeon RV250: xorg locks up when running glxgears
https://bugs.freedesktop.org/show_bug.cgi?id=25005 Alex Deucher changed: What|Removed |Added Product|xorg|Mesa Version|7.5 |unspecified Component|Driver/Radeon |Drivers/DRI/r200 AssignedTo|xorg-driver-...@lists.x.org |dri-de...@lists.freedesktop ||.org QAContact|xorg-t...@lists.x.org | --- Comment #7 from Alex Deucher 2010-10-19 18:42:04 PDT --- Is this still an issue with mesa from git? -- 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
[Bug 25005] radeon RV250: xorg locks up when running glxgears
https://bugs.freedesktop.org/show_bug.cgi?id=25005 Alex Deucher changed: What|Removed |Added Product|xorg|Mesa Version|7.5 |unspecified Component|Driver/Radeon |Drivers/DRI/r200 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QAContact|xorg-team at lists.x.org | --- Comment #7 from Alex Deucher 2010-10-19 18:42:04 PDT --- Is this still an issue with mesa from git? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Intel-gfx] [PATCH 1/4] drm/edid: add helper function to detect monitor audio capability
On Sun, 2010-09-19 at 15:56 +0800, Zhenyu Wang wrote: > On 2010.09.19 08:38:07 +0100, Chris Wilson wrote: > > > > This should be cc'ed for Adam Jackson's attention as well. > > yep, I think I cc-ed ajax in git-send-mail command line...I'll amend the > commit. > > > > +bool drm_detect_monitor_audio(struct edid *edid) > > > > drm_edid_has_monitor_audio()? That is a little more self-descriptive. > > (I also think drm_detect_hdmi_monitor is poorly named.) > > yeah, that looks better. thanks. > > > The last time Adam had a chance to comment on this EDID check, he > > suggested that we cannot rely on has_audio being a reliable indicator of > > the sink's properties. If the EDID has no audio support, then return > > early, otherwise perform the secondary check that extension block contains > > audio data. > > That's also the problem we stuck for quite some time, and until recently > we got reply on this issue. Adam is right, 'basic audio' bit might not be > reliable, so we try to search audio block too, if there's any existence, > we will accept 'basic audio' support as well. Also, would you be able to export drm_find_cea_extension(), I have pending nouveau patches that will require this symbol (to build a HDA ELD from the EDID data for HDMI/DP audio). With that, you can add my Reviewed-by :) Thanks, Ben. > > Thanks for the review! > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[stable] [PATCH] drm/radeon/kms: fix possible sigbus in evergreen accel code
On Tue, Oct 19, 2010 at 5:00 PM, Greg KH wrote: > I need the ack from the DRM maintainer before I can add a patch to the > stable tree that is not upstream in Linus's tree, as it is a major > exception to the rule. A better fix ended up making it into 2.6.36 afterall, so we don't anything for 2.6.36. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c919b371cb734f42b1130e706ecee262f8d9261d However, either patch will work for 2.6.35. Alex > > David? > > > On Tue, Oct 12, 2010 at 12:20:31PM -0400, Alex Deucher wrote: >> 2.6.35 and 2.6.36 do not contain blit support for evergreen >> asics so if they use unmappable vram, you can end up with an >> unreachable buffer address. ?This should not be applied to drm-next >> as that tree already contains evergreen blit support. ?This should >> only be applied to the 2.6.35 and 2.6.36 stable trees. >> >> Fixes: >> https://bugs.freedesktop.org/show_bug.cgi?id=30188 >> >> Signed-off-by: Alex Deucher >> Cc: stable at kernel.org >> --- >> ?drivers/gpu/drm/radeon/evergreen.c | ? ?2 ++ >> ?1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/evergreen.c >> b/drivers/gpu/drm/radeon/evergreen.c >> index 2117cf5..f8c0f15 100644 >> --- a/drivers/gpu/drm/radeon/evergreen.c >> +++ b/drivers/gpu/drm/radeon/evergreen.c >> @@ -1480,6 +1480,8 @@ int evergreen_mc_init(struct radeon_device *rdev) >> ? ? ? rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024; >> ? ? ? rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024; >> ? ? ? rdev->mc.visible_vram_size = rdev->mc.aper_size; >> + ? ? /* limit it to the aperture size for now as there is no blit support >> in 2.6.35/36*/ >> + ? ? rdev->mc.real_vram_size = rdev->mc.visible_vram_size; >> ? ? ? r600_vram_gtt_location(rdev, &rdev->mc); >> ? ? ? radeon_update_bandwidth_info(rdev); >> >> -- >> 1.7.1.1 >> >> ___ >> stable mailing list >> stable at linux.kernel.org >> http://linux.kernel.org/mailman/listinfo/stable >
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tuesday 19 October 2010, Steven Rostedt wrote: > On Tue, 2010-10-19 at 15:36 +0200, Arnd Bergmann wrote: > > [trimming Cc list] > > > > On Tuesday 19 October 2010, Steven Rostedt wrote: > > > I think we also need to cover the PREEMPT case too. But that could be a > > > compile time check, since you can't boot a preempt kernel and make it > > > non preempt. > > > > Right. Can we turn the lock_kernel() into preempt_disable() in these > > drivers when we know we never run on SMP? > > I'm not sure that will work. A holder of the BKL can call schedule or > even a mutex. The schedule code will drop the BKL and re-enable > preemption. Unless the code is known not to schedule while holding BKL, > we would need to open code the preempt_enable() around the locations > that the code may schedule. Right, that won't work then. I was confused by the fact that __lock_kernel() turns into preempt_disable() on UP-preempt systems, which only works because it still maintains current->lock_depth and schedule consequently enables preemption again in __release_kernel_lock(). With CONFIG_BKL disabled, that won't happen any more. Arnd
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
[trimming Cc list] On Tuesday 19 October 2010, Steven Rostedt wrote: > I think we also need to cover the PREEMPT case too. But that could be a > compile time check, since you can't boot a preempt kernel and make it > non preempt. Right. Can we turn the lock_kernel() into preempt_disable() in these drivers when we know we never run on SMP? Arnd
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tuesday 19 October 2010, Arnd Bergmann wrote:
> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > I might be able to find some hardware still lying around here that uses an
> > > i810. Not sure unless I go hunting it. But I get the impression that if
> > > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > > distros offer a non-smp kernel as an installation option in case the user
> > > needs it? So in reality how big a problem is this?
> >
> > Not anymore, which is my old point of making a fuss. Nowadays in the
> > modern distro world, we supply a single kernel that can at runtime
> > decide if its running on SMP or UP and rewrite the text section
> > appropriately with locks etc. Its like magic, and something like
> > marking drivers as BROKEN_ON_SMP at compile time is really wrong when
> > what you want now is a runtime warning if someone tries to hotplug a
> > CPU with a known iffy driver loaded or if someone tries to load the
> > driver when we are already in SMP mode.
>
> We could make the driver run-time non-SMP by adding
>
> if (num_present_cpus() > 1) {
> pr_err("i810 no longer supports SMP\n");
> return -EINVAL;
> }
>
> to the init function. That would cover the vast majority of the
> users of i810 hardware, I guess.
Some research showed that Intel never support i810/i815 SMP setups,
but there was indeed one company (http://www.acorpusa.com at the time,
now owned by a domain squatter) that made i815E based dual Pentium-III
boards like this one: http://cgi.ebay.com/280319795096
The first person that can send me an authentic log file showing the
use of X.org with DRM on a 2.6.35 kernel with two processors on that
mainboard dated today or earlier gets a free upgrade to an AGP graphics
card of comparable or better 3D performance from me. Please include
the story how why you are running this machine with a new kernel.
i830 is harder, apparently some i865G boards support Pentium 4 with HT
and even later dual-core processors.
Arnd
Re: [stable] [PATCH] drm/radeon/kms: fix possible sigbus in evergreen accel code
On Wed, Oct 20, 2010 at 7:00 AM, Greg KH wrote: > I need the ack from the DRM maintainer before I can add a patch to the > stable tree that is not upstream in Linus's tree, as it is a major > exception to the rule. > > David For 2.6.35 Acked-by: Dave Airlie for 2.6.36 we are all good. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
> I might be able to find some hardware still lying around here that uses an > i810. Not sure unless I go hunting it. But I get the impression that if > the kernel is a single-CPU kernel there is not any problem anyway? Don't > distros offer a non-smp kernel as an installation option in case the user > needs it? So in reality how big a problem is this? Not anymore, which is my old point of making a fuss. Nowadays in the modern distro world, we supply a single kernel that can at runtime decide if its running on SMP or UP and rewrite the text section appropriately with locks etc. Its like magic, and something like marking drivers as BROKEN_ON_SMP at compile time is really wrong when what you want now is a runtime warning if someone tries to hotplug a CPU with a known iffy driver loaded or if someone tries to load the driver when we are already in SMP mode. Dave.
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Mon, 18 Oct 2010 17:40:04 PDT, Greg KH said: > I do have access to this hardware, but its on an old single processor > laptop, so any work that it would take to help do this development, > really wouldn't be able to be tested to be valid at all. The i810 is a graphics chipset embedded on the memory controller, which was designed for the Intel Pentium II, Pentium III, and Celeron CPUs. Page 8 of the datasheet specifically says: Processor/Host Bus Support - Optimized for the Intel Pentium II processor, Intel Pentium III processor, and Intel CeleronTM processor - Supports processor 370-Pin Socket and SC242 connectors - Supports 32-Bit System Bus Addressing - 4 deep in-order queue; 4 or 1 deep request queue - Supports Uni-processor systems only So no need to clean it up for multiprocessor support. http://download.intel.com/design/chipsets/datashts/29067602.pdf http://www.intel.com/design/chipsets/specupdt/29069403.pdf -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20101019/647c1a85/attachment-0001.pgp>
Re: [stable] [PATCH] drm/radeon/kms: fix possible sigbus in evergreen accel code
On Tue, Oct 19, 2010 at 5:00 PM, Greg KH wrote: > I need the ack from the DRM maintainer before I can add a patch to the > stable tree that is not upstream in Linus's tree, as it is a major > exception to the rule. A better fix ended up making it into 2.6.36 afterall, so we don't anything for 2.6.36. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c919b371cb734f42b1130e706ecee262f8d9261d However, either patch will work for 2.6.35. Alex > > David? > > > On Tue, Oct 12, 2010 at 12:20:31PM -0400, Alex Deucher wrote: >> 2.6.35 and 2.6.36 do not contain blit support for evergreen >> asics so if they use unmappable vram, you can end up with an >> unreachable buffer address. This should not be applied to drm-next >> as that tree already contains evergreen blit support. This should >> only be applied to the 2.6.35 and 2.6.36 stable trees. >> >> Fixes: >> https://bugs.freedesktop.org/show_bug.cgi?id=30188 >> >> Signed-off-by: Alex Deucher >> Cc: sta...@kernel.org >> --- >> drivers/gpu/drm/radeon/evergreen.c | 2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/evergreen.c >> b/drivers/gpu/drm/radeon/evergreen.c >> index 2117cf5..f8c0f15 100644 >> --- a/drivers/gpu/drm/radeon/evergreen.c >> +++ b/drivers/gpu/drm/radeon/evergreen.c >> @@ -1480,6 +1480,8 @@ int evergreen_mc_init(struct radeon_device *rdev) >> rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024; >> rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024; >> rdev->mc.visible_vram_size = rdev->mc.aper_size; >> + /* limit it to the aperture size for now as there is no blit support >> in 2.6.35/36*/ >> + rdev->mc.real_vram_size = rdev->mc.visible_vram_size; >> r600_vram_gtt_location(rdev, &rdev->mc); >> radeon_update_bandwidth_info(rdev); >> >> -- >> 1.7.1.1 >> >> ___ >> stable mailing list >> sta...@linux.kernel.org >> http://linux.kernel.org/mailman/listinfo/stable > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/ttm: Avoid using the ttm_mem_type_manager::put_locked function
On Thu, Oct 14, 2010 at 3:17 AM, Thomas Hellstrom
wrote:
> Release the lru spinlock early.
Actually I think its this patch that introduces the recursion issue,
since we still seem to hold the lock on entry into cleanup_memtype_use
and not drop it at all.
Dave.
>
> Signed-off-by: Thomas Hellstrom
> ---
> ?drivers/gpu/drm/ttm/ttm_bo.c ? ? ? ? | ? 30 +-
> ?drivers/gpu/drm/ttm/ttm_bo_manager.c | ? 10 --
> ?include/drm/ttm/ttm_bo_driver.h ? ? ?| ? ?2 --
> ?3 files changed, 5 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index fd8344d..7497b79 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -439,36 +439,25 @@ out_err:
> ?}
>
> ?/**
> - * Call bo::reserved and with the lru lock held.
> + * Call bo::reserved.
> ?* Will release GPU memory type usage on destruction.
> - * This is the place to put in driver specific hooks.
> - * Will release the bo::reserved lock and the
> - * lru lock on exit.
> + * This is the place to put in driver specific hooks to release
> + * driver private resources.
> + * Will release the bo::reserved lock.
> ?*/
>
> ?static void ttm_bo_cleanup_memtype_use(struct ttm_buffer_object *bo)
> ?{
> - ? ? ? struct ttm_bo_global *glob = bo->glob;
> -
> ? ? ? ?if (bo->ttm) {
> -
> - ? ? ? ? ? ? ? /**
> - ? ? ? ? ? ? ? ?* Release the lru_lock, since we don't want to have
> - ? ? ? ? ? ? ? ?* an atomic requirement on ttm_tt[unbind|destroy].
> - ? ? ? ? ? ? ? ?*/
> -
> - ? ? ? ? ? ? ? spin_unlock(&glob->lru_lock);
> ? ? ? ? ? ? ? ?ttm_tt_unbind(bo->ttm);
> ? ? ? ? ? ? ? ?ttm_tt_destroy(bo->ttm);
> ? ? ? ? ? ? ? ?bo->ttm = NULL;
> - ? ? ? ? ? ? ? spin_lock(&glob->lru_lock);
> ? ? ? ?}
>
> - ? ? ? ttm_bo_mem_put_locked(bo, &bo->mem);
> + ? ? ? ttm_bo_mem_put(bo, &bo->mem);
>
> ? ? ? ?atomic_set(&bo->reserved, 0);
> ? ? ? ?wake_up_all(&bo->event_queue);
> - ? ? ? spin_unlock(&glob->lru_lock);
> ?}
>
>
> @@ -788,15 +777,6 @@ void ttm_bo_mem_put(struct ttm_buffer_object *bo, struct
> ttm_mem_reg *mem)
> ?}
> ?EXPORT_SYMBOL(ttm_bo_mem_put);
>
> -void ttm_bo_mem_put_locked(struct ttm_buffer_object *bo, struct ttm_mem_reg
> *mem)
> -{
> - ? ? ? struct ttm_mem_type_manager *man = &bo->bdev->man[mem->mem_type];
> -
> - ? ? ? if (mem->mm_node)
> - ? ? ? ? ? ? ? (*man->func->put_node_locked)(man, mem);
> -}
> -EXPORT_SYMBOL(ttm_bo_mem_put_locked);
> -
> ?/**
> ?* Repeatedly evict memory from the LRU for @mem_type until we create enough
> ?* space, or we've evicted everything and there isn't enough space.
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
> b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> index 35c97b2..7410c19 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> @@ -90,15 +90,6 @@ static void ttm_bo_man_put_node(struct
> ttm_mem_type_manager *man,
> ? ? ? ?}
> ?}
>
> -static void ttm_bo_man_put_node_locked(struct ttm_mem_type_manager *man,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct ttm_mem_reg *mem)
> -{
> - ? ? ? if (mem->mm_node) {
> - ? ? ? ? ? ? ? drm_mm_put_block(mem->mm_node);
> - ? ? ? ? ? ? ? mem->mm_node = NULL;
> - ? ? ? }
> -}
> -
> ?static int ttm_bo_man_init(struct ttm_mem_type_manager *man,
> ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned long p_size)
> ?{
> @@ -152,7 +143,6 @@ const struct ttm_mem_type_manager_func
> ttm_bo_manager_func = {
> ? ? ? ?ttm_bo_man_takedown,
> ? ? ? ?ttm_bo_man_get_node,
> ? ? ? ?ttm_bo_man_put_node,
> - ? ? ? ttm_bo_man_put_node_locked,
> ? ? ? ?ttm_bo_man_debug
> ?};
> ?EXPORT_SYMBOL(ttm_bo_manager_func);
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index d0ff529..d01b4dd 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -214,8 +214,6 @@ struct ttm_mem_type_manager_func {
> ? ? ? ? ? ? ? ? ? ? ? ? struct ttm_mem_reg *mem);
> ? ? ? ?void (*put_node)(struct ttm_mem_type_manager *man,
> ? ? ? ? ? ? ? ? ? ? ? ? struct ttm_mem_reg *mem);
> - ? ? ? void (*put_node_locked)(struct ttm_mem_type_manager *man,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct ttm_mem_reg *mem);
> ? ? ? ?void (*debug)(struct ttm_mem_type_manager *man, const char *prefix);
> ?};
>
> --
> 1.6.2.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Re: [stable] [PATCH] drm/radeon/kms: fix possible sigbus in evergreen accel code
I need the ack from the DRM maintainer before I can add a patch to the stable tree that is not upstream in Linus's tree, as it is a major exception to the rule. David? On Tue, Oct 12, 2010 at 12:20:31PM -0400, Alex Deucher wrote: > 2.6.35 and 2.6.36 do not contain blit support for evergreen > asics so if they use unmappable vram, you can end up with an > unreachable buffer address. This should not be applied to drm-next > as that tree already contains evergreen blit support. This should > only be applied to the 2.6.35 and 2.6.36 stable trees. > > Fixes: > https://bugs.freedesktop.org/show_bug.cgi?id=30188 > > Signed-off-by: Alex Deucher > Cc: sta...@kernel.org > --- > drivers/gpu/drm/radeon/evergreen.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/evergreen.c > b/drivers/gpu/drm/radeon/evergreen.c > index 2117cf5..f8c0f15 100644 > --- a/drivers/gpu/drm/radeon/evergreen.c > +++ b/drivers/gpu/drm/radeon/evergreen.c > @@ -1480,6 +1480,8 @@ int evergreen_mc_init(struct radeon_device *rdev) > rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024; > rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024; > rdev->mc.visible_vram_size = rdev->mc.aper_size; > + /* limit it to the aperture size for now as there is no blit support in > 2.6.35/36*/ > + rdev->mc.real_vram_size = rdev->mc.visible_vram_size; > r600_vram_gtt_location(rdev, &rdev->mc); > radeon_update_bandwidth_info(rdev); > > -- > 1.7.1.1 > > ___ > stable mailing list > sta...@linux.kernel.org > http://linux.kernel.org/mailman/listinfo/stable ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
>> >> like I'm sure the intersection of this driver and reality are getting >> quite limited, but its still a userspace ABI change and needs to be >> treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the >> old driver/API. > > Thus, you are saying that this will break for people with older user > apps and have a newer kernel? There are two drivers here: i810 i830 The i830 case is the case I care less about since the ABI is only used by older userspace and i915 provides a replacement. the i810 case ABI is still in use today by distro userspaces that are still released, i.e. i810 is still used in F14, Ubuntu 10.10, RHEL6 Beta etc. I've snipped the rest of the argument on the grounds you are conflating two cases that aren't the same. > >> >> Well the thing is doing the work right is a non-trivial task and just >> dropping support only screws the people using the hardware, >> it doesn't place any burden on the distro developers to fix it up. If >> people are really serious about making the BKL go away completely, I >> think the onus should be on them to fix the drivers not on the users >> who are using it, like I'm ?guessing if this gets broken the bug will >> end up in Novell or RH bugzilla in a year and nobody will ever see it. > > Well the problem comes down to testing it. I don't know of any developer > that is removing the BKL that actually owns hardware to test out these > broken drivers. And for the change not being trivial, means that there's > no way to do in correctly. > So we can drop i830 using deprecation, however its pointless since the fix for i810 is the same fix for i830 if we can work out the fix. Well the way to do it correctly is make it so if the driver is initialised and we do an SMP transition we warn the users, or we make BROKEN_ON_SMP into a runtime thing that warns when the driver is loaded on an SMP system. The intersection of SMP and this hardware is definitely a very very small number and a lot more workable. Dave.
[stable] [PATCH] drm/radeon/kms: fix possible sigbus in evergreen accel code
I need the ack from the DRM maintainer before I can add a patch to the stable tree that is not upstream in Linus's tree, as it is a major exception to the rule. David? On Tue, Oct 12, 2010 at 12:20:31PM -0400, Alex Deucher wrote: > 2.6.35 and 2.6.36 do not contain blit support for evergreen > asics so if they use unmappable vram, you can end up with an > unreachable buffer address. This should not be applied to drm-next > as that tree already contains evergreen blit support. This should > only be applied to the 2.6.35 and 2.6.36 stable trees. > > Fixes: > https://bugs.freedesktop.org/show_bug.cgi?id=30188 > > Signed-off-by: Alex Deucher > Cc: stable at kernel.org > --- > drivers/gpu/drm/radeon/evergreen.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/evergreen.c > b/drivers/gpu/drm/radeon/evergreen.c > index 2117cf5..f8c0f15 100644 > --- a/drivers/gpu/drm/radeon/evergreen.c > +++ b/drivers/gpu/drm/radeon/evergreen.c > @@ -1480,6 +1480,8 @@ int evergreen_mc_init(struct radeon_device *rdev) > rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024; > rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024; > rdev->mc.visible_vram_size = rdev->mc.aper_size; > + /* limit it to the aperture size for now as there is no blit support in > 2.6.35/36*/ > + rdev->mc.real_vram_size = rdev->mc.visible_vram_size; > r600_vram_gtt_location(rdev, &rdev->mc); > radeon_update_bandwidth_info(rdev); > > -- > 1.7.1.1 > > ___ > stable mailing list > stable at linux.kernel.org > http://linux.kernel.org/mailman/listinfo/stable
[PATCH 2/2] drm/ttm: Optimize delayed buffer destruction
On Thu, Oct 14, 2010 at 3:18 AM, Thomas Hellstrom
wrote:
> This commit replaces the ttm_bo_cleanup_ref function with two new functions.
> One for the case where the bo is not yet on the delayed destroy list, and
> one for the case where the bo was on the delayed destroy list, at least at
> the time of call. This makes it possible to optimize the two cases somewhat.
I tried booting this today, but on radeon starting X hit a recursive
spin lock on the lru lock.
(annotated below)
> + *
> + * @interruptible ? ? ? ? Any sleeps should occur interruptibly.
> + * @no_wait_reserve ? ? ? Never wait for reserve. Return -EBUSY instead.
> + * @no_wait_gpu ? ? ? ? ? Never wait for gpu. Return -EBUSY instead.
> + */
> +
> +static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bool interruptible,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bool no_wait_reserve,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bool no_wait_gpu)
> +{
> + ? ? ? struct ttm_bo_global *glob = bo->glob;
> + ? ? ? int put_count;
> + ? ? ? int ret = 0;
> +
> +retry:
> + ? ? ? spin_lock(&bo->lock);
> + ? ? ? ret = ttm_bo_wait(bo, false, interruptible, no_wait_gpu);
> + ? ? ? spin_unlock(&bo->lock);
> +
> + ? ? ? if (unlikely(ret != 0))
> + ? ? ? ? ? ? ? return ret;
> +
> ? ? ? ?spin_lock(&glob->lru_lock);
^^ take LRU lock
> - ? ? ? if (list_empty(&bo->ddestroy)) {
> - ? ? ? ? ? ? ? void *sync_obj = bo->sync_obj;
> - ? ? ? ? ? ? ? void *sync_obj_arg = bo->sync_obj_arg;
> + ? ? ? ret = ttm_bo_reserve_locked(bo, interruptible,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? no_wait_reserve, false, 0);
>
> - ? ? ? ? ? ? ? kref_get(&bo->list_kref);
> - ? ? ? ? ? ? ? list_add_tail(&bo->ddestroy, &bdev->ddestroy);
> + ? ? ? if (unlikely(ret != 0) || list_empty(&bo->ddestroy)) {
> ? ? ? ? ? ? ? ?spin_unlock(&glob->lru_lock);
^^ drop in error path.
> - ? ? ? ? ? ? ? spin_unlock(&bo->lock);
> + ? ? ? ? ? ? ? return ret;
> + ? ? ? }
>
> - ? ? ? ? ? ? ? if (sync_obj)
> - ? ? ? ? ? ? ? ? ? ? ? driver->sync_obj_flush(sync_obj, sync_obj_arg);
> - ? ? ? ? ? ? ? schedule_delayed_work(&bdev->wq,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ((HZ / 100) < 1) ? 1 : HZ / 100);
> - ? ? ? ? ? ? ? ret = 0;
> + ? ? ? /**
> + ? ? ? ?* We can re-check for sync object without taking
> + ? ? ? ?* the bo::lock since setting the sync object requires
> + ? ? ? ?* also bo::reserved. A busy object at this point may
> + ? ? ? ?* be caused by another thread recently starting an accelerated
> + ? ? ? ?* eviction.
> + ? ? ? ?*/
>
> - ? ? ? } else {
> + ? ? ? if (unlikely(bo->sync_obj)) {
> + ? ? ? ? ? ? ? atomic_set(&bo->reserved, 0);
> + ? ? ? ? ? ? ? wake_up_all(&bo->event_queue);
> ? ? ? ? ? ? ? ?spin_unlock(&glob->lru_lock);
^^ drop for retry path.
> - ? ? ? ? ? ? ? spin_unlock(&bo->lock);
> - ? ? ? ? ? ? ? ret = -EBUSY;
> + ? ? ? ? ? ? ? goto retry;
> ? ? ? ?}
>
> - ? ? ? return ret;
> + ? ? ? put_count = ttm_bo_del_from_lru(bo);
> + ? ? ? list_del_init(&bo->ddestroy);
> + ? ? ? ++put_count;
> +
> + ? ? ? ttm_bo_cleanup_memtype_use(bo);
^^ get into cleanup_memtype_use, which calls the ttm_bo_mem_put which
tries to take the lru lock inside
ttm_bo_man_put_node
Dave.
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote: > Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH: > > > So no need to clean it up for multiprocessor support. > > > > > > http://download.intel.com/design/chipsets/datashts/29067602.pdf > > > http://www.intel.com/design/chipsets/specupdt/29069403.pdf > > > > Great, we can just drop all calls to lock_kernel() and the like in the > > driver and be done with it, right? > > No, > > you still need to switch off preemption. Hm, how would you do that from within a driver? thanks, greg k-h
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote: > On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote: >> On Tue, Oct 19, 2010 at 10:40 AM, Greg KH wrote: >> > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote: >> >> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote: >> >> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote: >> >> >> >> >> >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs >> >> >> might end >> >> >> up not getting fixed at all, we can either mark them non-SMP or move >> >> >> them >> >> >> to drivers/staging once all the others are done. >> >> > >> >> > I recommend moving them to staging, and then retire them from there if >> >> > no one steps up to maintain them. >> >> >> >> I think this sets a bad precedent, these drivers work fine. Removing >> >> BKL from them is hard, and involves finding and booting hw that >> >> developers don't have much time/interest in at the moment. Anyone who >> >> has access to the i810 hw and has time to work out the locking has >> >> more important things to be doing with modern hw, however it doesn't >> >> mean we should just drop support for old drivers because they don't >> >> have active maintainers. Removing the BKL from the kernel is a great >> >> goal, but breaking userspace ABI by removing drivers isn't. >> > >> > Should we just restrict such drivers to only be able to build on UP >> > machines with preempt disabled so that the BKL could be safely removed >> > from them? >> > >> > Or what other idea do you have as to what could be done here? >> > >> > I do have access to this hardware, but its on an old single processor >> > laptop, so any work that it would take to help do this development, >> > really wouldn't be able to be tested to be valid at all. >> >> There is only very rare case where the i830 driver might get used with >> SMP and really I think that case is in the don't care place, since if >> you have that hw you probably should be using i915 on it anyways. > > So, there is no need for the i830 driver? ?Can it just be removed > because i915 works instead? No because it provides a different userspace ABI to the i915 driver to a different userspace X driver etc. like I'm sure the intersection of this driver and reality are getting quite limited, but its still a userspace ABI change and needs to be treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the old driver/API. >> So it really only leaves the problem case of what do distros do if we >> mark things as BROKEN_ON_SMP, since no distro builds UP kernels and >> when you boot the SMP kernels on UP they don't run as SMP so not >> having the driver load on those is a problem. Maybe we just need some >> sort of warn on smp if a smp unfriendly driver is loaded and we >> transition to SMP mode. Though this sounds like either (a) something >> we do now and I don't about it, (b) work. > > So you are saying that just because distros will never build such a > thing, we should keep it building for SMP mode? ?Why not prevent it from > being built and if a distro really cares, then they will pony up the > development to fix the driver up? Distros build the driver now even it it didn't work on SMP it wouldn't matter to the 99% of people who have this hw since it can't suppport SMP except in some corner cases. So not building for SMP is the same as just throwing it out of the kernel since most people don't run kernel.org kernels, and shouldn't have to just to get a driver for some piece of hardware that worked fine up until now. Look at this from a user who has this hardware pov, it works for them now with a distro kernel, us breaking it isn't going to help that user or make any distro care, its just going to screw over the people who are actually using it. > In other words, if someone really cares, then they will do the work, > otherwise why worry? ?Especially as it seems that no one here is going > to do it, right? Well the thing is doing the work right is a non-trivial task and just dropping support only screws the people using the hardware, it doesn't place any burden on the distro developers to fix it up. If people are really serious about making the BKL go away completely, I think the onus should be on them to fix the drivers not on the users who are using it, like I'm guessing if this gets broken the bug will end up in Novell or RH bugzilla in a year and nobody will ever see it. Dave.
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 02:24:53PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 18 Oct 2010 17:40:04 PDT, Greg KH said: > > > I do have access to this hardware, but its on an old single processor > > laptop, so any work that it would take to help do this development, > > really wouldn't be able to be tested to be valid at all. > > The i810 is a graphics chipset embedded on the memory controller, which > was designed for the Intel Pentium II, Pentium III, and Celeron CPUs. Page 8 > of the datasheet specifically says: > > Processor/Host Bus Support > - Optimized for the Intel Pentium II processor, Intel Pentium III processor, > and Intel > CeleronTM processor > - Supports processor 370-Pin Socket and SC242 > connectors > - Supports 32-Bit System Bus Addressing > - 4 deep in-order queue; 4 or 1 deep request queue > - Supports Uni-processor systems only > > So no need to clean it up for multiprocessor support. > > http://download.intel.com/design/chipsets/datashts/29067602.pdf > http://www.intel.com/design/chipsets/specupdt/29069403.pdf Great, we can just drop all calls to lock_kernel() and the like in the driver and be done with it, right? thanks, greg k-h
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 10:40 AM, Greg KH wrote: > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote: >> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote: >> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote: >> >> >> >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might >> >> end >> >> up not getting fixed at all, we can either mark them non-SMP or move them >> >> to drivers/staging once all the others are done. >> > >> > I recommend moving them to staging, and then retire them from there if >> > no one steps up to maintain them. >> >> I think this sets a bad precedent, these drivers work fine. Removing >> BKL from them is hard, and involves finding and booting hw that >> developers don't have much time/interest in at the moment. Anyone who >> has access to the i810 hw and has time to work out the locking has >> more important things to be doing with modern hw, however it doesn't >> mean we should just drop support for old drivers because they don't >> have active maintainers. Removing the BKL from the kernel is a great >> goal, but breaking userspace ABI by removing drivers isn't. > > Should we just restrict such drivers to only be able to build on UP > machines with preempt disabled so that the BKL could be safely removed > from them? > > Or what other idea do you have as to what could be done here? > > I do have access to this hardware, but its on an old single processor > laptop, so any work that it would take to help do this development, > really wouldn't be able to be tested to be valid at all. There is only very rare case where the i830 driver might get used with SMP and really I think that case is in the don't care place, since if you have that hw you probably should be using i915 on it anyways. So it really only leaves the problem case of what do distros do if we mark things as BROKEN_ON_SMP, since no distro builds UP kernels and when you boot the SMP kernels on UP they don't run as SMP so not having the driver load on those is a problem. Maybe we just need some sort of warn on smp if a smp unfriendly driver is loaded and we transition to SMP mode. Though this sounds like either (a) something we do now and I don't about it, (b) work. Dave. > > thanks, > > greg k-h >
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #25 from Tomasz Czapiewski 2010-10-19 09:52:23 PDT --- Created an attachment (id=39547) --> (https://bugs.freedesktop.org/attachment.cgi?id=39547) Screenshot during merged logs grab lightmap+deluxemapping xonotic13.jpg -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #24 from Tomasz Czapiewski 2010-10-19 09:51:57 PDT --- Created an attachment (id=39546) --> (https://bugs.freedesktop.org/attachment.cgi?id=39546) Screenshot during merged logs grab lightmap+deluxemapping xonotic12.jpg -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #25 from Tomasz Czapiewski 2010-10-19 09:52:23 PDT --- Created an attachment (id=39547) --> (https://bugs.freedesktop.org/attachment.cgi?id=39547) Screenshot during merged logs grab lightmap+deluxemapping xonotic13.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #23 from Tomasz Czapiewski 2010-10-19 09:51:36 PDT --- Created an attachment (id=39545) --> (https://bugs.freedesktop.org/attachment.cgi?id=39545) Screenshot during merged logs grab lightmap+deluxemapping xonotic11.jpg -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #24 from Tomasz Czapiewski 2010-10-19 09:51:57 PDT --- Created an attachment (id=39546) --> (https://bugs.freedesktop.org/attachment.cgi?id=39546) Screenshot during merged logs grab lightmap+deluxemapping xonotic12.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #23 from Tomasz Czapiewski 2010-10-19 09:51:36 PDT --- Created an attachment (id=39545) --> (https://bugs.freedesktop.org/attachment.cgi?id=39545) Screenshot during merged logs grab lightmap+deluxemapping xonotic11.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #22 from Tomasz Czapiewski 2010-10-19 09:50:42 PDT --- Created an attachment (id=39544) --> (https://bugs.freedesktop.org/attachment.cgi?id=39544) RADEON_DEBUG=fp,vp +game log lightmaps+deluxemapping -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #22 from Tomasz Czapiewski 2010-10-19 09:50:42 PDT --- Created an attachment (id=39544) --> (https://bugs.freedesktop.org/attachment.cgi?id=39544) RADEON_DEBUG=fp,vp +game log lightmaps+deluxemapping -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Tomasz Czapiewski changed: What|Removed |Added Attachment #39532|RADEON_DEBUG=fv,fp (STDOUT |RADEON_DEBUG=fp,vp (STDOUT description|[game] log) |[game] log) -- 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
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, 2010-10-19 at 15:36 +0200, Arnd Bergmann wrote: > [trimming Cc list] > > On Tuesday 19 October 2010, Steven Rostedt wrote: > > I think we also need to cover the PREEMPT case too. But that could be a > > compile time check, since you can't boot a preempt kernel and make it > > non preempt. > > Right. Can we turn the lock_kernel() into preempt_disable() in these > drivers when we know we never run on SMP? I'm not sure that will work. A holder of the BKL can call schedule or even a mutex. The schedule code will drop the BKL and re-enable preemption. Unless the code is known not to schedule while holding BKL, we would need to open code the preempt_enable() around the locations that the code may schedule. -- Steve
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #21 from Tomasz Czapiewski 2010-10-19 09:35:56 PDT --- Created an attachment (id=39542) --> (https://bugs.freedesktop.org/attachment.cgi?id=39542) Screenshot during merged logs grab xonotic10.jpg -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #20 from Tomasz Czapiewski 2010-10-19 09:35:22 PDT --- Created an attachment (id=39541) --> (https://bugs.freedesktop.org/attachment.cgi?id=39541) Screenshot during merged logs grab xonotic09.jpg -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #19 from Tomasz Czapiewski 2010-10-19 09:34:38 PDT --- Created an attachment (id=39540) --> (https://bugs.freedesktop.org/attachment.cgi?id=39540) Screenshot during merged logs grab xonotic08.jpg -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #18 from Tomasz Czapiewski 2010-10-19 09:33:44 PDT --- Created an attachment (id=39539) --> (https://bugs.freedesktop.org/attachment.cgi?id=39539) RADEON_DEBUG=fp,vp + game log 2>&1 merged -- 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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 08:39:58AM -0400, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > > I might be able to find some hardware still lying around here that uses
> > > > an
> > > > i810. Not sure unless I go hunting it. But I get the impression that if
> > > > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > > > distros offer a non-smp kernel as an installation option in case the
> > > > user
> > > > needs it? So in reality how big a problem is this?
> > >
> > > Not anymore, which is my old point of making a fuss. Nowadays in the
> > > modern distro world, we supply a single kernel that can at runtime
> > > decide if its running on SMP or UP and rewrite the text section
> > > appropriately with locks etc. Its like magic, and something like
> > > marking drivers as BROKEN_ON_SMP at compile time is really wrong when
> > > what you want now is a runtime warning if someone tries to hotplug a
> > > CPU with a known iffy driver loaded or if someone tries to load the
> > > driver when we are already in SMP mode.
> >
> > We could make the driver run-time non-SMP by adding
> >
> > if (num_present_cpus() > 1) {
> > pr_err("i810 no longer supports SMP\n");
> > return -EINVAL;
> > }
> >
> > to the init function. That would cover the vast majority of the
> > users of i810 hardware, I guess.
>
> I think we also need to cover the PREEMPT case too. But that could be a
> compile time check, since you can't boot a preempt kernel and make it
> non preempt.
>
There are enough nameless embedded vendors that have turned a preempt
kernel in to a non-preempt one at run-time by leaking the preempt count,
whether by design or not, so it's certainly possile :-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 Tomasz Czapiewski changed: What|Removed |Added Attachment #39532|RADEON_DEBUG=fv,fp (STDOUT |RADEON_DEBUG=fp,vp (STDOUT description|[game] log) |[game] log) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, 2010-10-19 at 15:36 +0200, Arnd Bergmann wrote: > [trimming Cc list] > > On Tuesday 19 October 2010, Steven Rostedt wrote: > > I think we also need to cover the PREEMPT case too. But that could be a > > compile time check, since you can't boot a preempt kernel and make it > > non preempt. > > Right. Can we turn the lock_kernel() into preempt_disable() in these > drivers when we know we never run on SMP? I'm not sure that will work. A holder of the BKL can call schedule or even a mutex. The schedule code will drop the BKL and re-enable preemption. Unless the code is known not to schedule while holding BKL, we would need to open code the preempt_enable() around the locations that the code may schedule. -- Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tuesday 19 October 2010, Arnd Bergmann wrote:
> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > I might be able to find some hardware still lying around here that uses an
> > > i810. Not sure unless I go hunting it. But I get the impression that if
> > > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > > distros offer a non-smp kernel as an installation option in case the user
> > > needs it? So in reality how big a problem is this?
> >
> > Not anymore, which is my old point of making a fuss. Nowadays in the
> > modern distro world, we supply a single kernel that can at runtime
> > decide if its running on SMP or UP and rewrite the text section
> > appropriately with locks etc. Its like magic, and something like
> > marking drivers as BROKEN_ON_SMP at compile time is really wrong when
> > what you want now is a runtime warning if someone tries to hotplug a
> > CPU with a known iffy driver loaded or if someone tries to load the
> > driver when we are already in SMP mode.
>
> We could make the driver run-time non-SMP by adding
>
> if (num_present_cpus() > 1) {
> pr_err("i810 no longer supports SMP\n");
> return -EINVAL;
> }
>
> to the init function. That would cover the vast majority of the
> users of i810 hardware, I guess.
Some research showed that Intel never support i810/i815 SMP setups,
but there was indeed one company (http://www.acorpusa.com at the time,
now owned by a domain squatter) that made i815E based dual Pentium-III
boards like this one: http://cgi.ebay.com/280319795096
The first person that can send me an authentic log file showing the
use of X.org with DRM on a 2.6.35 kernel with two processors on that
mainboard dated today or earlier gets a free upgrade to an AGP graphics
card of comparable or better 3D performance from me. Please include
the story how why you are running this machine with a new kernel.
i830 is harder, apparently some i865G boards support Pentium 4 with HT
and even later dual-core processors.
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > I might be able to find some hardware still lying around here that uses an
> > > i810. Not sure unless I go hunting it. But I get the impression that if
> > > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > > distros offer a non-smp kernel as an installation option in case the user
> > > needs it? So in reality how big a problem is this?
> >
> > Not anymore, which is my old point of making a fuss. Nowadays in the
> > modern distro world, we supply a single kernel that can at runtime
> > decide if its running on SMP or UP and rewrite the text section
> > appropriately with locks etc. Its like magic, and something like
> > marking drivers as BROKEN_ON_SMP at compile time is really wrong when
> > what you want now is a runtime warning if someone tries to hotplug a
> > CPU with a known iffy driver loaded or if someone tries to load the
> > driver when we are already in SMP mode.
>
> We could make the driver run-time non-SMP by adding
>
> if (num_present_cpus() > 1) {
> pr_err("i810 no longer supports SMP\n");
> return -EINVAL;
> }
>
> to the init function. That would cover the vast majority of the
> users of i810 hardware, I guess.
I think we also need to cover the PREEMPT case too. But that could be a
compile time check, since you can't boot a preempt kernel and make it
non preempt.
-- Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > I might be able to find some hardware still lying around here that uses an
> > i810. Not sure unless I go hunting it. But I get the impression that if
> > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > distros offer a non-smp kernel as an installation option in case the user
> > needs it? So in reality how big a problem is this?
>
> Not anymore, which is my old point of making a fuss. Nowadays in the
> modern distro world, we supply a single kernel that can at runtime
> decide if its running on SMP or UP and rewrite the text section
> appropriately with locks etc. Its like magic, and something like
> marking drivers as BROKEN_ON_SMP at compile time is really wrong when
> what you want now is a runtime warning if someone tries to hotplug a
> CPU with a known iffy driver loaded or if someone tries to load the
> driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() > 1) {
pr_err("i810 no longer supports SMP\n");
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
> I might be able to find some hardware still lying around here that uses an > i810. Not sure unless I go hunting it. But I get the impression that if > the kernel is a single-CPU kernel there is not any problem anyway? Don't > distros offer a non-smp kernel as an installation option in case the user > needs it? So in reality how big a problem is this? Not anymore, which is my old point of making a fuss. Nowadays in the modern distro world, we supply a single kernel that can at runtime decide if its running on SMP or UP and rewrite the text section appropriately with locks etc. Its like magic, and something like marking drivers as BROKEN_ON_SMP at compile time is really wrong when what you want now is a runtime warning if someone tries to hotplug a CPU with a known iffy driver loaded or if someone tries to load the driver when we are already in SMP mode. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Mon, 18 Oct 2010, Steven Rostedt wrote: > On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote: > > On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote: > > > > So, there is no need for the i830 driver? Can it just be removed > > > because i915 works instead? > > > > No because it provides a different userspace ABI to the i915 driver to > > a different userspace X driver etc. > > > > like I'm sure the intersection of this driver and reality are getting > > quite limited, but its still a userspace ABI change and needs to be > > treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the > > old driver/API. > > Thus, you are saying that this will break for people with older user > apps and have a newer kernel? > > > > > >> So it really only leaves the problem case of what do distros do if we > > >> mark things as BROKEN_ON_SMP, since no distro builds UP kernels and > > >> when you boot the SMP kernels on UP they don't run as SMP so not > > >> having the driver load on those is a problem. Maybe we just need some > > >> sort of warn on smp if a smp unfriendly driver is loaded and we > > >> transition to SMP mode. Though this sounds like either (a) something > > >> we do now and I don't about it, (b) work. > > > > > > So you are saying that just because distros will never build such a > > > thing, we should keep it building for SMP mode? Why not prevent it from > > > being built and if a distro really cares, then they will pony up the > > > development to fix the driver up? > > > > Distros build the driver now even it it didn't work on SMP it wouldn't > > matter to the 99% of people who have this hw since it can't suppport > > SMP except in some corner cases. So not building for SMP is the same > > as just throwing it out of the kernel since most people don't run > > kernel.org kernels, and shouldn't have to just to get a driver for > > some piece of hardware that worked fine up until now. > > Ah! Exactly! Thus, those that do not run kernel.org kernels are using a > distro kernel. Wont these same people use the distro userspace? That is, > if they have upgraded their kernel, most likely, they also update their > X interface. > > > > > Look at this from a user who has this hardware pov, it works for them > > now with a distro kernel, us breaking it isn't going to help that user > > or make any distro care, its just going to screw over the people who > > are actually using it. > > But they can use the i915 driver instead, because they are using the > newer userspace apps. > > > > > > In other words, if someone really cares, then they will do the work, > > > otherwise why worry? Especially as it seems that no one here is going > > > to do it, right? > > > > Well the thing is doing the work right is a non-trivial task and just > > dropping support only screws the people using the hardware, > > it doesn't place any burden on the distro developers to fix it up. If > > people are really serious about making the BKL go away completely, I > > think the onus should be on them to fix the drivers not on the users > > who are using it, like I'm guessing if this gets broken the bug will > > end up in Novell or RH bugzilla in a year and nobody will ever see it. > > Well the problem comes down to testing it. I don't know of any developer > that is removing the BKL that actually owns hardware to test out these > broken drivers. And for the change not being trivial, means that there's > no way to do in correctly. > > -- Steve I might be able to find some hardware still lying around here that uses an i810. Not sure unless I go hunting it. But I get the impression that if the kernel is a single-CPU kernel there is not any problem anyway? Don't distros offer a non-smp kernel as an installation option in case the user needs it? So in reality how big a problem is this? Theodore Kilgore ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
>> >> like I'm sure the intersection of this driver and reality are getting >> quite limited, but its still a userspace ABI change and needs to be >> treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the >> old driver/API. > > Thus, you are saying that this will break for people with older user > apps and have a newer kernel? There are two drivers here: i810 i830 The i830 case is the case I care less about since the ABI is only used by older userspace and i915 provides a replacement. the i810 case ABI is still in use today by distro userspaces that are still released, i.e. i810 is still used in F14, Ubuntu 10.10, RHEL6 Beta etc. I've snipped the rest of the argument on the grounds you are conflating two cases that aren't the same. > >> >> Well the thing is doing the work right is a non-trivial task and just >> dropping support only screws the people using the hardware, >> it doesn't place any burden on the distro developers to fix it up. If >> people are really serious about making the BKL go away completely, I >> think the onus should be on them to fix the drivers not on the users >> who are using it, like I'm guessing if this gets broken the bug will >> end up in Novell or RH bugzilla in a year and nobody will ever see it. > > Well the problem comes down to testing it. I don't know of any developer > that is removing the BKL that actually owns hardware to test out these > broken drivers. And for the change not being trivial, means that there's > no way to do in correctly. > So we can drop i830 using deprecation, however its pointless since the fix for i810 is the same fix for i830 if we can work out the fix. Well the way to do it correctly is make it so if the driver is initialised and we do an SMP transition we warn the users, or we make BROKEN_ON_SMP into a runtime thing that warns when the driver is loaded on an SMP system. The intersection of SMP and this hardware is definitely a very very small number and a lot more workable. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #21 from Tomasz Czapiewski 2010-10-19 09:35:56 PDT --- Created an attachment (id=39542) --> (https://bugs.freedesktop.org/attachment.cgi?id=39542) Screenshot during merged logs grab xonotic10.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote: > On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote: > > So, there is no need for the i830 driver? Can it just be removed > > because i915 works instead? > > No because it provides a different userspace ABI to the i915 driver to > a different userspace X driver etc. > > like I'm sure the intersection of this driver and reality are getting > quite limited, but its still a userspace ABI change and needs to be > treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the > old driver/API. Thus, you are saying that this will break for people with older user apps and have a newer kernel? > > >> So it really only leaves the problem case of what do distros do if we > >> mark things as BROKEN_ON_SMP, since no distro builds UP kernels and > >> when you boot the SMP kernels on UP they don't run as SMP so not > >> having the driver load on those is a problem. Maybe we just need some > >> sort of warn on smp if a smp unfriendly driver is loaded and we > >> transition to SMP mode. Though this sounds like either (a) something > >> we do now and I don't about it, (b) work. > > > > So you are saying that just because distros will never build such a > > thing, we should keep it building for SMP mode? Why not prevent it from > > being built and if a distro really cares, then they will pony up the > > development to fix the driver up? > > Distros build the driver now even it it didn't work on SMP it wouldn't > matter to the 99% of people who have this hw since it can't suppport > SMP except in some corner cases. So not building for SMP is the same > as just throwing it out of the kernel since most people don't run > kernel.org kernels, and shouldn't have to just to get a driver for > some piece of hardware that worked fine up until now. Ah! Exactly! Thus, those that do not run kernel.org kernels are using a distro kernel. Wont these same people use the distro userspace? That is, if they have upgraded their kernel, most likely, they also update their X interface. > > Look at this from a user who has this hardware pov, it works for them > now with a distro kernel, us breaking it isn't going to help that user > or make any distro care, its just going to screw over the people who > are actually using it. But they can use the i915 driver instead, because they are using the newer userspace apps. > > > In other words, if someone really cares, then they will do the work, > > otherwise why worry? Especially as it seems that no one here is going > > to do it, right? > > Well the thing is doing the work right is a non-trivial task and just > dropping support only screws the people using the hardware, > it doesn't place any burden on the distro developers to fix it up. If > people are really serious about making the BKL go away completely, I > think the onus should be on them to fix the drivers not on the users > who are using it, like I'm guessing if this gets broken the bug will > end up in Novell or RH bugzilla in a year and nobody will ever see it. Well the problem comes down to testing it. I don't know of any developer that is removing the BKL that actually owns hardware to test out these broken drivers. And for the change not being trivial, means that there's no way to do in correctly. -- Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #20 from Tomasz Czapiewski 2010-10-19 09:35:22 PDT --- Created an attachment (id=39541) --> (https://bugs.freedesktop.org/attachment.cgi?id=39541) Screenshot during merged logs grab xonotic09.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote: > On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote: >> On Tue, Oct 19, 2010 at 10:40 AM, Greg KH wrote: >> > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote: >> >> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote: >> >> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote: >> >> >> >> >> >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs >> >> >> might end >> >> >> up not getting fixed at all, we can either mark them non-SMP or move >> >> >> them >> >> >> to drivers/staging once all the others are done. >> >> > >> >> > I recommend moving them to staging, and then retire them from there if >> >> > no one steps up to maintain them. >> >> >> >> I think this sets a bad precedent, these drivers work fine. Removing >> >> BKL from them is hard, and involves finding and booting hw that >> >> developers don't have much time/interest in at the moment. Anyone who >> >> has access to the i810 hw and has time to work out the locking has >> >> more important things to be doing with modern hw, however it doesn't >> >> mean we should just drop support for old drivers because they don't >> >> have active maintainers. Removing the BKL from the kernel is a great >> >> goal, but breaking userspace ABI by removing drivers isn't. >> > >> > Should we just restrict such drivers to only be able to build on UP >> > machines with preempt disabled so that the BKL could be safely removed >> > from them? >> > >> > Or what other idea do you have as to what could be done here? >> > >> > I do have access to this hardware, but its on an old single processor >> > laptop, so any work that it would take to help do this development, >> > really wouldn't be able to be tested to be valid at all. >> >> There is only very rare case where the i830 driver might get used with >> SMP and really I think that case is in the don't care place, since if >> you have that hw you probably should be using i915 on it anyways. > > So, there is no need for the i830 driver? Can it just be removed > because i915 works instead? No because it provides a different userspace ABI to the i915 driver to a different userspace X driver etc. like I'm sure the intersection of this driver and reality are getting quite limited, but its still a userspace ABI change and needs to be treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the old driver/API. >> So it really only leaves the problem case of what do distros do if we >> mark things as BROKEN_ON_SMP, since no distro builds UP kernels and >> when you boot the SMP kernels on UP they don't run as SMP so not >> having the driver load on those is a problem. Maybe we just need some >> sort of warn on smp if a smp unfriendly driver is loaded and we >> transition to SMP mode. Though this sounds like either (a) something >> we do now and I don't about it, (b) work. > > So you are saying that just because distros will never build such a > thing, we should keep it building for SMP mode? Why not prevent it from > being built and if a distro really cares, then they will pony up the > development to fix the driver up? Distros build the driver now even it it didn't work on SMP it wouldn't matter to the 99% of people who have this hw since it can't suppport SMP except in some corner cases. So not building for SMP is the same as just throwing it out of the kernel since most people don't run kernel.org kernels, and shouldn't have to just to get a driver for some piece of hardware that worked fine up until now. Look at this from a user who has this hardware pov, it works for them now with a distro kernel, us breaking it isn't going to help that user or make any distro care, its just going to screw over the people who are actually using it. > In other words, if someone really cares, then they will do the work, > otherwise why worry? Especially as it seems that no one here is going > to do it, right? Well the thing is doing the work right is a non-trivial task and just dropping support only screws the people using the hardware, it doesn't place any burden on the distro developers to fix it up. If people are really serious about making the BKL go away completely, I think the onus should be on them to fix the drivers not on the users who are using it, like I'm guessing if this gets broken the bug will end up in Novell or RH bugzilla in a year and nobody will ever see it. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #19 from Tomasz Czapiewski 2010-10-19 09:34:38 PDT --- Created an attachment (id=39540) --> (https://bugs.freedesktop.org/attachment.cgi?id=39540) Screenshot during merged logs grab xonotic08.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote: > On Tue, Oct 19, 2010 at 10:40 AM, Greg KH wrote: > > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote: > >> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote: > >> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote: > >> >> > >> >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs > >> >> might end > >> >> up not getting fixed at all, we can either mark them non-SMP or move > >> >> them > >> >> to drivers/staging once all the others are done. > >> > > >> > I recommend moving them to staging, and then retire them from there if > >> > no one steps up to maintain them. > >> > >> I think this sets a bad precedent, these drivers work fine. Removing > >> BKL from them is hard, and involves finding and booting hw that > >> developers don't have much time/interest in at the moment. Anyone who > >> has access to the i810 hw and has time to work out the locking has > >> more important things to be doing with modern hw, however it doesn't > >> mean we should just drop support for old drivers because they don't > >> have active maintainers. Removing the BKL from the kernel is a great > >> goal, but breaking userspace ABI by removing drivers isn't. > > > > Should we just restrict such drivers to only be able to build on UP > > machines with preempt disabled so that the BKL could be safely removed > > from them? > > > > Or what other idea do you have as to what could be done here? > > > > I do have access to this hardware, but its on an old single processor > > laptop, so any work that it would take to help do this development, > > really wouldn't be able to be tested to be valid at all. > > There is only very rare case where the i830 driver might get used with > SMP and really I think that case is in the don't care place, since if > you have that hw you probably should be using i915 on it anyways. So, there is no need for the i830 driver? Can it just be removed because i915 works instead? > So it really only leaves the problem case of what do distros do if we > mark things as BROKEN_ON_SMP, since no distro builds UP kernels and > when you boot the SMP kernels on UP they don't run as SMP so not > having the driver load on those is a problem. Maybe we just need some > sort of warn on smp if a smp unfriendly driver is loaded and we > transition to SMP mode. Though this sounds like either (a) something > we do now and I don't about it, (b) work. So you are saying that just because distros will never build such a thing, we should keep it building for SMP mode? Why not prevent it from being built and if a distro really cares, then they will pony up the development to fix the driver up? In other words, if someone really cares, then they will do the work, otherwise why worry? Especially as it seems that no one here is going to do it, right? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #18 from Tomasz Czapiewski 2010-10-19 09:33:44 PDT --- Created an attachment (id=39539) --> (https://bugs.freedesktop.org/attachment.cgi?id=39539) RADEON_DEBUG=fp,vp + game log 2>&1 merged -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 10:40 AM, Greg KH wrote: > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote: >> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote: >> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote: >> >> >> >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might >> >> end >> >> up not getting fixed at all, we can either mark them non-SMP or move them >> >> to drivers/staging once all the others are done. >> > >> > I recommend moving them to staging, and then retire them from there if >> > no one steps up to maintain them. >> >> I think this sets a bad precedent, these drivers work fine. Removing >> BKL from them is hard, and involves finding and booting hw that >> developers don't have much time/interest in at the moment. Anyone who >> has access to the i810 hw and has time to work out the locking has >> more important things to be doing with modern hw, however it doesn't >> mean we should just drop support for old drivers because they don't >> have active maintainers. Removing the BKL from the kernel is a great >> goal, but breaking userspace ABI by removing drivers isn't. > > Should we just restrict such drivers to only be able to build on UP > machines with preempt disabled so that the BKL could be safely removed > from them? > > Or what other idea do you have as to what could be done here? > > I do have access to this hardware, but its on an old single processor > laptop, so any work that it would take to help do this development, > really wouldn't be able to be tested to be valid at all. There is only very rare case where the i830 driver might get used with SMP and really I think that case is in the don't care place, since if you have that hw you probably should be using i915 on it anyways. So it really only leaves the problem case of what do distros do if we mark things as BROKEN_ON_SMP, since no distro builds UP kernels and when you boot the SMP kernels on UP they don't run as SMP so not having the driver load on those is a problem. Maybe we just need some sort of warn on smp if a smp unfriendly driver is loaded and we transition to SMP mode. Though this sounds like either (a) something we do now and I don't about it, (b) work. Dave. > > thanks, > > greg k-h > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote: > On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote: > > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote: > >> > >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might > >> end > >> up not getting fixed at all, we can either mark them non-SMP or move them > >> to drivers/staging once all the others are done. > > > > I recommend moving them to staging, and then retire them from there if > > no one steps up to maintain them. > > I think this sets a bad precedent, these drivers work fine. Removing > BKL from them is hard, and involves finding and booting hw that > developers don't have much time/interest in at the moment. Anyone who > has access to the i810 hw and has time to work out the locking has > more important things to be doing with modern hw, however it doesn't > mean we should just drop support for old drivers because they don't > have active maintainers. Removing the BKL from the kernel is a great > goal, but breaking userspace ABI by removing drivers isn't. Should we just restrict such drivers to only be able to build on UP machines with preempt disabled so that the BKL could be safely removed from them? Or what other idea do you have as to what could be done here? I do have access to this hardware, but its on an old single processor laptop, so any work that it would take to help do this development, really wouldn't be able to be tested to be valid at all. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #17 from Tomasz Czapiewski 2010-10-19 09:25:41 PDT --- Created an attachment (id=39538) --> (https://bugs.freedesktop.org/attachment.cgi?id=39538) Screenshot during logs grab xonotic06.jpg -- 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
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > I might be able to find some hardware still lying around here that uses an
> > i810. Not sure unless I go hunting it. But I get the impression that if
> > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > distros offer a non-smp kernel as an installation option in case the user
> > needs it? So in reality how big a problem is this?
>
> Not anymore, which is my old point of making a fuss. Nowadays in the
> modern distro world, we supply a single kernel that can at runtime
> decide if its running on SMP or UP and rewrite the text section
> appropriately with locks etc. Its like magic, and something like
> marking drivers as BROKEN_ON_SMP at compile time is really wrong when
> what you want now is a runtime warning if someone tries to hotplug a
> CPU with a known iffy driver loaded or if someone tries to load the
> driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() > 1) {
pr_err("i810 no longer supports SMP\n");
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
Arnd
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #16 from Tomasz Czapiewski 2010-10-19 09:24:45 PDT --- Created an attachment (id=39537) --> (https://bugs.freedesktop.org/attachment.cgi?id=39537) Screenshot during logs grab xonotic05.jpg -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #17 from Tomasz Czapiewski 2010-10-19 09:25:41 PDT --- Created an attachment (id=39538) --> (https://bugs.freedesktop.org/attachment.cgi?id=39538) Screenshot during logs grab xonotic06.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #15 from Tomasz Czapiewski 2010-10-19 09:23:51 PDT --- Created an attachment (id=39536) --> (https://bugs.freedesktop.org/attachment.cgi?id=39536) Screenshot during logs grab xonotic04.jpg -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #14 from Tomasz Czapiewski 2010-10-19 09:22:56 PDT --- Created an attachment (id=39535) --> (https://bugs.freedesktop.org/attachment.cgi?id=39535) Screenshot during logs grab xonotic03.jpg -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #16 from Tomasz Czapiewski 2010-10-19 09:24:45 PDT --- Created an attachment (id=39537) --> (https://bugs.freedesktop.org/attachment.cgi?id=39537) Screenshot during logs grab xonotic05.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #13 from Tomasz Czapiewski 2010-10-19 09:21:53 PDT --- Created an attachment (id=39534) --> (https://bugs.freedesktop.org/attachment.cgi?id=39534) Screenshot during logs grab xonotic02.jpg -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #15 from Tomasz Czapiewski 2010-10-19 09:23:51 PDT --- Created an attachment (id=39536) --> (https://bugs.freedesktop.org/attachment.cgi?id=39536) Screenshot during logs grab xonotic04.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #12 from Tomasz Czapiewski 2010-10-19 09:20:59 PDT --- Created an attachment (id=39533) --> (https://bugs.freedesktop.org/attachment.cgi?id=39533) Screenshot during logs grab xonotic01.jpg -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #14 from Tomasz Czapiewski 2010-10-19 09:22:56 PDT --- Created an attachment (id=39535) --> (https://bugs.freedesktop.org/attachment.cgi?id=39535) Screenshot during logs grab xonotic03.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #13 from Tomasz Czapiewski 2010-10-19 09:21:53 PDT --- Created an attachment (id=39534) --> (https://bugs.freedesktop.org/attachment.cgi?id=39534) Screenshot during logs grab xonotic02.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 2/2] drm/ttm: Optimize delayed buffer destruction
On 10/19/2010 05:57 AM, Dave Airlie wrote: > On Thu, Oct 14, 2010 at 3:18 AM, Thomas Hellstrom > wrote: > >> This commit replaces the ttm_bo_cleanup_ref function with two new functions. >> One for the case where the bo is not yet on the delayed destroy list, and >> one for the case where the bo was on the delayed destroy list, at least at >> the time of call. This makes it possible to optimize the two cases somewhat. >> > I tried booting this today, but on radeon starting X hit a recursive > spin lock on the lru lock. > > (annotated below) > > New patches sent. /Thomas
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #12 from Tomasz Czapiewski 2010-10-19 09:20:59 PDT --- Created an attachment (id=39533) --> (https://bugs.freedesktop.org/attachment.cgi?id=39533) Screenshot during logs grab xonotic01.jpg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #11 from Tomasz Czapiewski 2010-10-19 09:17:32 PDT --- Created an attachment (id=39532) --> (https://bugs.freedesktop.org/attachment.cgi?id=39532) RADEON_DEBUG=fv,fp (STDOUT [game] log) -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #10 from Tomasz Czapiewski 2010-10-19 09:16:47 PDT --- Created an attachment (id=39531) --> (https://bugs.freedesktop.org/attachment.cgi?id=39531) RADEON_DEBUG=fp,vp (STDERR log) -- 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
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #11 from Tomasz Czapiewski 2010-10-19 09:17:32 PDT --- Created an attachment (id=39532) --> (https://bugs.freedesktop.org/attachment.cgi?id=39532) RADEON_DEBUG=fv,fp (STDOUT [game] log) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30960] [r300g][glsl] Texture corruption in Xonotic with lightmaps
https://bugs.freedesktop.org/show_bug.cgi?id=30960 --- Comment #10 from Tomasz Czapiewski 2010-10-19 09:16:47 PDT --- Created an attachment (id=39531) --> (https://bugs.freedesktop.org/attachment.cgi?id=39531) RADEON_DEBUG=fp,vp (STDERR log) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 2/2] drm/ttm: Optimize delayed buffer destruction
This commit replaces the ttm_bo_cleanup_ref function with two new functions.
One for the case where the bo is not yet on the delayed destroy list, and
one for the case where the bo was on the delayed destroy list, at least at
the time of call. This makes it possible to optimize the two cases somewhat.
It also enables the possibility to directly destroy buffers on the
delayed delete list when they are about to be evicted or swapped out.
Currently they were only evicted / swapped and destruction was left for the
delayed buffer destruction thread.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 171 ++
1 files changed, 107 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 6e75dab..2985fee 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -460,100 +460,123 @@ static void ttm_bo_cleanup_memtype_use(struct
ttm_buffer_object *bo)
wake_up_all(&bo->event_queue);
}
-
-/**
- * If bo idle, remove from delayed- and lru lists, and unref.
- * If not idle, and already on delayed list, do nothing.
- * If not idle, and not on delayed list, put on delayed list,
- * up the list_kref and schedule a delayed list check.
- */
-
-static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo, bool remove_all)
+static void ttm_bo_cleanup_refs_or_queue(struct ttm_buffer_object *bo)
{
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_bo_global *glob = bo->glob;
- struct ttm_bo_driver *driver = bdev->driver;
+ struct ttm_bo_driver *driver;
+ void *sync_obj;
+ void *sync_obj_arg;
+ int put_count;
int ret;
spin_lock(&bo->lock);
-retry:
- (void) ttm_bo_wait(bo, false, false, !remove_all);
-
+ (void) ttm_bo_wait(bo, false, false, true);
if (!bo->sync_obj) {
- int put_count;
-
- spin_unlock(&bo->lock);
spin_lock(&glob->lru_lock);
- ret = ttm_bo_reserve_locked(bo, false, !remove_all, false, 0);
/**
-* Someone else has the object reserved. Bail and retry.
+* Lock inversion between bo::reserve and bo::lock here,
+* but that's OK, since we're only trylocking.
*/
- if (unlikely(ret == -EBUSY)) {
- spin_unlock(&glob->lru_lock);
- spin_lock(&bo->lock);
- goto requeue;
- }
-
- /**
-* We can re-check for sync object without taking
-* the bo::lock since setting the sync object requires
-* also bo::reserved. A busy object at this point may
-* be caused by another thread starting an accelerated
-* eviction.
-*/
+ ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
- if (unlikely(bo->sync_obj)) {
- atomic_set(&bo->reserved, 0);
- wake_up_all(&bo->event_queue);
- spin_unlock(&glob->lru_lock);
- spin_lock(&bo->lock);
- if (remove_all)
- goto retry;
- else
- goto requeue;
- }
+ if (unlikely(ret == -EBUSY))
+ goto queue;
+ spin_unlock(&bo->lock);
put_count = ttm_bo_del_from_lru(bo);
- if (!list_empty(&bo->ddestroy)) {
- list_del_init(&bo->ddestroy);
- ++put_count;
- }
spin_unlock(&glob->lru_lock);
ttm_bo_cleanup_memtype_use(bo);
while (put_count--)
kref_put(&bo->list_kref, ttm_bo_ref_bug);
- return 0;
+ return;
+ } else {
+ spin_lock(&glob->lru_lock);
}
-requeue:
+queue:
+ sync_obj = bo->sync_obj;
+ sync_obj_arg = bo->sync_obj_arg;
+ driver = bdev->driver;
+
+ kref_get(&bo->list_kref);
+ list_add_tail(&bo->ddestroy, &bdev->ddestroy);
+ spin_unlock(&glob->lru_lock);
+ spin_unlock(&bo->lock);
+
+ if (sync_obj)
+ driver->sync_obj_flush(sync_obj, sync_obj_arg);
+ schedule_delayed_work(&bdev->wq,
+ ((HZ / 100) < 1) ? 1 : HZ / 100);
+}
+
+/**
+ * function ttm_bo_cleanup_refs
+ * If bo idle, remove from delayed- and lru lists, and unref.
+ * If not idle, do nothing.
+ *
+ * @interruptible Any sleeps should occur interruptibly.
+ * @no_wait_reserve Never wait for reserve. Return -EBUSY instead.
+ * @no_wait_gpu Never wait for gpu. Return -EBUSY instead.
+ */
+
+static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
+ bool interru
[PATCH 1/2] drm/ttm: Avoid using the ttm_mem_type_manager::put_locked function
Release the lru spinlock early.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 31 ++-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 10 --
include/drm/ttm/ttm_bo_driver.h |2 --
3 files changed, 6 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index fd8344d..6e75dab 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -439,36 +439,25 @@ out_err:
}
/**
- * Call bo::reserved and with the lru lock held.
+ * Call bo::reserved.
* Will release GPU memory type usage on destruction.
- * This is the place to put in driver specific hooks.
- * Will release the bo::reserved lock and the
- * lru lock on exit.
+ * This is the place to put in driver specific hooks to release
+ * driver private resources.
+ * Will release the bo::reserved lock.
*/
static void ttm_bo_cleanup_memtype_use(struct ttm_buffer_object *bo)
{
- struct ttm_bo_global *glob = bo->glob;
-
if (bo->ttm) {
-
- /**
-* Release the lru_lock, since we don't want to have
-* an atomic requirement on ttm_tt[unbind|destroy].
-*/
-
- spin_unlock(&glob->lru_lock);
ttm_tt_unbind(bo->ttm);
ttm_tt_destroy(bo->ttm);
bo->ttm = NULL;
- spin_lock(&glob->lru_lock);
}
- ttm_bo_mem_put_locked(bo, &bo->mem);
+ ttm_bo_mem_put(bo, &bo->mem);
atomic_set(&bo->reserved, 0);
wake_up_all(&bo->event_queue);
- spin_unlock(&glob->lru_lock);
}
@@ -533,6 +522,7 @@ retry:
list_del_init(&bo->ddestroy);
++put_count;
}
+ spin_unlock(&glob->lru_lock);
ttm_bo_cleanup_memtype_use(bo);
while (put_count--)
@@ -788,15 +778,6 @@ void ttm_bo_mem_put(struct ttm_buffer_object *bo, struct
ttm_mem_reg *mem)
}
EXPORT_SYMBOL(ttm_bo_mem_put);
-void ttm_bo_mem_put_locked(struct ttm_buffer_object *bo, struct ttm_mem_reg
*mem)
-{
- struct ttm_mem_type_manager *man = &bo->bdev->man[mem->mem_type];
-
- if (mem->mm_node)
- (*man->func->put_node_locked)(man, mem);
-}
-EXPORT_SYMBOL(ttm_bo_mem_put_locked);
-
/**
* Repeatedly evict memory from the LRU for @mem_type until we create enough
* space, or we've evicted everything and there isn't enough space.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index 35c97b2..7410c19 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -90,15 +90,6 @@ static void ttm_bo_man_put_node(struct ttm_mem_type_manager
*man,
}
}
-static void ttm_bo_man_put_node_locked(struct ttm_mem_type_manager *man,
- struct ttm_mem_reg *mem)
-{
- if (mem->mm_node) {
- drm_mm_put_block(mem->mm_node);
- mem->mm_node = NULL;
- }
-}
-
static int ttm_bo_man_init(struct ttm_mem_type_manager *man,
unsigned long p_size)
{
@@ -152,7 +143,6 @@ const struct ttm_mem_type_manager_func ttm_bo_manager_func
= {
ttm_bo_man_takedown,
ttm_bo_man_get_node,
ttm_bo_man_put_node,
- ttm_bo_man_put_node_locked,
ttm_bo_man_debug
};
EXPORT_SYMBOL(ttm_bo_manager_func);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index d0ff529..d01b4dd 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -214,8 +214,6 @@ struct ttm_mem_type_manager_func {
struct ttm_mem_reg *mem);
void (*put_node)(struct ttm_mem_type_manager *man,
struct ttm_mem_reg *mem);
- void (*put_node_locked)(struct ttm_mem_type_manager *man,
- struct ttm_mem_reg *mem);
void (*debug)(struct ttm_mem_type_manager *man, const char *prefix);
};
--
1.6.2.5
[PATCH 0/2] ttm patches for drm-next v2
These patches attempt to optimize the delayed destroy handling. The first patch removes the need for the newly introduced mem_put_locked callback. The second patch optimizes the delayed buffer destruction somewhat, but has not yet seen extensive testing. v2: As Dave Airlie pointed out, we actually forgot to drop the spinlock before calling ttm_bo_cleanup_memtype_use
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 4:43 AM, Greg KH wrote: > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote: >> >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end >> up not getting fixed at all, we can either mark them non-SMP or move them >> to drivers/staging once all the others are done. > > I recommend moving them to staging, and then retire them from there if > no one steps up to maintain them. I think this sets a bad precedent, these drivers work fine. Removing BKL from them is hard, and involves finding and booting hw that developers don't have much time/interest in at the moment. Anyone who has access to the i810 hw and has time to work out the locking has more important things to be doing with modern hw, however it doesn't mean we should just drop support for old drivers because they don't have active maintainers. Removing the BKL from the kernel is a great goal, but breaking userspace ABI by removing drivers isn't. Dave.
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
> On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > I might be able to find some hardware still lying around here that uses an
> > > i810. Not sure unless I go hunting it. But I get the impression that if
> > > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > > distros offer a non-smp kernel as an installation option in case the user
> > > needs it? So in reality how big a problem is this?
> >
> > Not anymore, which is my old point of making a fuss. Nowadays in the
> > modern distro world, we supply a single kernel that can at runtime
> > decide if its running on SMP or UP and rewrite the text section
> > appropriately with locks etc. Its like magic, and something like
> > marking drivers as BROKEN_ON_SMP at compile time is really wrong when
> > what you want now is a runtime warning if someone tries to hotplug a
> > CPU with a known iffy driver loaded or if someone tries to load the
> > driver when we are already in SMP mode.
>
> We could make the driver run-time non-SMP by adding
>
> if (num_present_cpus() > 1) {
> pr_err("i810 no longer supports SMP\n");
> return -EINVAL;
> }
>
> to the init function. That would cover the vast majority of the
> users of i810 hardware, I guess.
I think we also need to cover the PREEMPT case too. But that could be a
compile time check, since you can't boot a preempt kernel and make it
non preempt.
-- Steve
