i915 on 2.6.37-rc1: backlight always off after "xset dpms standby"
On Thu, Nov 11, 2010 at 22:10, Alex Riesen wrote: > an alternative way to reproduce it, is to just wait for screensaver. > Only the backlight is off, it is possible to see the image on LCD > matrix if you get the angle right. Bugzilla bug: https://bugzilla.kernel.org/show_bug.cgi?id=22672
3Dfx KMS board needed
On Wed, Nov 10, 2010 at 7:45 PM, James Simmons
wrote:
> Looking to work on the 3Dfx KMS driver I discovered that it is very
> difficult to find a motherboard that supports AGP of 3.3V. So I discovered
> that the only 3Dfx card that supports this is the 3dfx Voodoo 4 4500 AGP
> Card which also is difficult to find. Does anyone have this card to send
> to me or a old working system with a 3.3V AGP bus. Thanks.
Sorry, I'm having a hard time understanding. If motherboards with 3.3V
AGP are difficult to find, why are you looking for a Voodoo 4 4500?
You must mean that the Voodoo 4 4500 is the only AGP card that also
supports 1.5V AGP signaling?
I see a very cheap Voodoo 4 4500 on eBay in the UK. Item # 110610063423.
Also, the 4500 and 5500 come in PCI.
I had trouble finding a suitable board to use with Permedia hardware
this summer. The last to support 3.3V AGP were the Athlon MP
motherboards, e.g., Tyan S246{0,2,6,8,9}. But at least you get dual
processors.
For reference, the last 3.3V supporting video cards were the R300
series (specifically Radeon 9800 Pro, but not 9800 XT) and the GeForce
7950 GT. Not that any of that's specifically related to your query.
Thanks,
Matt
i915 on 2.6.37-rc1: backlight always off after "xset dpms standby"
Hi, an alternative way to reproduce it, is to just wait for screensaver. Only the backlight is off, it is possible to see the image on LCD matrix if you get the angle right. The system is the by now fairly old Dell XPS M1330, 64 bit kernel, KMS used (and works since 2.6.35), no 3D. There is sadly nothing interesting in dmesg or in XOrg.0.log (attached along with .config anyway). The repo's HEAD is at f6614b7bb405a9b35dd28baea989a749492c46b2. -- next part -- A non-text attachment was scrubbed... Name: dmesg Type: application/octet-stream Size: 57059 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20101111/4a09565b/attachment-0002.obj> -- next part -- A non-text attachment was scrubbed... Name: Xorg.0.log.old Type: application/x-trash Size: 25764 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2010/4a09565b/attachment-0001.old> -- next part -- A non-text attachment was scrubbed... Name: .config Type: application/octet-stream Size: 76521 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2010/4a09565b/attachment-0003.obj>
[Bug 31482] When trying to put the fullscreen window, data show and LCD laptop screen, the screen windwos screw up
https://bugs.freedesktop.org/show_bug.cgi?id=31482 --- Comment #5 from Alex Deucher 2010-11-11 21:15:22 PST --- I think the app does not update it's itself properly after the screen geometry changes. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31482] When trying to put the fullscreen window, data show and LCD laptop screen, the screen windwos screw up
https://bugs.freedesktop.org/show_bug.cgi?id=31482 --- Comment #4 from Maximiliano Casta??n 2010-11-11 18:50:55 PST --- http://img143.imageshack.us/img143/829/libreofficefail.png this is an example... this is how it look after a screen change, i mean the press of hardware button changin between modes, dual screen, single screen, etc... -- 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
Hi Rui,
First, thank's for your review and take care.
? ??2010-11-12 ? 09:31 +0800?Zhang Rui ???
> Hi, Lee,
>
> there are several regressions caused by this patch,
> http://marc.info/?l=linux-acpi=128872402020412=2
> http://marc.info/?l=linux-acpi=128858111022621=2
>
> Yes, We can fix it by "select INPUT if ACPI"/"select
> VIDEO_OUTPUT_CONTROL if ACPI".
> But IMO, STUB_POULSBO should not select ACPI_VIDEO at all,
> what do you think?
>
Yes, I agreed.
We can just remove the _select ACPI_VIDEO if ACPI_ because user should
select it when they want to use.
If CONFIG_ACPI_VIDEO doesn't select, the stub poulsbo just do _not_
thing but will have no any bad thing.
So, let's direct remove it from Kconfig. Should I submit patch again?
Thank's
Joey Lee
> thanks,
> rui
>
> On Wed, 2010-11-03 at 09:19 +0800, Zhang Rui wrote:
> > Hi, Lee,
> >
> > Sorry I missed this thread.
> >
> > 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.
> > >
> > If you want the acpi backlight control, why not set CONFIG_ACPI_VIDEO
> > driver directly?
> > The reason why i915 driver selects ACPI_VIDEO is that it needs some
> > cooperation between these two drivers during initialization, or else the
> > system may hang.
> >
> > thanks,
> > rui
> >
> > > Signed-off-by: Lee, Chun-Yi
> > > ---
> > > drivers/gpu/Makefile |2 +-
> > > drivers/gpu/stub/Kconfig | 13 +
> > > drivers/gpu/stub/Makefile |1 +
> > > drivers/gpu/stub/poulsbo.c | 63
> > >
> > > drivers/video/Kconfig |2 +
> > > 5 files changed, 80 insertions(+), 1 deletions(-)
> > > create mode 100644 drivers/gpu/stub/Kconfig
> > > create mode 100644 drivers/gpu/stub/Makefile
> > > create mode 100644 drivers/gpu/stub/poulsbo.c
> > >
> > > diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
> > > index 30879df..cc92778 100644
> > > --- a/drivers/gpu/Makefile
> > > +++ b/drivers/gpu/Makefile
> > > @@ -1 +1 @@
> > > -obj-y+= drm/ vga/
> > > +obj-y+= drm/ vga/ stub/
> > > diff --git a/drivers/gpu/stub/Kconfig b/drivers/gpu/stub/Kconfig
> > > new file mode 100644
> > > index 000..8f5a540
> > > --- /dev/null
> > > +++ b/drivers/gpu/stub/Kconfig
> > > @@ -0,0 +1,13 @@
> > > +config STUB_POULSBO
> > > + tristate "Intel GMA500 Stub Driver"
> > > + depends on PCI
> > > +# Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
> > > +# but for select to work, need to select ACPI_VIDEO's
> > > dependencies, ick
> > > +select ACPI_VIDEO if ACPI
> > > + help
> > > + Choose this option if you have a system that has Intel GMA500
> > > + (Poulsbo) integrated graphics. If M is selected, the module will
> > > + be called Poulsbo. This driver is a stub driver for Poulsbo that
> > > + will call poulsbo.ko to enable the acpi backlight control sysfs
> > > + entry file because there have no poulsbo native driver can support
> > > + intel opregion.
> > > diff --git a/drivers/gpu/stub/Makefile b/drivers/gpu/stub/Makefile
> > > new file mode 100644
> > > index 000..cd940cc
> > > --- /dev/null
> > > +++ b/drivers/gpu/stub/Makefile
> > > @@ -0,0 +1 @@
> > > +obj-$(CONFIG_STUB_POULSBO) += poulsbo.o
> > > diff --git a/drivers/gpu/stub/poulsbo.c b/drivers/gpu/stub/poulsbo.c
> > > new file mode 100644
> > > index 000..d8aa636
> > > --- /dev/null
> > > +++ b/drivers/gpu/stub/poulsbo.c
> > > @@ -0,0 +1,63 @@
> > > +/*
> > > + * Intel Poulsbo Stub driver
> > > + *
> > > + * Copyright (C) 2010 Novell
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > it
> > > + * under the terms of the GNU General Public License version 2 as
> > > published by
> > > + * the Free Software Foundation.
> > > + *
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define DRIVER_NAME "poulsbo"
> > > +
> > > +enum {
> > > + CHIP_PSB_8108 = 0,
> > > + CHIP_PSB_8109 = 1,
> > > +};
> > > +
> > > +static struct pci_device_id pciidlist[] = {
> > > + {0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8108}, \
> > > + {0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8109}, \
> > > + {0, 0, 0}
> > > +};
> > > +
> > > +static int poulsbo_probe(struct pci_dev *pdev, const struct
> > > pci_device_id *id)
> > > +{
> > > + return acpi_video_register();
> > > +}
> > > +
> > > +static void poulsbo_remove(struct pci_dev *pdev)
> > > +{
> > > + acpi_video_unregister();
> > > +}
> > > +
> > > +static struct pci_driver poulsbo_driver = {
> > > + .name = DRIVER_NAME,
> > > + .id_table = pciidlist,
> > > + .probe = poulsbo_probe,
> > > + .remove = poulsbo_remove,
> > > +};
> > > +
> > > +static int __init poulsbo_init(void)
> > > +{
> > > + return
[Bug 31569] New: [r300g] SIGSEGV src/mesa/main/api_loopback.c:1470
https://bugs.freedesktop.org/show_bug.cgi?id=31569
Summary: [r300g] SIGSEGV src/mesa/main/api_loopback.c:1470
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vlee at vmware.com
mesa: d18df9e336b5d2e68a4a6185f7b9d0d0c095c3c4 (master)
chipset: RV530 71C5 (ATI Radeon X1600)
system architecture: i686
libdrm-dev: 2.4.21-1ubuntu2.1
kernel version: 2.6.35-22-generic
Linux distribution: Ubuntu 10.10 i386
Machine model: iMac4,1
Run piglit provoking-vertex test.
$ ./bin/provoking-vertex
radeon: Successfully grabbed chipset info from kernel!
radeon: DRM version: 2.5.0 ID: 0x71c5 GB: 1 Z: 2
radeon: GART size: 509 MB VRAM size: 128 MB
radeon: HyperZ: NO
Mesa: Mesa 7.10-devel DEBUG build Nov 11 2010 12:16:33
Mesa: User error: GL_INVALID_ENUM in vbo_VertexAttribI1ui
Segmentation fault (core dumped)
(gdb) bt
#0 0x017e0d43 in loopback_VertexAttribI1uiv (index=36430, v=0x96) at
src/mesa/main/api_loopback.c:1470
#1 0x0804a5f0 in piglit_display () at
piglit/tests/general/provoking-vertex.c:90
#2 0x0804c6a7 in display () at piglit/tests/util/piglit-framework.c:52
#3 0x006f5820 in fghRedrawWindow (window=0x9c02058, enumerator=0xbfa6e598) at
freeglut_main.c:210
#4 fghcbDisplayWindow (window=0x9c02058, enumerator=0xbfa6e598) at
freeglut_main.c:227
#5 0x006f9660 in fgEnumWindows (enumCallback=0x6f5790 ,
enumerator=0xbfa6e598) at freeglut_structure.c:394
#6 0x006f5cdb in fghDisplayAll () at freeglut_main.c:249
#7 glutMainLoopEvent () at freeglut_main.c:1450
#8 0x006f6605 in glutMainLoop () at freeglut_main.c:1498
#9 0x0804c850 in main (argc=1, argv=0xbfa6e824) at
piglit/tests/util/piglit-framework.c:118
(gdb) frame 0
#0 0x017e0d43 in loopback_VertexAttribI1uiv (index=36430, v=0x96) at
src/mesa/main/api_loopback.c:1470
1470 ATTRIBI_1UI(index, v[0]);
(gdb) l
1465}
1466
1467static void GLAPIENTRY
1468loopback_VertexAttribI1uiv(GLuint index, const GLuint *v)
1469{
1470 ATTRIBI_1UI(index, v[0]);
1471}
1472
1473static void GLAPIENTRY
1474loopback_VertexAttribI4bv(GLuint index, const GLbyte *v)
(gdb) print *v
Cannot access memory at address 0x96
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 31568] New: [r300g] SIGSEGV src/mesa/vbo/vbo_exec_array.c:1154
https://bugs.freedesktop.org/show_bug.cgi?id=31568
Summary: [r300g] SIGSEGV src/mesa/vbo/vbo_exec_array.c:1154
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vlee at vmware.com
mesa: d18df9e336b5d2e68a4a6185f7b9d0d0c095c3c4 (master)
chipset: RV530 71C5 (ATI Radeon X1600)
system architecture: i686
libdrm-dev: 2.4.21-1ubuntu2.1
kernel version: 2.6.35-22-generic
Linux distribution: Ubuntu 10.10 i386
Machine model: iMac4,1
Run piglit bgra-sec-color-pointer test.
$ ./bin/bgra-sec-color-pointer-test
...
Segmentation fault (core dumped)
(gdb) bt
#0 0x0183d923 in vbo_exec_MultiDrawElements (mode=3, count=0x1401, type=4,
indices=0x804f1d0, primcount=143224880) at src/mesa/vbo/vbo_exec_array.c:1154
#1 0x0804a622 in piglit_display () at
piglit/tests/general/bgra-sec-color-pointer.c:82
#2 0x0804c847 in display () at piglit/tests/util/piglit-framework.c:52
#3 0x00755820 in fghRedrawWindow (window=0x88a2060, enumerator=0xbfd29688) at
freeglut_main.c:210
#4 fghcbDisplayWindow (window=0x88a2060, enumerator=0xbfd29688) at
freeglut_main.c:227
#5 0x00759660 in fgEnumWindows (enumCallback=0x755790 ,
enumerator=0xbfd29688) at freeglut_structure.c:394
#6 0x00755cdb in fghDisplayAll () at freeglut_main.c:249
#7 glutMainLoopEvent () at freeglut_main.c:1450
#8 0x00756605 in glutMainLoop () at freeglut_main.c:1498
#9 0x0804c9f0 in main (argc=1, argv=0xbfd29914) at
piglit/tests/util/piglit-framework.c:118
(gdb) frame 0
#0 0x0183d923 in vbo_exec_MultiDrawElements (mode=3, count=0x1401, type=4,
indices=0x804f1d0, primcount=143224880) at src/mesa/vbo/vbo_exec_array.c:1154
1154 if (!_mesa_validate_DrawElements(ctx, mode, count[i], type,
indices[i],
(gdb) l
1149 GLint i;
1150
1151 ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(ctx);
1152
1153 for (i = 0; i < primcount; i++) {
1154 if (!_mesa_validate_DrawElements(ctx, mode, count[i], type,
indices[i],
1155 0))
1156 return;
1157 }
1158
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 31567] New: [r300] swrast/s_span.c:1267: _swrast_write_rgba_span: Assertion `rb->PutValues' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=31567 Summary: [r300] swrast/s_span.c:1267: _swrast_write_rgba_span: Assertion `rb->PutValues' failed. Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: vlee at vmware.com mesa: d18df9e336b5d2e68a4a6185f7b9d0d0c095c3c4 (master) chipset: RV530 71C5 (ATI Radeon X1600) system architecture: i686 libdrm-dev: 2.4.21-1ubuntu2.1 kernel version: 2.6.35-22-generic Linux distribution: Ubuntu 10.10 i386 Machine model: iMac4,1 Run piglit fbo-scissor-bitmap test. $ ./bin/fbo-scissor-bitmap ... radeonSetSpanFunctions: bad format: 0x0002 radeonSetSpanFunctions: bad format: 0x0002 fbo-scissor-bitmap: swrast/s_span.c:1267: _swrast_write_rgba_span: Assertion `rb->PutValues' failed. (gdb) bt #0 0x00808416 in __kernel_vsyscall () #1 0x00b0a941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x00b0de42 in abort () at abort.c:92 #3 0x00b038e8 in __assert_fail (assertion=0x122ec21 "rb->PutValues", file=0x124138c "swrast/s_span.c", line=1267, function=0x124170c "_swrast_write_rgba_span") at assert.c:81 #4 0x0110fa87 in _swrast_write_rgba_span (ctx=0x9550460, span=0xbfe29174) at swrast/s_span.c:1267 #5 0x010fe66d in _swrast_Bitmap (ctx=0x9550460, px=224, py=229, width=64, height=53, unpack=0x955f130, bitmap=0x804e200 "") at swrast/s_bitmap.c:128 #6 0x011a3084 in _mesa_Bitmap (width=64, height=53, xorig=0, yorig=0, xmove=0, ymove=0, bitmap=0x804e200 "") at main/drawpix.c:246 #7 0x0804ad06 in draw_and_test (destination=0x804e1d6 "FBO", drawable_width=512, drawable_height=512) at piglit/tests/fbo/fbo-scissor-bitmap.c:185 #8 0x0804b9b9 in piglit_display () at piglit/tests/fbo/fbo-scissor-bitmap.c:370 #9 0x0804d9b3 in display () at piglit/tests/util/piglit-framework.c:52 #10 0x00370820 in fghRedrawWindow (window=0x9533058, enumerator=0xbfe29d98) at freeglut_main.c:210 #11 fghcbDisplayWindow (window=0x9533058, enumerator=0xbfe29d98) at freeglut_main.c:227 #12 0x00374660 in fgEnumWindows (enumCallback=0x370790 , enumerator=0xbfe29d98) at freeglut_structure.c:394 #13 0x00370cdb in fghDisplayAll () at freeglut_main.c:249 #14 glutMainLoopEvent () at freeglut_main.c:1450 #15 0x00371605 in glutMainLoop () at freeglut_main.c:1498 #16 0x0804db5c in main (argc=1, argv=0xbfe2a024) at piglit/tests/util/piglit-framework.c:118 (gdb) frame 4 #4 0x0110fa87 in _swrast_write_rgba_span (ctx=0x9550460, span=0xbfe29174) at swrast/s_span.c:1267 1267 ASSERT(rb->PutValues); -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31566] New: [r300] swrast/s_span.c:1349: _swrast_read_rgba_span: Assertion `rb->GetRow' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=31566 Summary: [r300] swrast/s_span.c:1349: _swrast_read_rgba_span: Assertion `rb->GetRow' failed. Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: vlee at vmware.com mesa: d18df9e336b5d2e68a4a6185f7b9d0d0c095c3c4 (master) chipset: RV530 71C5 (ATI Radeon X1600) system architecture: i686 libdrm-dev: 2.4.21-1ubuntu2.1 kernel version: 2.6.35-22-generic Linux distribution: Ubuntu 10.10 i386 Machine model: iMac4,1 Run piglit fbo-nodepth-test. $ ./bin/fbo-nodepth-test ... radeonSetSpanFunctions: bad format: 0x0002 radeonSetSpanFunctions: bad format: 0x0002 fbo-nodepth-test: swrast/s_span.c:1349: _swrast_read_rgba_span: Assertion `rb->GetRow' failed. (gdb) bt #0 0x008e6416 in __kernel_vsyscall () #1 0x001aa941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x001ade42 in abort () at abort.c:92 #3 0x001a38e8 in __assert_fail (assertion=0x1244bee "rb->GetRow", file=0x125738c "swrast/s_span.c", line=1349, function=0x12576f5 "_swrast_read_rgba_span") at assert.c:81 #4 0x01123088 in _swrast_read_rgba_span (ctx=0x9f43460, rb=0xa290458, n=128, x=0, y=6, dstType=5126, rgba=0xb754f008) at swrast/s_span.c:1349 #5 0x0112251a in read_rgba_pixels (ctx=0x9f43460, x=0, y=0, width=128, height=128, format=6407, type=5126, packing=0x9f52110, pixels=) at swrast/s_readpix.c:341 #6 _swrast_ReadPixels (ctx=0x9f43460, x=0, y=0, width=128, height=128, format=6407, type=5126, packing=0x9f52110, pixels=) at swrast/s_readpix.c:509 #7 0x0101c76d in radeonReadPixels (ctx=0x9f43460, x=0, y=0, width=128, height=128, format=6407, type=5126, pack=0x9f52110, pixels=0xb7315008) at radeon_pixel_read.c:221 #8 0x0109558b in _mesa_ReadPixels (x=0, y=0, width=128, height=128, format=6407, type=5126, pixels=0xb7315008) at main/readpix.c:232 #9 0x0804aeaa in piglit_probe_rect_rgb (x=0, y=0, w=128, h=128, expected=0xbfe29940) at piglit/tests/util/piglit-util.c:278 #10 0x0804a766 in piglit_display () at piglit/tests/fbo/fbo-nodepth-test.c:79 #11 0x0804c7e7 in display () at piglit/tests/util/piglit-framework.c:52 #12 0x006ab820 in fghRedrawWindow (window=0x9f26058, enumerator=0xbfe29a48) at freeglut_main.c:210 #13 fghcbDisplayWindow (window=0x9f26058, enumerator=0xbfe29a48) at freeglut_main.c:227 #14 0x006af660 in fgEnumWindows (enumCallback=0x6ab790 , enumerator=0xbfe29a48) at freeglut_structure.c:394 #15 0x006abcdb in fghDisplayAll () at freeglut_main.c:249 #16 glutMainLoopEvent () at freeglut_main.c:1450 #17 0x006ac605 in glutMainLoop () at freeglut_main.c:1498 #18 0x0804c990 in main (argc=1, argv=0xbfe29cd4) at piglit/tests/util/piglit-framework.c:118 (gdb) frame 4 #4 0x01123088 in _swrast_read_rgba_span (ctx=0x9f43460, rb=0xa290458, n=128, x=0, y=6, dstType=5126, rgba=0xb754f008) at swrast/s_span.c:1349 1349 ASSERT(rb->GetRow); -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31565] New: [r300] radeon_texture.c:136: radeon_teximage_map: Assertion `!image->base.Data' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=31565
Summary: [r300] radeon_texture.c:136: radeon_teximage_map:
Assertion `!image->base.Data' failed.
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vlee at vmware.com
mesa: d18df9e336b5d2e68a4a6185f7b9d0d0c095c3c4 (master)
chipset: RV530 71C5 (ATI Radeon X1600)
system architecture: i686
libdrm-dev: 2.4.21-1ubuntu2.1
kernel version: 2.6.35-22-generic
Linux distribution: Ubuntu 10.10 i386
Machine model: iMac4,1
Run piglit fbo-blit.
$ ./bin/fbo-blit
...
radeonSetSpanFunctions: bad format: 0x0002
radeonSetSpanFunctions: bad format: 0x0002
fbo-blit: radeon_texture.c:136: radeon_teximage_map: Assertion
`!image->base.Data' failed.
(gdb) bt
#0 0x0020c416 in __kernel_vsyscall ()
#1 0x00354941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x00357e42 in abort () at abort.c:92
#3 0x0034d8e8 in __assert_fail (assertion=0x1123ce5 "!image->base.Data",
file=0x1123cb6 "radeon_texture.c", line=136, function=0x1123f06
"radeon_teximage_map") at assert.c:81
#4 0x00f2fb0f in radeon_teximage_map (image=0x9884200, write_enable=1 '\001')
at radeon_texture.c:136
#5 0x00f22fb0 in radeon_map_unmap_framebuffer (ctx=,
fb=0x9884350, map=1 '\001') at radeon_span.c:1047
#6 0x00f2ebc4 in radeonSpanRenderStart (ctx=0x9526458) at radeon_span.c:1085
#7 0x01027253 in swrast_render_start (ctx=0x9526458, x=10, y=10, width=10,
height=10, format=6407, type=5126, packing=0x9535108, pixels=0x98b7508) at
swrast/s_context.h:268
#8 _swrast_ReadPixels (ctx=0x9526458, x=10, y=10, width=10, height=10,
format=6407, type=5126, packing=0x9535108, pixels=0x98b7508) at
swrast/s_readpix.c:473
#9 0x00f2176d in radeonReadPixels (ctx=0x9526458, x=10, y=10, width=10,
height=10, format=6407, type=5126, pack=0x9535108, pixels=0x98b7508) at
radeon_pixel_read.c:221
#10 0x00f9a58b in _mesa_ReadPixels (x=10, y=10, width=10, height=10,
format=6407, type=5126, pixels=0x98b7508) at main/readpix.c:232
#11 0x0804b53e in piglit_probe_rect_rgb (x=10, y=10, w=10, h=10,
expected=0xbfde7a00) at piglit/tests/util/piglit-util.c:278
#12 0x0804a890 in verify_color_rect (start_x=10, start_y=10, w=20, h=20) at
/piglit/tests/fbo/fbo-blit.c:110
#13 0x0804ae31 in run_test () at piglit/tests/fbo/fbo-blit.c:193
#14 0x0804aeb6 in piglit_display () at /piglit/tests/fbo/fbo-blit.c:206
#15 0x0804ce7b in display () at piglit/tests/util/piglit-framework.c:52
#16 0x00d79820 in fghRedrawWindow (window=0x9509050, enumerator=0xbfde7b68) at
freeglut_main.c:210
#17 fghcbDisplayWindow (window=0x9509050, enumerator=0xbfde7b68) at
freeglut_main.c:227
#18 0x00d7d660 in fgEnumWindows (enumCallback=0xd79790 ,
enumerator=0xbfde7b68) at freeglut_structure.c:394
#19 0x00d79cdb in fghDisplayAll () at freeglut_main.c:249
#20 glutMainLoopEvent () at freeglut_main.c:1450
#21 0x00d7a605 in glutMainLoop () at freeglut_main.c:1498
#22 0x0804d024 in main (argc=1, argv=0xbfde7df4) at
piglit/tests/util/piglit-framework.c:118
(gdb) frame 4
#4 0x00f2fb0f in radeon_teximage_map (image=0x9884200, write_enable=1 '\001')
at radeon_texture.c:136
136assert(!image->base.Data);
(gdb) l
131radeon_print(RADEON_TEXTURE, RADEON_VERBOSE,
132"%s(img %p), write_enable %s.\n",
133__func__, image,
134write_enable ? "true": "false");
135if (image->mt) {
136assert(!image->base.Data);
137
138radeon_bo_map(image->mt->bo, write_enable);
139teximage_set_map_data(image);
140}
(gdb) print image->base
$1 = {InternalFormat = 6408, _BaseFormat = 6408, TexFormat = 2, Border = 0,
Width = 64, Height = 64, Depth = 1, Width2 = 64, Height2 = 64, Depth2 = 1,
WidthLog2 = 6, HeightLog2 = 6, DepthLog2 = 0,
MaxLog2 = 6, WidthScale = 64, HeightScale = 64, DepthScale = 1, IsClientData
= 0 '\000', _IsPowerOfTwo = 1 '\001', TexObject = 0x9884690, FetchTexelc =
0x10cfc60 ,
FetchTexelf = 0x10c9dc0 , RowStride = 64,
ImageOffsets = 0x9884278, Data = 0xb77cb000, DriverData = 0x0}
(gdb) print image->base.Data
$2 = (GLvoid *) 0xb77cb000
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[PATCH 0/1][RFC] drm/ttm Improved io_mem_reserve / io_mem_free_calling
On 11/11/2010 04:27 PM, Jerome Glisse wrote: > On Thu, Nov 11, 2010 at 3:41 AM, Thomas Hellstrom > wrote: > >> The following patch is really intended for the next merge window. >> >> RFC: >> 1) Are there any implementations of driver::io_mem_reserve today that can't >> use >> the fastpath? >> 2) Can we put an atomic requirement on driver::io_mem_reserve / >> driver::io_mem_free? >> >> The patch improves on the io_mem_reserve / io_mem_free calling sequences by >> introducing a fastpath and an optional eviction mechanism. >> >> The fastpath is enabled by default and is switched off by the driver setting >> struct ttm_mem_type_manager::io_reserve_fastpath to false on mem type init. >> With the fastpath no locking occurs, and io_mem_free is never called. >> I'm not sure if there are any implementations today that could not use the >> fastpath. >> >> As mentioned in the patch, if the fastpath is disabled, calls to >> io_mem_reserve and io_mem_free are exactly balanced, and refcounted within >> struct ttm_mem_reg so that io_mem_reserve should never be called recursively >> for the same struct ttm_mem_reg. >> Locking is required to make sure that ptes are never present on when the >> underlying memory region is not reserved. Currently I'm using >> man::io_reserve_mutex for this. Can we use a spinlock? That would require >> io_mem_reserve and io_mem_free to be atomic. >> >> Optionally, there is an eviction mechanism that is activated by setting >> struct ttm_mem_type_manager::use_io_reserve_lru to true when initialized. >> If the eviction mechanism is activated, and io_mem_reserve returns -EAGAIN, >> it will attempt to kill user-space mappings to free up reserved regions. >> Kernel mappings (ttm_bo_kmap) are not affected. >> >> > Radeon can use fast path, i think nouveau can too. I am not sure we > can consider io_mem_reserve as atomic. Use case i fear is GPU with > remappable apperture i don't know what kind of code we would need for > that and it might sleep. Thought my first guess is that it likely can > be done atomicly. > In that case, I think I will change it to a spinlock, with a code comment that it can be changed to a mutex later if it turns out to be very hard / impossible to implement atomic operations. Another possible concern is the execution of umap_mapping_range() that may in some cases be long. Perhaps too long to use a spinlock. > Quick review of the patch looks good, i will try to take a closer look latter. > > Cheers, > Jerome Glisse > Great. Thanks, Thomas
[Bug 31482] When trying to put the fullscreen window, data show and LCD laptop screen, the screen windwos screw up
https://bugs.freedesktop.org/show_bug.cgi?id=31482 --- Comment #3 from Maximiliano Casta??n 2010-11-11 17:43:40 PST --- Created an attachment (id=40220) --> (https://bugs.freedesktop.org/attachment.cgi?id=40220) /var/log/messages the file is compressed because it's 1200 KB size -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31482] When trying to put the fullscreen window, data show and LCD laptop screen, the screen windwos screw up
https://bugs.freedesktop.org/show_bug.cgi?id=31482 --- Comment #2 from Maximiliano Casta??n 2010-11-11 17:38:00 PST --- Seems to be managed by a kernel driver... don't know which Nov 11 22:30:15 localhost kernel: [74389.406194] atkbd serio0: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0). Nov 11 22:30:15 localhost kernel: [74389.406205] atkbd serio0: Use 'setkeycodes e078 ' to make it known. Nov 11 22:30:15 localhost kernel: [74389.413290] atkbd serio0: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0). Nov 11 22:30:15 localhost kernel: [74389.413298] atkbd serio0: Use 'setkeycodes e078 ' to make it known. Nov 11 22:30:17 localhost kernel: [74392.162654] atkbd serio0: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0). Nov 11 22:30:17 localhost kernel: [74392.162660] atkbd serio0: Use 'setkeycodes e078 ' to make it known. Nov 11 22:30:17 localhost kernel: [74392.169601] atkbd serio0: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0). Nov 11 22:30:17 localhost kernel: [74392.169607] atkbd serio0: Use 'setkeycodes e078 ' to make it known. i'm on Fedora 14, xrandr 1.3.3 Linux localhost.localdomain 2.6.35.6-48.fc14.x86_64 #1 SMP Fri Oct 22 15:36:08 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Name: xorg-x11-drv-ati Arch: x86_64 Version : 6.13.1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30188] X server crashes with a SIGBUS on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=30188 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #29 from Alex Deucher 2010-11-11 17:08:18 PST --- fixes pushed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 0/1][RFC] drm/ttm Improved io_mem_reserve / io_mem_free_calling
On Thu, Nov 11, 2010 at 3:41 AM, Thomas Hellstrom wrote: > The following patch is really intended for the next merge window. > > RFC: > 1) Are there any implementations of driver::io_mem_reserve today that can't > use > the fastpath? > 2) Can we put an atomic requirement on driver::io_mem_reserve / > driver::io_mem_free? > > The patch improves on the io_mem_reserve / io_mem_free calling sequences by > introducing a fastpath and an optional eviction mechanism. > > The fastpath is enabled by default and is switched off by the driver setting > struct ttm_mem_type_manager::io_reserve_fastpath to false on mem type init. > With the fastpath no locking occurs, and io_mem_free is never called. > I'm not sure if there are any implementations today that could not use the > fastpath. > > As mentioned in the patch, if the fastpath is disabled, calls to > io_mem_reserve and io_mem_free are exactly balanced, and refcounted within > struct ttm_mem_reg so that io_mem_reserve should never be called recursively > for the same struct ttm_mem_reg. > Locking is required to make sure that ptes are never present on when the > underlying memory region is not reserved. Currently I'm using > man::io_reserve_mutex for this. Can we use a spinlock? That would require > io_mem_reserve and io_mem_free to be atomic. > > Optionally, there is an eviction mechanism that is activated by setting > struct ttm_mem_type_manager::use_io_reserve_lru to true when initialized. > If the eviction mechanism is activated, and io_mem_reserve returns -EAGAIN, > it will attempt to kill user-space mappings to free up reserved regions. > Kernel mappings (ttm_bo_kmap) are not affected. > Radeon can use fast path, i think nouveau can too. I am not sure we can consider io_mem_reserve as atomic. Use case i fear is GPU with remappable apperture i don't know what kind of code we would need for that and it might sleep. Thought my first guess is that it likely can be done atomicly. Quick review of the patch looks good, i will try to take a closer look latter. Cheers, Jerome Glisse
[PATCH] drm/ttm: Fix up a theoretical deadlock
A process suspended waiting for a higher sequence or no sequence to unreserve,
a bo may be beaten to the reservation by a process with a lower sequence.
In that case the first process should give up trying to reserve and
return -EAGAIN. In order for that to happen, we must wake waiting processes
when we change sequence, so that they have a chance to detect the new
sequence.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3ca77dc..148a322 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -224,6 +224,9 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
int ret;
while (unlikely(atomic_cmpxchg(>reserved, 0, 1) != 0)) {
+ /**
+* Deadlock avoidance for multi-bo reserving.
+*/
if (use_sequence && bo->seq_valid &&
(sequence - bo->val_seq < (1 << 31))) {
return -EAGAIN;
@@ -241,6 +244,14 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
}
if (use_sequence) {
+ /**
+* Wake up waiters that may need to recheck for deadlock,
+* if we decreased the sequence number.
+*/
+ if (unlikely((bo->val_seq - sequence < (1 << 31))
+|| !bo->seq_valid))
+ wake_up_all(>event_queue);
+
bo->val_seq = sequence;
bo->seq_valid = true;
} else {
--
1.6.2.5
[PATCH 1/1] drm/ttm: Fix up io_mem_reserve / io_mem_free calling
This patch attempts to fix up shortcomings with the current calling
sequences.
1) There's a fastpath where no locking occurs and only io_mem_reserved is
called to obtain needed info for mapping. The fastpath is set per
memory type manager.
2) If the fastpath is disabled, io_mem_reserve and io_mem_free will be exactly
balanced and not called recursively for the same struct ttm_mem_reg.
3) Optionally the driver can choose to enable a per memory type manager LRU
eviction mechanism that, when io_mem_reserve returns -EAGAIN will attempt
to kill user-space mappings of memory in that manager to free up needed
resources
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 44 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 129 +
drivers/gpu/drm/ttm/ttm_bo_vm.c | 23 --
include/drm/ttm/ttm_bo_api.h |6 ++-
include/drm/ttm/ttm_bo_driver.h | 104 --
5 files changed, 226 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 336a39d..489bde8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -361,8 +361,13 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
int ret = 0;
if (old_is_pci || new_is_pci ||
- ((mem->placement & bo->mem.placement & TTM_PL_MASK_CACHING) == 0))
- ttm_bo_unmap_virtual(bo);
+ ((mem->placement & bo->mem.placement & TTM_PL_MASK_CACHING) == 0)) {
+ ret = ttm_mem_io_lock(old_man, true);
+ if (unlikely(ret != 0))
+ goto out_err;
+ ttm_bo_unmap_virtual_locked(bo);
+ ttm_mem_io_unlock(old_man);
+ }
/*
* Create and bind a ttm if required.
@@ -451,7 +456,6 @@ static void ttm_bo_cleanup_memtype_use(struct
ttm_buffer_object *bo)
ttm_tt_destroy(bo->ttm);
bo->ttm = NULL;
}
-
ttm_bo_mem_put(bo, >mem);
atomic_set(>reserved, 0);
@@ -651,6 +655,7 @@ static void ttm_bo_release(struct kref *kref)
struct ttm_buffer_object *bo =
container_of(kref, struct ttm_buffer_object, kref);
struct ttm_bo_device *bdev = bo->bdev;
+ struct ttm_mem_type_manager *man = >man[bo->mem.mem_type];
if (likely(bo->vm_node != NULL)) {
rb_erase(>vm_rb, >addr_space_rb);
@@ -658,6 +663,9 @@ static void ttm_bo_release(struct kref *kref)
bo->vm_node = NULL;
}
write_unlock(>vm_lock);
+ ttm_mem_io_lock(man, false);
+ ttm_mem_io_free_vm(bo);
+ ttm_mem_io_unlock(man);
ttm_bo_cleanup_refs_or_queue(bo);
kref_put(>list_kref, ttm_bo_release_list);
write_lock(>vm_lock);
@@ -714,7 +722,8 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool
interruptible,
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
- evict_mem.bus.io_reserved = false;
+ evict_mem.bus.io_reserved_vm = false;
+ evict_mem.bus.io_reserved_count = 0;
placement.fpfn = 0;
placement.lpfn = 0;
@@ -1051,7 +1060,8 @@ int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
mem.num_pages = bo->num_pages;
mem.size = mem.num_pages << PAGE_SHIFT;
mem.page_alignment = bo->mem.page_alignment;
- mem.bus.io_reserved = false;
+ mem.bus.io_reserved_vm = false;
+ mem.bus.io_reserved_count = 0;
/*
* Determine where to move the buffer.
*/
@@ -1171,6 +1181,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
INIT_LIST_HEAD(>lru);
INIT_LIST_HEAD(>ddestroy);
INIT_LIST_HEAD(>swap);
+ INIT_LIST_HEAD(>io_reserve_lru);
bo->bdev = bdev;
bo->glob = bdev->glob;
bo->type = type;
@@ -1180,7 +1191,8 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo->mem.num_pages = bo->num_pages;
bo->mem.mm_node = NULL;
bo->mem.page_alignment = page_alignment;
- bo->mem.bus.io_reserved = false;
+ bo->mem.bus.io_reserved_vm = false;
+ bo->mem.bus.io_reserved_count = 0;
bo->buffer_start = buffer_start & PAGE_MASK;
bo->priv_flags = 0;
bo->mem.placement = (TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED);
@@ -1354,6 +1366,10 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned
type,
BUG_ON(type >= TTM_NUM_MEM_TYPES);
man = >man[type];
BUG_ON(man->has_type);
+ man->io_reserve_fastpath = true;
+ man->use_io_reserve_lru = false;
+ mutex_init(>io_reserve_mutex);
+ INIT_LIST_HEAD(>io_reserve_lru);
ret = bdev->driver->init_mem_type(bdev, type, man);
if (ret)
@@ -1560,7 +1576,7 @@ bool ttm_mem_reg_is_pci(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
return true;
}
-void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
+void ttm_bo_unmap_virtual_locked(struct
[PATCH 0/1][RFC] drm/ttm Improved io_mem_reserve / io_mem_free_calling
The following patch is really intended for the next merge window. RFC: 1) Are there any implementations of driver::io_mem_reserve today that can't use the fastpath? 2) Can we put an atomic requirement on driver::io_mem_reserve / driver::io_mem_free? The patch improves on the io_mem_reserve / io_mem_free calling sequences by introducing a fastpath and an optional eviction mechanism. The fastpath is enabled by default and is switched off by the driver setting struct ttm_mem_type_manager::io_reserve_fastpath to false on mem type init. With the fastpath no locking occurs, and io_mem_free is never called. I'm not sure if there are any implementations today that could not use the fastpath. As mentioned in the patch, if the fastpath is disabled, calls to io_mem_reserve and io_mem_free are exactly balanced, and refcounted within struct ttm_mem_reg so that io_mem_reserve should never be called recursively for the same struct ttm_mem_reg. Locking is required to make sure that ptes are never present on when the underlying memory region is not reserved. Currently I'm using man::io_reserve_mutex for this. Can we use a spinlock? That would require io_mem_reserve and io_mem_free to be atomic. Optionally, there is an eviction mechanism that is activated by setting struct ttm_mem_type_manager::use_io_reserve_lru to true when initialized. If the eviction mechanism is activated, and io_mem_reserve returns -EAGAIN, it will attempt to kill user-space mappings to free up reserved regions. Kernel mappings (ttm_bo_kmap) are not affected.
[PATCH 2/2] nouveau: Acknowledge HPD irq in handler, not bottom half
On Wed, 2010-11-10 at 18:01 -0500, Andrew Lutomirski wrote: > On Wed, Nov 10, 2010 at 5:55 PM, Maarten Maathuis > wrote: > > On Wed, Nov 10, 2010 at 11:51 PM, Andrew Lutomirski wrote: > >> On Wed, Nov 10, 2010 at 5:35 PM, Ben Skeggs wrote: > >>> On Wed, 2010-11-10 at 17:25 -0500, Andrew Lutomirski wrote: > On Wed, Nov 10, 2010 at 5:10 PM, Ben Skeggs > wrote: > > On Wed, 2010-11-10 at 16:32 -0500, Andy Lutomirski wrote: > >> The old code generated an interrupt storm bad enough to completely > >> take down my system. > >> > >> This only fixes the bits that are defined nouveau_regs.h. Newer > >> hardware > >> uses another register that isn't described, and I don't have that > >> hardware > >> to test. > > Thanks for looking at this. I'll take a closer look at the problem > > today and see what I can come up with too, that'll work with the newer > > hardware too. > > It should be as simple as adding an hpd1 field to the hpd_state and > making exactly the same change. (It would be nice to put the register > definitions into nouveau_regs.h as well -- I didn't really want to > muck around with a bunch of magic numbers that I can't test.) > >>> Yes, it is. I can confirm the problem on another card, but it doesn't > >>> actually cause any crashes here. If you can rework the patch to support > >>> the newer chips too, that'd be great. > >>> > >>> As for magic numbers, the register names for those regs are wrong > >>> anyway. The joy of reverse-engineering the support. It doesn't really > >>> matter if you want to stick to them or go back to "magic" numbers. > >> > >> That explains why INTR and CTRL seemed backwards :) I'll leave the > >> magic numbers for the 0xe07? stuff. > > > > Perhaps remove the bad definitions from the reg file, or rename them > > to UNKsomething? > > Well, they're known. One is hotplug detect enable (unless the code is > wrong) and the other is hotplug interrupt status. That's also not correct, if anything the most accurate names so far would probably be: #define NV_PGPIO_INTR_EN_0 0xe050 #define NV_PGPIO_INTR_00xe054 #define NV_PGPIO_INTR_EN_1 0xe070 #define NV_PGPIO_INTR_10xe074 PGPIO is a guess, and there's other stuff in that range too, but it's definitely *not* PCONNECTOR. Anyway, this doesn't matter. Whatever change in names can happen in nouveau git and make it's way to Linus from there, the fix for nouveau git is already going to be different enough from what'll apply on Linus' tree right now. My opinion is, lets just fix the bug in mainline (without register naming) and fix the naming etc in nouveau git. Ben. > > > > --Andy
[PATCH 2/2] nouveau: Acknowledge HPD irq in handler, not bottom half
On Wed, 2010-11-10 at 17:51 -0500, Andrew Lutomirski wrote: > On Wed, Nov 10, 2010 at 5:35 PM, Ben Skeggs wrote: > > On Wed, 2010-11-10 at 17:25 -0500, Andrew Lutomirski wrote: > >> On Wed, Nov 10, 2010 at 5:10 PM, Ben Skeggs wrote: > >> > On Wed, 2010-11-10 at 16:32 -0500, Andy Lutomirski wrote: > >> >> The old code generated an interrupt storm bad enough to completely > >> >> take down my system. > >> >> > >> >> This only fixes the bits that are defined nouveau_regs.h. Newer > >> >> hardware > >> >> uses another register that isn't described, and I don't have that > >> >> hardware > >> >> to test. > >> > Thanks for looking at this. I'll take a closer look at the problem > >> > today and see what I can come up with too, that'll work with the newer > >> > hardware too. > >> > >> It should be as simple as adding an hpd1 field to the hpd_state and > >> making exactly the same change. (It would be nice to put the register > >> definitions into nouveau_regs.h as well -- I didn't really want to > >> muck around with a bunch of magic numbers that I can't test.) > > Yes, it is. I can confirm the problem on another card, but it doesn't > > actually cause any crashes here. If you can rework the patch to support > > the newer chips too, that'd be great. > > > > As for magic numbers, the register names for those regs are wrong > > anyway. The joy of reverse-engineering the support. It doesn't really > > matter if you want to stick to them or go back to "magic" numbers. > > That explains why INTR and CTRL seemed backwards :) I'll leave the > magic numbers for the 0xe07? stuff. That sounds good, it'll all get a cleanup at some point and switched to "proper" (well, our best guess, you'd have to ask NVIDIA about the real ones) names. Ben. > > Also, I accidentally dropped the "& enabled_bits" part -- I'll put that back. > > Patch to follow after I boot and test it here. > > --Andy
[PATCH 2/2] nouveau: Acknowledge HPD irq in handler, not bottom half
On Wed, 2010-11-10 at 17:25 -0500, Andrew Lutomirski wrote:
> On Wed, Nov 10, 2010 at 5:10 PM, Ben Skeggs wrote:
> > On Wed, 2010-11-10 at 16:32 -0500, Andy Lutomirski wrote:
> >> The old code generated an interrupt storm bad enough to completely
> >> take down my system.
> >>
> >> This only fixes the bits that are defined nouveau_regs.h. Newer hardware
> >> uses another register that isn't described, and I don't have that hardware
> >> to test.
> > Thanks for looking at this. I'll take a closer look at the problem
> > today and see what I can come up with too, that'll work with the newer
> > hardware too.
>
> It should be as simple as adding an hpd1 field to the hpd_state and
> making exactly the same change. (It would be nice to put the register
> definitions into nouveau_regs.h as well -- I didn't really want to
> muck around with a bunch of magic numbers that I can't test.)
Yes, it is. I can confirm the problem on another card, but it doesn't
actually cause any crashes here. If you can rework the patch to support
the newer chips too, that'd be great.
As for magic numbers, the register names for those regs are wrong
anyway. The joy of reverse-engineering the support. It doesn't really
matter if you want to stick to them or go back to "magic" numbers.
Ben.
>
> I tried writing 0x to the display IRQ control in the handler
> to explicitly acknowledge the IRQ, but either I did it wrong or it had
> no effect.
>
> I imagine that this explains the unreproducible crashes I had on F13 as well.
>
> --Andy
>
> >
> > Ben.
> >>
> >> Signed-off-by: Andy Lutomirski
> >> Cc:
> >> ---
> >> drivers/gpu/drm/nouveau/nouveau_drv.h |5 +
> >> drivers/gpu/drm/nouveau/nouveau_irq.c |1 +
> >> drivers/gpu/drm/nouveau/nv50_display.c | 17 +
> >> 3 files changed, 19 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
> >> b/drivers/gpu/drm/nouveau/nouveau_drv.h
> >> index b1be617..b6c62cc 100644
> >> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> >> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> >> @@ -531,6 +531,11 @@ struct drm_nouveau_private {
> >> struct work_struct irq_work;
> >> struct work_struct hpd_work;
> >>
> >> + struct {
> >> + spinlock_t lock;
> >> + uint32_t hpd0_bits;
> >> + } hpd_state;
> >> +
> >> struct list_head vbl_waiting;
> >>
> >> struct {
> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
> >> b/drivers/gpu/drm/nouveau/nouveau_irq.c
> >> index 794b0ee..b62a601 100644
> >> --- a/drivers/gpu/drm/nouveau/nouveau_irq.c
> >> +++ b/drivers/gpu/drm/nouveau/nouveau_irq.c
> >> @@ -52,6 +52,7 @@ nouveau_irq_preinstall(struct drm_device *dev)
> >> if (dev_priv->card_type >= NV_50) {
> >> INIT_WORK(_priv->irq_work, nv50_display_irq_handler_bh);
> >> INIT_WORK(_priv->hpd_work, nv50_display_irq_hotplug_bh);
> >> + spin_lock_init(_priv->hpd_state.lock);
> >> INIT_LIST_HEAD(_priv->vbl_waiting);
> >> }
> >> }
> >> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
> >> b/drivers/gpu/drm/nouveau/nv50_display.c
> >> index 83a7d27..0df08e3 100644
> >> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> >> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> >> @@ -1014,7 +1014,12 @@ nv50_display_irq_hotplug_bh(struct work_struct
> >> *work)
> >> uint32_t unplug_mask, plug_mask, change_mask;
> >> uint32_t hpd0, hpd1 = 0;
> >>
> >> - hpd0 = nv_rd32(dev, NV50_PCONNECTOR_HOTPLUG_CTRL) & nv_rd32(dev,
> >> NV50_PCONNECTOR_HOTPLUG_INTR);
> >> + spin_lock_irq(_priv->hpd_state.lock);
> >> + hpd0 = dev_priv->hpd_state.hpd0_bits;
> >> + dev_priv->hpd_state.hpd0_bits = 0;
> >> + spin_unlock_irq(_priv->hpd_state.lock);
> >> +
> >> + hpd0 &= nv_rd32(dev, NV50_PCONNECTOR_HOTPLUG_INTR);
> >> if (dev_priv->chipset >= 0x90)
> >> hpd1 = nv_rd32(dev, 0xe074) & nv_rd32(dev, 0xe070);
> >>
> >> @@ -1058,7 +1063,6 @@ nv50_display_irq_hotplug_bh(struct work_struct *work)
> >> helper->dpms(connector->encoder, DRM_MODE_DPMS_OFF);
> >> }
> >>
> >> - nv_wr32(dev, NV50_PCONNECTOR_HOTPLUG_CTRL, nv_rd32(dev,
> >> NV50_PCONNECTOR_HOTPLUG_CTRL));
> >> if (dev_priv->chipset >= 0x90)
> >> nv_wr32(dev, 0xe074, nv_rd32(dev, 0xe074));
> >>
> >> @@ -1072,8 +1076,13 @@ nv50_display_irq_handler(struct drm_device *dev)
> >> uint32_t delayed = 0;
> >>
> >> if (nv_rd32(dev, NV50_PMC_INTR_0) & NV50_PMC_INTR_0_HOTPLUG) {
> >> - if (!work_pending(_priv->hpd_work))
> >> - queue_work(dev_priv->wq, _priv->hpd_work);
> >> + uint32_t hpd0_bits = nv_rd32(dev,
> >> NV50_PCONNECTOR_HOTPLUG_CTRL);
> >> + nv_wr32(dev, NV50_PCONNECTOR_HOTPLUG_CTRL, hpd0_bits);
> >> + spin_lock(_priv->hpd_state.lock);
> >> + dev_priv->hpd_state.hpd0_bits |= hpd0_bits;
> >> +
[Bug 31549] Commit c2c55547dc36f404e29dbc9253166f90df6783af makes CS checker unhappy and causes rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=31549 Keith Whitwell changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Keith Whitwell 2010-11-11 08:23:24 PST --- commit 6baad55f157387d0bb44144680a96bc32280109f Author: Keith Whitwell Date: Thu Nov 11 14:26:52 2010 + r600g: guard experimental s3tc code with R600_ENABLE_S3TC -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31152] Please backport r200 fix to r100 and r300c
https://bugs.freedesktop.org/show_bug.cgi?id=31152 --- Comment #8 from Alex Deucher 2010-11-11 08:12:23 PST --- (In reply to comment #7) > Which kernel is this going to get merged into? Could I figure this out from > the > ticket? These are mesa fixes, not kernel fixes. They are in mesa master and the 7.9 branch so they'll show up in mesa 7.10 and 7.9.1. -- 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] nouveau: Acknowledge HPD irq in handler, not bottom half
On Wed, 2010-11-10 at 16:32 -0500, Andy Lutomirski wrote:
> The old code generated an interrupt storm bad enough to completely
> take down my system.
>
> This only fixes the bits that are defined nouveau_regs.h. Newer hardware
> uses another register that isn't described, and I don't have that hardware
> to test.
Thanks for looking at this. I'll take a closer look at the problem
today and see what I can come up with too, that'll work with the newer
hardware too.
Ben.
>
> Signed-off-by: Andy Lutomirski
> Cc:
> ---
> drivers/gpu/drm/nouveau/nouveau_drv.h |5 +
> drivers/gpu/drm/nouveau/nouveau_irq.c |1 +
> drivers/gpu/drm/nouveau/nv50_display.c | 17 +
> 3 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
> b/drivers/gpu/drm/nouveau/nouveau_drv.h
> index b1be617..b6c62cc 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> @@ -531,6 +531,11 @@ struct drm_nouveau_private {
> struct work_struct irq_work;
> struct work_struct hpd_work;
>
> + struct {
> + spinlock_t lock;
> + uint32_t hpd0_bits;
> + } hpd_state;
> +
> struct list_head vbl_waiting;
>
> struct {
> diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
> b/drivers/gpu/drm/nouveau/nouveau_irq.c
> index 794b0ee..b62a601 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_irq.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_irq.c
> @@ -52,6 +52,7 @@ nouveau_irq_preinstall(struct drm_device *dev)
> if (dev_priv->card_type >= NV_50) {
> INIT_WORK(_priv->irq_work, nv50_display_irq_handler_bh);
> INIT_WORK(_priv->hpd_work, nv50_display_irq_hotplug_bh);
> + spin_lock_init(_priv->hpd_state.lock);
> INIT_LIST_HEAD(_priv->vbl_waiting);
> }
> }
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index 83a7d27..0df08e3 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -1014,7 +1014,12 @@ nv50_display_irq_hotplug_bh(struct work_struct *work)
> uint32_t unplug_mask, plug_mask, change_mask;
> uint32_t hpd0, hpd1 = 0;
>
> - hpd0 = nv_rd32(dev, NV50_PCONNECTOR_HOTPLUG_CTRL) & nv_rd32(dev,
> NV50_PCONNECTOR_HOTPLUG_INTR);
> + spin_lock_irq(_priv->hpd_state.lock);
> + hpd0 = dev_priv->hpd_state.hpd0_bits;
> + dev_priv->hpd_state.hpd0_bits = 0;
> + spin_unlock_irq(_priv->hpd_state.lock);
> +
> + hpd0 &= nv_rd32(dev, NV50_PCONNECTOR_HOTPLUG_INTR);
> if (dev_priv->chipset >= 0x90)
> hpd1 = nv_rd32(dev, 0xe074) & nv_rd32(dev, 0xe070);
>
> @@ -1058,7 +1063,6 @@ nv50_display_irq_hotplug_bh(struct work_struct *work)
> helper->dpms(connector->encoder, DRM_MODE_DPMS_OFF);
> }
>
> - nv_wr32(dev, NV50_PCONNECTOR_HOTPLUG_CTRL, nv_rd32(dev,
> NV50_PCONNECTOR_HOTPLUG_CTRL));
> if (dev_priv->chipset >= 0x90)
> nv_wr32(dev, 0xe074, nv_rd32(dev, 0xe074));
>
> @@ -1072,8 +1076,13 @@ nv50_display_irq_handler(struct drm_device *dev)
> uint32_t delayed = 0;
>
> if (nv_rd32(dev, NV50_PMC_INTR_0) & NV50_PMC_INTR_0_HOTPLUG) {
> - if (!work_pending(_priv->hpd_work))
> - queue_work(dev_priv->wq, _priv->hpd_work);
> + uint32_t hpd0_bits = nv_rd32(dev, NV50_PCONNECTOR_HOTPLUG_CTRL);
> + nv_wr32(dev, NV50_PCONNECTOR_HOTPLUG_CTRL, hpd0_bits);
> + spin_lock(_priv->hpd_state.lock);
> + dev_priv->hpd_state.hpd0_bits |= hpd0_bits;
> + spin_unlock(_priv->hpd_state.lock);
> +
> + queue_work(dev_priv->wq, _priv->hpd_work);
> }
>
> while (nv_rd32(dev, NV50_PMC_INTR_0) & NV50_PMC_INTR_0_DISPLAY) {
[Bug 31152] Please backport r200 fix to r100 and r300c
https://bugs.freedesktop.org/show_bug.cgi?id=31152 --- Comment #7 from Alexei 2010-11-11 08:09:41 PST --- Which kernel is this going to get merged into? Could I figure this out from the ticket? Thanks everybody! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31152] Please backport r200 fix to r100 and r300c
https://bugs.freedesktop.org/show_bug.cgi?id=31152 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Alex Deucher 2010-11-11 07:22:47 PST --- I guess we can close this then. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31549] Commit c2c55547dc36f404e29dbc9253166f90df6783af makes CS checker unhappy and causes rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=31549 --- Comment #1 from Keith Whitwell 2010-11-11 05:47:41 PST --- OK, I'll protect this with a debug option defaulting to off. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31549] New: Commit c2c55547dc36f404e29dbc9253166f90df6783af makes CS checker unhappy and causes rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=31549 Summary: Commit c2c55547dc36f404e29dbc9253166f90df6783af makes CS checker unhappy and causes rendering issues Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: mikhail.vorozhtsov at gmail.com Commit c2c55547dc36f404e29dbc9253166f90df6783af "r600g: attempt to turn on DXTn formats" makes my dmesg (both 2.6.36 and d-r-t, the hardware is RV730XT) full of radeon :01:00.0: r600_check_texture_resource:1127 texture invalid format 50 [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! and Compiz plugins like Scale/App switcher are completely broken. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31152] Please backport r200 fix to r100 and r300c
https://bugs.freedesktop.org/show_bug.cgi?id=31152 --- Comment #5 from Fabio Pedretti 2010-11-11 00:50:26 PST --- Looks like r300c was fixed by the following commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d8eef5196fcd6f51e443d4dfa0fda8aadc668f9f -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
3Dfx KMS board needed
Looking to work on the 3Dfx KMS driver I discovered that it is very difficult to find a motherboard that supports AGP of 3.3V. So I discovered that the only 3Dfx card that supports this is the 3dfx Voodoo 4 4500 AGP Card which also is difficult to find. Does anyone have this card to send to me or a old working system with a 3.3V AGP bus. Thanks.
[git pull] drm fixes
Hi Linus, This is a bunch of drm fixes, it includes couple of regression fixers on radeon that could cause oops/memory corruptions, along with few Intel fixers. It also fixes the Kconfig for the poulsbo stub. I've started taking Chris's pull requests now, so all the intel drm changes should start coming via my tree always now, unless they are pretty exceptional or I'm away. Dave. The following changes since commit a7bcf21e60c73cb7f7c13fad928967d7e47c3cac: Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2010-11-08 11:54:53 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Alex Deucher (5): drm/radeon/kms/evergreen: add missing pm.vblank_sync update in vbl handler drm/radeon/kms: make the connector code less verbose drm/radeon/kms: don't disable shared encoders on pre-DCE3 display blocks drm/radeon/kms: add support for clock/data path routers drm/radeon/kms: fix thermal sensor reporting on rv6xx Chris Wilson (7): drm/i915: Flush read-only buffers from the active list upon idle as well drm/i915: Apply big hammer to serialise buffer access between rings drm/i915: Allow powersave modparam to be adjusted at runtime. drm/i915: SNB BLT workaround drm/i915: Avoid might_fault during pwrite whilst holding our mutex drm/i915/ringbuffer: Use the HEAD auto-reporting mechanism drm/i915: Fix LVDS fixed-mode regression from 219adae1 Christoph Fritz (1): drm/i915: opregion_setup: iounmap correct address Dan Carpenter (1): i915: signedness bug in check_overlay_src() Dave Airlie (1): Merge branch 'drm-intel-fixes' of git://git.kernel.org/.../ickle/drm-intel Ingo Molnar (1): drm/stub/Kconfig: fix Kconfig for stub driver. Jesse Barnes (1): drm/i915: Fix the graphics frequency clamping at init and when IPS is active. Joe Perches (3): drivers/gpu/drm/vmwgfx: Fix k.alloc switched arguments drivers/gpu/drm: Update WARN uses drivers/gpu: Use vzalloc Kulikov Vasiliy (1): drm: vmwgfx: fix information leak to userland Kyle McMartin (1): i915: reprogram power monitoring registers on resume Michel D?nzer (1): drm/radeon/kms: Fix retrying ttm_bo_init() after it failed once. Sam Tygier (1): DRM: ignore invalid EDID extensions Takashi Iwai (1): drm/i915: Fix typo from "Enable DisplayPort Audio" Thomas Hellstrom (10): drm/ttm: Documentation update drm/ttm: Use private locks for the default bo range manager drm/ttm: Remove pointless list_empty check drm/ttm: Remove mm init error printouts and checks drm/ttm: Add a barrier when unreserving drm/ttm: remove failed ttm binding error printout drm/ttm: Make sure a sync object doesn't disappear while we use it drm/ttm: Remove the CAP_SYS_ADMIN requirement for bo pinning drm/vmwgfx: Fix oops on failing bo pin drm/ttm: Be consistent on ttm_bo_init() failures Tyson Whitehead (1): drm/radeon/kms: fix bugs in ddc and cd path router code Zhenyu Wang (4): drm/i915: Fix KMS regression on Sandybridge/CPT drm/i915; Don't apply Ironlake FDI clock workaround to Sandybridge agp/intel: restore cache behavior on sandybridge agp/intel: fix cache control for sandybridge drivers/char/agp/intel-gtt.c |6 +- drivers/gpu/drm/drm_crtc_helper.c |2 +- drivers/gpu/drm/drm_edid.c | 26 +-- drivers/gpu/drm/i915/i915_drv.c|2 +- drivers/gpu/drm/i915/i915_drv.h|1 + drivers/gpu/drm/i915/i915_gem.c| 118 +++-- drivers/gpu/drm/i915/i915_gem_evict.c |8 +-- drivers/gpu/drm/i915/i915_suspend.c|4 +- drivers/gpu/drm/i915/intel_display.c | 70 +-- drivers/gpu/drm/i915/intel_dp.c|2 +- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_lvds.c | 16 +++- drivers/gpu/drm/i915/intel_opregion.c |2 +- drivers/gpu/drm/i915/intel_overlay.c |4 +- drivers/gpu/drm/i915/intel_ringbuffer.c| 129 +++- drivers/gpu/drm/i915/intel_ringbuffer.h|3 + drivers/gpu/drm/radeon/evergreen.c |8 ++- drivers/gpu/drm/radeon/r100.c |4 +- drivers/gpu/drm/radeon/r300.c |2 +- drivers/gpu/drm/radeon/r600.c | 12 +-- drivers/gpu/drm/radeon/radeon_atombios.c | 27 -- drivers/gpu/drm/radeon/radeon_connectors.c | 16 ++-- drivers/gpu/drm/radeon/radeon_display.c| 18 +++-- drivers/gpu/drm/radeon/radeon_encoders.c | 26 ++ drivers/gpu/drm/radeon/radeon_fence.c |3 +- drivers/gpu/drm/radeon/radeon_i2c.c| 41 +++-- drivers/gpu/drm/radeon/radeon_mode.h | 17 +++- drivers/gpu/drm/radeon/radeon_object.c
[PATCH 0/1][RFC] drm/ttm Improved io_mem_reserve / io_mem_free_calling
The following patch is really intended for the next merge window. RFC: 1) Are there any implementations of driver::io_mem_reserve today that can't use the fastpath? 2) Can we put an atomic requirement on driver::io_mem_reserve / driver::io_mem_free? The patch improves on the io_mem_reserve / io_mem_free calling sequences by introducing a fastpath and an optional eviction mechanism. The fastpath is enabled by default and is switched off by the driver setting struct ttm_mem_type_manager::io_reserve_fastpath to false on mem type init. With the fastpath no locking occurs, and io_mem_free is never called. I'm not sure if there are any implementations today that could not use the fastpath. As mentioned in the patch, if the fastpath is disabled, calls to io_mem_reserve and io_mem_free are exactly balanced, and refcounted within struct ttm_mem_reg so that io_mem_reserve should never be called recursively for the same struct ttm_mem_reg. Locking is required to make sure that ptes are never present on when the underlying memory region is not reserved. Currently I'm using man::io_reserve_mutex for this. Can we use a spinlock? That would require io_mem_reserve and io_mem_free to be atomic. Optionally, there is an eviction mechanism that is activated by setting struct ttm_mem_type_manager::use_io_reserve_lru to true when initialized. If the eviction mechanism is activated, and io_mem_reserve returns -EAGAIN, it will attempt to kill user-space mappings to free up reserved regions. Kernel mappings (ttm_bo_kmap) are not affected. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/ttm: Fix up io_mem_reserve / io_mem_free calling
This patch attempts to fix up shortcomings with the current calling
sequences.
1) There's a fastpath where no locking occurs and only io_mem_reserved is
called to obtain needed info for mapping. The fastpath is set per
memory type manager.
2) If the fastpath is disabled, io_mem_reserve and io_mem_free will be exactly
balanced and not called recursively for the same struct ttm_mem_reg.
3) Optionally the driver can choose to enable a per memory type manager LRU
eviction mechanism that, when io_mem_reserve returns -EAGAIN will attempt
to kill user-space mappings of memory in that manager to free up needed
resources
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 44 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 129 +
drivers/gpu/drm/ttm/ttm_bo_vm.c | 23 --
include/drm/ttm/ttm_bo_api.h |6 ++-
include/drm/ttm/ttm_bo_driver.h | 104 --
5 files changed, 226 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 336a39d..489bde8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -361,8 +361,13 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
int ret = 0;
if (old_is_pci || new_is_pci ||
- ((mem-placement bo-mem.placement TTM_PL_MASK_CACHING) == 0))
- ttm_bo_unmap_virtual(bo);
+ ((mem-placement bo-mem.placement TTM_PL_MASK_CACHING) == 0)) {
+ ret = ttm_mem_io_lock(old_man, true);
+ if (unlikely(ret != 0))
+ goto out_err;
+ ttm_bo_unmap_virtual_locked(bo);
+ ttm_mem_io_unlock(old_man);
+ }
/*
* Create and bind a ttm if required.
@@ -451,7 +456,6 @@ static void ttm_bo_cleanup_memtype_use(struct
ttm_buffer_object *bo)
ttm_tt_destroy(bo-ttm);
bo-ttm = NULL;
}
-
ttm_bo_mem_put(bo, bo-mem);
atomic_set(bo-reserved, 0);
@@ -651,6 +655,7 @@ static void ttm_bo_release(struct kref *kref)
struct ttm_buffer_object *bo =
container_of(kref, struct ttm_buffer_object, kref);
struct ttm_bo_device *bdev = bo-bdev;
+ struct ttm_mem_type_manager *man = bdev-man[bo-mem.mem_type];
if (likely(bo-vm_node != NULL)) {
rb_erase(bo-vm_rb, bdev-addr_space_rb);
@@ -658,6 +663,9 @@ static void ttm_bo_release(struct kref *kref)
bo-vm_node = NULL;
}
write_unlock(bdev-vm_lock);
+ ttm_mem_io_lock(man, false);
+ ttm_mem_io_free_vm(bo);
+ ttm_mem_io_unlock(man);
ttm_bo_cleanup_refs_or_queue(bo);
kref_put(bo-list_kref, ttm_bo_release_list);
write_lock(bdev-vm_lock);
@@ -714,7 +722,8 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool
interruptible,
evict_mem = bo-mem;
evict_mem.mm_node = NULL;
- evict_mem.bus.io_reserved = false;
+ evict_mem.bus.io_reserved_vm = false;
+ evict_mem.bus.io_reserved_count = 0;
placement.fpfn = 0;
placement.lpfn = 0;
@@ -1051,7 +1060,8 @@ int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
mem.num_pages = bo-num_pages;
mem.size = mem.num_pages PAGE_SHIFT;
mem.page_alignment = bo-mem.page_alignment;
- mem.bus.io_reserved = false;
+ mem.bus.io_reserved_vm = false;
+ mem.bus.io_reserved_count = 0;
/*
* Determine where to move the buffer.
*/
@@ -1171,6 +1181,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
INIT_LIST_HEAD(bo-lru);
INIT_LIST_HEAD(bo-ddestroy);
INIT_LIST_HEAD(bo-swap);
+ INIT_LIST_HEAD(bo-io_reserve_lru);
bo-bdev = bdev;
bo-glob = bdev-glob;
bo-type = type;
@@ -1180,7 +1191,8 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo-mem.num_pages = bo-num_pages;
bo-mem.mm_node = NULL;
bo-mem.page_alignment = page_alignment;
- bo-mem.bus.io_reserved = false;
+ bo-mem.bus.io_reserved_vm = false;
+ bo-mem.bus.io_reserved_count = 0;
bo-buffer_start = buffer_start PAGE_MASK;
bo-priv_flags = 0;
bo-mem.placement = (TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED);
@@ -1354,6 +1366,10 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned
type,
BUG_ON(type = TTM_NUM_MEM_TYPES);
man = bdev-man[type];
BUG_ON(man-has_type);
+ man-io_reserve_fastpath = true;
+ man-use_io_reserve_lru = false;
+ mutex_init(man-io_reserve_mutex);
+ INIT_LIST_HEAD(man-io_reserve_lru);
ret = bdev-driver-init_mem_type(bdev, type, man);
if (ret)
@@ -1560,7 +1576,7 @@ bool ttm_mem_reg_is_pci(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
return true;
}
-void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
+void
[Bug 31152] Please backport r200 fix to r100 and r300c
https://bugs.freedesktop.org/show_bug.cgi?id=31152 --- Comment #5 from Fabio Pedretti fabio@libero.it 2010-11-11 00:50:26 PST --- Looks like r300c was fixed by the following commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d8eef5196fcd6f51e443d4dfa0fda8aadc668f9f -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: Fix up a theoretical deadlock
A process suspended waiting for a higher sequence or no sequence to unreserve,
a bo may be beaten to the reservation by a process with a lower sequence.
In that case the first process should give up trying to reserve and
return -EAGAIN. In order for that to happen, we must wake waiting processes
when we change sequence, so that they have a chance to detect the new
sequence.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3ca77dc..148a322 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -224,6 +224,9 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
int ret;
while (unlikely(atomic_cmpxchg(bo-reserved, 0, 1) != 0)) {
+ /**
+* Deadlock avoidance for multi-bo reserving.
+*/
if (use_sequence bo-seq_valid
(sequence - bo-val_seq (1 31))) {
return -EAGAIN;
@@ -241,6 +244,14 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
}
if (use_sequence) {
+ /**
+* Wake up waiters that may need to recheck for deadlock,
+* if we decreased the sequence number.
+*/
+ if (unlikely((bo-val_seq - sequence (1 31))
+|| !bo-seq_valid))
+ wake_up_all(bo-event_queue);
+
bo-val_seq = sequence;
bo-seq_valid = true;
} else {
--
1.6.2.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31549] New: Commit c2c55547dc36f404e29dbc9253166f90df6783af makes CS checker unhappy and causes rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=31549 Summary: Commit c2c55547dc36f404e29dbc9253166f90df6783af makes CS checker unhappy and causes rendering issues Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: mikhail.vorozht...@gmail.com Commit c2c55547dc36f404e29dbc9253166f90df6783af r600g: attempt to turn on DXTn formats makes my dmesg (both 2.6.36 and d-r-t, the hardware is RV730XT) full of radeon :01:00.0: r600_check_texture_resource:1127 texture invalid format 50 [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! and Compiz plugins like Scale/App switcher are completely broken. -- 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 31549] Commit c2c55547dc36f404e29dbc9253166f90df6783af makes CS checker unhappy and causes rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=31549 --- Comment #1 from Keith Whitwell kei...@vmware.com 2010-11-11 05:47:41 PST --- OK, I'll protect this with a debug option defaulting to off. -- 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 31152] Please backport r200 fix to r100 and r300c
https://bugs.freedesktop.org/show_bug.cgi?id=31152 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Alex Deucher ag...@yahoo.com 2010-11-11 07:22:47 PST --- I guess we can close this then. -- 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: [PATCH 0/1][RFC] drm/ttm Improved io_mem_reserve / io_mem_free_calling
On Thu, Nov 11, 2010 at 3:41 AM, Thomas Hellstrom thellst...@vmware.com wrote: The following patch is really intended for the next merge window. RFC: 1) Are there any implementations of driver::io_mem_reserve today that can't use the fastpath? 2) Can we put an atomic requirement on driver::io_mem_reserve / driver::io_mem_free? The patch improves on the io_mem_reserve / io_mem_free calling sequences by introducing a fastpath and an optional eviction mechanism. The fastpath is enabled by default and is switched off by the driver setting struct ttm_mem_type_manager::io_reserve_fastpath to false on mem type init. With the fastpath no locking occurs, and io_mem_free is never called. I'm not sure if there are any implementations today that could not use the fastpath. As mentioned in the patch, if the fastpath is disabled, calls to io_mem_reserve and io_mem_free are exactly balanced, and refcounted within struct ttm_mem_reg so that io_mem_reserve should never be called recursively for the same struct ttm_mem_reg. Locking is required to make sure that ptes are never present on when the underlying memory region is not reserved. Currently I'm using man::io_reserve_mutex for this. Can we use a spinlock? That would require io_mem_reserve and io_mem_free to be atomic. Optionally, there is an eviction mechanism that is activated by setting struct ttm_mem_type_manager::use_io_reserve_lru to true when initialized. If the eviction mechanism is activated, and io_mem_reserve returns -EAGAIN, it will attempt to kill user-space mappings to free up reserved regions. Kernel mappings (ttm_bo_kmap) are not affected. Radeon can use fast path, i think nouveau can too. I am not sure we can consider io_mem_reserve as atomic. Use case i fear is GPU with remappable apperture i don't know what kind of code we would need for that and it might sleep. Thought my first guess is that it likely can be done atomicly. Quick review of the patch looks good, i will try to take a closer look latter. Cheers, Jerome Glisse ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31152] Please backport r200 fix to r100 and r300c
https://bugs.freedesktop.org/show_bug.cgi?id=31152 --- Comment #7 from Alexei neow...@yahoo.com 2010-11-11 08:09:41 PST --- Which kernel is this going to get merged into? Could I figure this out from the ticket? Thanks everybody! -- 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 31152] Please backport r200 fix to r100 and r300c
https://bugs.freedesktop.org/show_bug.cgi?id=31152 --- Comment #8 from Alex Deucher ag...@yahoo.com 2010-11-11 08:12:23 PST --- (In reply to comment #7) Which kernel is this going to get merged into? Could I figure this out from the ticket? These are mesa fixes, not kernel fixes. They are in mesa master and the 7.9 branch so they'll show up in mesa 7.10 and 7.9.1. -- 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 31549] Commit c2c55547dc36f404e29dbc9253166f90df6783af makes CS checker unhappy and causes rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=31549 Keith Whitwell kei...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Keith Whitwell kei...@vmware.com 2010-11-11 08:23:24 PST --- commit 6baad55f157387d0bb44144680a96bc32280109f Author: Keith Whitwell kei...@vmware.com Date: Thu Nov 11 14:26:52 2010 + r600g: guard experimental s3tc code with R600_ENABLE_S3TC -- 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: [PATCH 0/1][RFC] drm/ttm Improved io_mem_reserve / io_mem_free_calling
On 11/11/2010 04:27 PM, Jerome Glisse wrote: On Thu, Nov 11, 2010 at 3:41 AM, Thomas Hellstromthellst...@vmware.com wrote: The following patch is really intended for the next merge window. RFC: 1) Are there any implementations of driver::io_mem_reserve today that can't use the fastpath? 2) Can we put an atomic requirement on driver::io_mem_reserve / driver::io_mem_free? The patch improves on the io_mem_reserve / io_mem_free calling sequences by introducing a fastpath and an optional eviction mechanism. The fastpath is enabled by default and is switched off by the driver setting struct ttm_mem_type_manager::io_reserve_fastpath to false on mem type init. With the fastpath no locking occurs, and io_mem_free is never called. I'm not sure if there are any implementations today that could not use the fastpath. As mentioned in the patch, if the fastpath is disabled, calls to io_mem_reserve and io_mem_free are exactly balanced, and refcounted within struct ttm_mem_reg so that io_mem_reserve should never be called recursively for the same struct ttm_mem_reg. Locking is required to make sure that ptes are never present on when the underlying memory region is not reserved. Currently I'm using man::io_reserve_mutex for this. Can we use a spinlock? That would require io_mem_reserve and io_mem_free to be atomic. Optionally, there is an eviction mechanism that is activated by setting struct ttm_mem_type_manager::use_io_reserve_lru to true when initialized. If the eviction mechanism is activated, and io_mem_reserve returns -EAGAIN, it will attempt to kill user-space mappings to free up reserved regions. Kernel mappings (ttm_bo_kmap) are not affected. Radeon can use fast path, i think nouveau can too. I am not sure we can consider io_mem_reserve as atomic. Use case i fear is GPU with remappable apperture i don't know what kind of code we would need for that and it might sleep. Thought my first guess is that it likely can be done atomicly. In that case, I think I will change it to a spinlock, with a code comment that it can be changed to a mutex later if it turns out to be very hard / impossible to implement atomic operations. Another possible concern is the execution of umap_mapping_range() that may in some cases be long. Perhaps too long to use a spinlock. Quick review of the patch looks good, i will try to take a closer look latter. Cheers, Jerome Glisse Great. Thanks, Thomas ___ 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 Jose bra...@hotmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #9 from Jose bra...@hotmail.com 2010-11-11 13:06:26 PST --- I finally got a chance to test and the bug seems to be fixed. There was no need to test mesa from git. I'm running: kernel 2.6.36 xorg-server 1.9.2 xf86-video-ati 6.13.2 mesa 7.8.2 -- 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: [PATCH 0/1][RFC] drm/ttm Improved io_mem_reserve / io_mem_free_calling
On Thu, 2010-11-11 at 17:50 +0100, Thomas Hellstrom wrote: On 11/11/2010 04:27 PM, Jerome Glisse wrote: On Thu, Nov 11, 2010 at 3:41 AM, Thomas Hellstromthellst...@vmware.com wrote: The following patch is really intended for the next merge window. RFC: 1) Are there any implementations of driver::io_mem_reserve today that can't use the fastpath? 2) Can we put an atomic requirement on driver::io_mem_reserve / driver::io_mem_free? The patch improves on the io_mem_reserve / io_mem_free calling sequences by introducing a fastpath and an optional eviction mechanism. The fastpath is enabled by default and is switched off by the driver setting struct ttm_mem_type_manager::io_reserve_fastpath to false on mem type init. With the fastpath no locking occurs, and io_mem_free is never called. I'm not sure if there are any implementations today that could not use the fastpath. As mentioned in the patch, if the fastpath is disabled, calls to io_mem_reserve and io_mem_free are exactly balanced, and refcounted within struct ttm_mem_reg so that io_mem_reserve should never be called recursively for the same struct ttm_mem_reg. Locking is required to make sure that ptes are never present on when the underlying memory region is not reserved. Currently I'm using man::io_reserve_mutex for this. Can we use a spinlock? That would require io_mem_reserve and io_mem_free to be atomic. Optionally, there is an eviction mechanism that is activated by setting struct ttm_mem_type_manager::use_io_reserve_lru to true when initialized. If the eviction mechanism is activated, and io_mem_reserve returns -EAGAIN, it will attempt to kill user-space mappings to free up reserved regions. Kernel mappings (ttm_bo_kmap) are not affected. Radeon can use fast path, i think nouveau can too. I am not sure we can consider io_mem_reserve as atomic. Use case i fear is GPU with remappable apperture i don't know what kind of code we would need for that and it might sleep. Thought my first guess is that it likely can be done atomicly. In that case, I think I will change it to a spinlock, with a code comment that it can be changed to a mutex later if it turns out to be very hard / impossible to implement atomic operations. Another possible concern is the execution of umap_mapping_range() that may in some cases be long. Perhaps too long to use a spinlock. I'd rather keep the mutex personally, the code I have in development uses mutexes itself beyond the io_mem_reserve/io_mem_free calls. An earlier revision used spinlocks, but it wasn't very nice. Ben. Quick review of the patch looks good, i will try to take a closer look latter. Cheers, Jerome Glisse Great. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30188] X server crashes with a SIGBUS on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=30188 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #29 from Alex Deucher ag...@yahoo.com 2010-11-11 17:08:18 PST --- fixes pushed. -- 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 31482] When trying to put the fullscreen window, data show and LCD laptop screen, the screen windwos screw up
https://bugs.freedesktop.org/show_bug.cgi?id=31482 --- Comment #2 from Maximiliano Castañón maxim...@gmail.com 2010-11-11 17:38:00 PST --- Seems to be managed by a kernel driver... don't know which Nov 11 22:30:15 localhost kernel: [74389.406194] atkbd serio0: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0). Nov 11 22:30:15 localhost kernel: [74389.406205] atkbd serio0: Use 'setkeycodes e078 keycode' to make it known. Nov 11 22:30:15 localhost kernel: [74389.413290] atkbd serio0: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0). Nov 11 22:30:15 localhost kernel: [74389.413298] atkbd serio0: Use 'setkeycodes e078 keycode' to make it known. Nov 11 22:30:17 localhost kernel: [74392.162654] atkbd serio0: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0). Nov 11 22:30:17 localhost kernel: [74392.162660] atkbd serio0: Use 'setkeycodes e078 keycode' to make it known. Nov 11 22:30:17 localhost kernel: [74392.169601] atkbd serio0: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0). Nov 11 22:30:17 localhost kernel: [74392.169607] atkbd serio0: Use 'setkeycodes e078 keycode' to make it known. i'm on Fedora 14, xrandr 1.3.3 Linux localhost.localdomain 2.6.35.6-48.fc14.x86_64 #1 SMP Fri Oct 22 15:36:08 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Name: xorg-x11-drv-ati Arch: x86_64 Version : 6.13.1 -- 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 31482] When trying to put the fullscreen window, data show and LCD laptop screen, the screen windwos screw up
https://bugs.freedesktop.org/show_bug.cgi?id=31482 --- Comment #3 from Maximiliano Castañón maxim...@gmail.com 2010-11-11 17:43:40 PST --- Created an attachment (id=40220) -- (https://bugs.freedesktop.org/attachment.cgi?id=40220) /var/log/messages the file is compressed because it's 1200 KB size -- 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 31565] New: [r300] radeon_texture.c:136: radeon_teximage_map: Assertion `!image-base.Data' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=31565
Summary: [r300] radeon_texture.c:136: radeon_teximage_map:
Assertion `!image-base.Data' failed.
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: v...@vmware.com
mesa: d18df9e336b5d2e68a4a6185f7b9d0d0c095c3c4 (master)
chipset: RV530 71C5 (ATI Radeon X1600)
system architecture: i686
libdrm-dev: 2.4.21-1ubuntu2.1
kernel version: 2.6.35-22-generic
Linux distribution: Ubuntu 10.10 i386
Machine model: iMac4,1
Run piglit fbo-blit.
$ ./bin/fbo-blit
...
radeonSetSpanFunctions: bad format: 0x0002
radeonSetSpanFunctions: bad format: 0x0002
fbo-blit: radeon_texture.c:136: radeon_teximage_map: Assertion
`!image-base.Data' failed.
(gdb) bt
#0 0x0020c416 in __kernel_vsyscall ()
#1 0x00354941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x00357e42 in abort () at abort.c:92
#3 0x0034d8e8 in __assert_fail (assertion=0x1123ce5 !image-base.Data,
file=0x1123cb6 radeon_texture.c, line=136, function=0x1123f06
radeon_teximage_map) at assert.c:81
#4 0x00f2fb0f in radeon_teximage_map (image=0x9884200, write_enable=1 '\001')
at radeon_texture.c:136
#5 0x00f22fb0 in radeon_map_unmap_framebuffer (ctx=value optimized out,
fb=0x9884350, map=1 '\001') at radeon_span.c:1047
#6 0x00f2ebc4 in radeonSpanRenderStart (ctx=0x9526458) at radeon_span.c:1085
#7 0x01027253 in swrast_render_start (ctx=0x9526458, x=10, y=10, width=10,
height=10, format=6407, type=5126, packing=0x9535108, pixels=0x98b7508) at
swrast/s_context.h:268
#8 _swrast_ReadPixels (ctx=0x9526458, x=10, y=10, width=10, height=10,
format=6407, type=5126, packing=0x9535108, pixels=0x98b7508) at
swrast/s_readpix.c:473
#9 0x00f2176d in radeonReadPixels (ctx=0x9526458, x=10, y=10, width=10,
height=10, format=6407, type=5126, pack=0x9535108, pixels=0x98b7508) at
radeon_pixel_read.c:221
#10 0x00f9a58b in _mesa_ReadPixels (x=10, y=10, width=10, height=10,
format=6407, type=5126, pixels=0x98b7508) at main/readpix.c:232
#11 0x0804b53e in piglit_probe_rect_rgb (x=10, y=10, w=10, h=10,
expected=0xbfde7a00) at piglit/tests/util/piglit-util.c:278
#12 0x0804a890 in verify_color_rect (start_x=10, start_y=10, w=20, h=20) at
/piglit/tests/fbo/fbo-blit.c:110
#13 0x0804ae31 in run_test () at piglit/tests/fbo/fbo-blit.c:193
#14 0x0804aeb6 in piglit_display () at /piglit/tests/fbo/fbo-blit.c:206
#15 0x0804ce7b in display () at piglit/tests/util/piglit-framework.c:52
#16 0x00d79820 in fghRedrawWindow (window=0x9509050, enumerator=0xbfde7b68) at
freeglut_main.c:210
#17 fghcbDisplayWindow (window=0x9509050, enumerator=0xbfde7b68) at
freeglut_main.c:227
#18 0x00d7d660 in fgEnumWindows (enumCallback=0xd79790 fghcbDisplayWindow,
enumerator=0xbfde7b68) at freeglut_structure.c:394
#19 0x00d79cdb in fghDisplayAll () at freeglut_main.c:249
#20 glutMainLoopEvent () at freeglut_main.c:1450
#21 0x00d7a605 in glutMainLoop () at freeglut_main.c:1498
#22 0x0804d024 in main (argc=1, argv=0xbfde7df4) at
piglit/tests/util/piglit-framework.c:118
(gdb) frame 4
#4 0x00f2fb0f in radeon_teximage_map (image=0x9884200, write_enable=1 '\001')
at radeon_texture.c:136
136assert(!image-base.Data);
(gdb) l
131radeon_print(RADEON_TEXTURE, RADEON_VERBOSE,
132%s(img %p), write_enable %s.\n,
133__func__, image,
134write_enable ? true: false);
135if (image-mt) {
136assert(!image-base.Data);
137
138radeon_bo_map(image-mt-bo, write_enable);
139teximage_set_map_data(image);
140}
(gdb) print image-base
$1 = {InternalFormat = 6408, _BaseFormat = 6408, TexFormat = 2, Border = 0,
Width = 64, Height = 64, Depth = 1, Width2 = 64, Height2 = 64, Depth2 = 1,
WidthLog2 = 6, HeightLog2 = 6, DepthLog2 = 0,
MaxLog2 = 6, WidthScale = 64, HeightScale = 64, DepthScale = 1, IsClientData
= 0 '\000', _IsPowerOfTwo = 1 '\001', TexObject = 0x9884690, FetchTexelc =
0x10cfc60 fetch_texel_float_to_chan,
FetchTexelf = 0x10c9dc0 fetch_texel_2d_f_rgba_rev, RowStride = 64,
ImageOffsets = 0x9884278, Data = 0xb77cb000, DriverData = 0x0}
(gdb) print image-base.Data
$2 = (GLvoid *) 0xb77cb000
--
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 31566] New: [r300] swrast/s_span.c:1349: _swrast_read_rgba_span: Assertion `rb-GetRow' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=31566 Summary: [r300] swrast/s_span.c:1349: _swrast_read_rgba_span: Assertion `rb-GetRow' failed. Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: v...@vmware.com mesa: d18df9e336b5d2e68a4a6185f7b9d0d0c095c3c4 (master) chipset: RV530 71C5 (ATI Radeon X1600) system architecture: i686 libdrm-dev: 2.4.21-1ubuntu2.1 kernel version: 2.6.35-22-generic Linux distribution: Ubuntu 10.10 i386 Machine model: iMac4,1 Run piglit fbo-nodepth-test. $ ./bin/fbo-nodepth-test ... radeonSetSpanFunctions: bad format: 0x0002 radeonSetSpanFunctions: bad format: 0x0002 fbo-nodepth-test: swrast/s_span.c:1349: _swrast_read_rgba_span: Assertion `rb-GetRow' failed. (gdb) bt #0 0x008e6416 in __kernel_vsyscall () #1 0x001aa941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x001ade42 in abort () at abort.c:92 #3 0x001a38e8 in __assert_fail (assertion=0x1244bee rb-GetRow, file=0x125738c swrast/s_span.c, line=1349, function=0x12576f5 _swrast_read_rgba_span) at assert.c:81 #4 0x01123088 in _swrast_read_rgba_span (ctx=0x9f43460, rb=0xa290458, n=128, x=0, y=6, dstType=5126, rgba=0xb754f008) at swrast/s_span.c:1349 #5 0x0112251a in read_rgba_pixels (ctx=0x9f43460, x=0, y=0, width=128, height=128, format=6407, type=5126, packing=0x9f52110, pixels=value optimized out) at swrast/s_readpix.c:341 #6 _swrast_ReadPixels (ctx=0x9f43460, x=0, y=0, width=128, height=128, format=6407, type=5126, packing=0x9f52110, pixels=value optimized out) at swrast/s_readpix.c:509 #7 0x0101c76d in radeonReadPixels (ctx=0x9f43460, x=0, y=0, width=128, height=128, format=6407, type=5126, pack=0x9f52110, pixels=0xb7315008) at radeon_pixel_read.c:221 #8 0x0109558b in _mesa_ReadPixels (x=0, y=0, width=128, height=128, format=6407, type=5126, pixels=0xb7315008) at main/readpix.c:232 #9 0x0804aeaa in piglit_probe_rect_rgb (x=0, y=0, w=128, h=128, expected=0xbfe29940) at piglit/tests/util/piglit-util.c:278 #10 0x0804a766 in piglit_display () at piglit/tests/fbo/fbo-nodepth-test.c:79 #11 0x0804c7e7 in display () at piglit/tests/util/piglit-framework.c:52 #12 0x006ab820 in fghRedrawWindow (window=0x9f26058, enumerator=0xbfe29a48) at freeglut_main.c:210 #13 fghcbDisplayWindow (window=0x9f26058, enumerator=0xbfe29a48) at freeglut_main.c:227 #14 0x006af660 in fgEnumWindows (enumCallback=0x6ab790 fghcbDisplayWindow, enumerator=0xbfe29a48) at freeglut_structure.c:394 #15 0x006abcdb in fghDisplayAll () at freeglut_main.c:249 #16 glutMainLoopEvent () at freeglut_main.c:1450 #17 0x006ac605 in glutMainLoop () at freeglut_main.c:1498 #18 0x0804c990 in main (argc=1, argv=0xbfe29cd4) at piglit/tests/util/piglit-framework.c:118 (gdb) frame 4 #4 0x01123088 in _swrast_read_rgba_span (ctx=0x9f43460, rb=0xa290458, n=128, x=0, y=6, dstType=5126, rgba=0xb754f008) at swrast/s_span.c:1349 1349 ASSERT(rb-GetRow); -- 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 31567] New: [r300] swrast/s_span.c:1267: _swrast_write_rgba_span: Assertion `rb-PutValues' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=31567 Summary: [r300] swrast/s_span.c:1267: _swrast_write_rgba_span: Assertion `rb-PutValues' failed. Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: v...@vmware.com mesa: d18df9e336b5d2e68a4a6185f7b9d0d0c095c3c4 (master) chipset: RV530 71C5 (ATI Radeon X1600) system architecture: i686 libdrm-dev: 2.4.21-1ubuntu2.1 kernel version: 2.6.35-22-generic Linux distribution: Ubuntu 10.10 i386 Machine model: iMac4,1 Run piglit fbo-scissor-bitmap test. $ ./bin/fbo-scissor-bitmap ... radeonSetSpanFunctions: bad format: 0x0002 radeonSetSpanFunctions: bad format: 0x0002 fbo-scissor-bitmap: swrast/s_span.c:1267: _swrast_write_rgba_span: Assertion `rb-PutValues' failed. (gdb) bt #0 0x00808416 in __kernel_vsyscall () #1 0x00b0a941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x00b0de42 in abort () at abort.c:92 #3 0x00b038e8 in __assert_fail (assertion=0x122ec21 rb-PutValues, file=0x124138c swrast/s_span.c, line=1267, function=0x124170c _swrast_write_rgba_span) at assert.c:81 #4 0x0110fa87 in _swrast_write_rgba_span (ctx=0x9550460, span=0xbfe29174) at swrast/s_span.c:1267 #5 0x010fe66d in _swrast_Bitmap (ctx=0x9550460, px=224, py=229, width=64, height=53, unpack=0x955f130, bitmap=0x804e200 ) at swrast/s_bitmap.c:128 #6 0x011a3084 in _mesa_Bitmap (width=64, height=53, xorig=0, yorig=0, xmove=0, ymove=0, bitmap=0x804e200 ) at main/drawpix.c:246 #7 0x0804ad06 in draw_and_test (destination=0x804e1d6 FBO, drawable_width=512, drawable_height=512) at piglit/tests/fbo/fbo-scissor-bitmap.c:185 #8 0x0804b9b9 in piglit_display () at piglit/tests/fbo/fbo-scissor-bitmap.c:370 #9 0x0804d9b3 in display () at piglit/tests/util/piglit-framework.c:52 #10 0x00370820 in fghRedrawWindow (window=0x9533058, enumerator=0xbfe29d98) at freeglut_main.c:210 #11 fghcbDisplayWindow (window=0x9533058, enumerator=0xbfe29d98) at freeglut_main.c:227 #12 0x00374660 in fgEnumWindows (enumCallback=0x370790 fghcbDisplayWindow, enumerator=0xbfe29d98) at freeglut_structure.c:394 #13 0x00370cdb in fghDisplayAll () at freeglut_main.c:249 #14 glutMainLoopEvent () at freeglut_main.c:1450 #15 0x00371605 in glutMainLoop () at freeglut_main.c:1498 #16 0x0804db5c in main (argc=1, argv=0xbfe2a024) at piglit/tests/util/piglit-framework.c:118 (gdb) frame 4 #4 0x0110fa87 in _swrast_write_rgba_span (ctx=0x9550460, span=0xbfe29174) at swrast/s_span.c:1267 1267 ASSERT(rb-PutValues); -- 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 31568] New: [r300g] SIGSEGV src/mesa/vbo/vbo_exec_array.c:1154
https://bugs.freedesktop.org/show_bug.cgi?id=31568
Summary: [r300g] SIGSEGV src/mesa/vbo/vbo_exec_array.c:1154
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: v...@vmware.com
mesa: d18df9e336b5d2e68a4a6185f7b9d0d0c095c3c4 (master)
chipset: RV530 71C5 (ATI Radeon X1600)
system architecture: i686
libdrm-dev: 2.4.21-1ubuntu2.1
kernel version: 2.6.35-22-generic
Linux distribution: Ubuntu 10.10 i386
Machine model: iMac4,1
Run piglit bgra-sec-color-pointer test.
$ ./bin/bgra-sec-color-pointer-test
...
Segmentation fault (core dumped)
(gdb) bt
#0 0x0183d923 in vbo_exec_MultiDrawElements (mode=3, count=0x1401, type=4,
indices=0x804f1d0, primcount=143224880) at src/mesa/vbo/vbo_exec_array.c:1154
#1 0x0804a622 in piglit_display () at
piglit/tests/general/bgra-sec-color-pointer.c:82
#2 0x0804c847 in display () at piglit/tests/util/piglit-framework.c:52
#3 0x00755820 in fghRedrawWindow (window=0x88a2060, enumerator=0xbfd29688) at
freeglut_main.c:210
#4 fghcbDisplayWindow (window=0x88a2060, enumerator=0xbfd29688) at
freeglut_main.c:227
#5 0x00759660 in fgEnumWindows (enumCallback=0x755790 fghcbDisplayWindow,
enumerator=0xbfd29688) at freeglut_structure.c:394
#6 0x00755cdb in fghDisplayAll () at freeglut_main.c:249
#7 glutMainLoopEvent () at freeglut_main.c:1450
#8 0x00756605 in glutMainLoop () at freeglut_main.c:1498
#9 0x0804c9f0 in main (argc=1, argv=0xbfd29914) at
piglit/tests/util/piglit-framework.c:118
(gdb) frame 0
#0 0x0183d923 in vbo_exec_MultiDrawElements (mode=3, count=0x1401, type=4,
indices=0x804f1d0, primcount=143224880) at src/mesa/vbo/vbo_exec_array.c:1154
1154 if (!_mesa_validate_DrawElements(ctx, mode, count[i], type,
indices[i],
(gdb) l
1149 GLint i;
1150
1151 ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(ctx);
1152
1153 for (i = 0; i primcount; i++) {
1154 if (!_mesa_validate_DrawElements(ctx, mode, count[i], type,
indices[i],
1155 0))
1156 return;
1157 }
1158
--
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 31482] When trying to put the fullscreen window, data show and LCD laptop screen, the screen windwos screw up
https://bugs.freedesktop.org/show_bug.cgi?id=31482 --- Comment #4 from Maximiliano Castañón maxim...@gmail.com 2010-11-11 18:50:55 PST --- http://img143.imageshack.us/img143/829/libreofficefail.png this is an example... this is how it look after a screen change, i mean the press of hardware button changin between modes, dual screen, single screen, etc... -- 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: 3Dfx KMS board needed
On Wed, Nov 10, 2010 at 7:45 PM, James Simmons jsimm...@infradead.org wrote:
Looking to work on the 3Dfx KMS driver I discovered that it is very
difficult to find a motherboard that supports AGP of 3.3V. So I discovered
that the only 3Dfx card that supports this is the 3dfx Voodoo 4 4500 AGP
Card which also is difficult to find. Does anyone have this card to send
to me or a old working system with a 3.3V AGP bus. Thanks.
Sorry, I'm having a hard time understanding. If motherboards with 3.3V
AGP are difficult to find, why are you looking for a Voodoo 4 4500?
You must mean that the Voodoo 4 4500 is the only AGP card that also
supports 1.5V AGP signaling?
I see a very cheap Voodoo 4 4500 on eBay in the UK. Item # 110610063423.
Also, the 4500 and 5500 come in PCI.
I had trouble finding a suitable board to use with Permedia hardware
this summer. The last to support 3.3V AGP were the Athlon MP
motherboards, e.g., Tyan S246{0,2,6,8,9}. But at least you get dual
processors.
For reference, the last 3.3V supporting video cards were the R300
series (specifically Radeon 9800 Pro, but not 9800 XT) and the GeForce
7950 GT. Not that any of that's specifically related to your query.
Thanks,
Matt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31482] When trying to put the fullscreen window, data show and LCD laptop screen, the screen windwos screw up
https://bugs.freedesktop.org/show_bug.cgi?id=31482 --- Comment #5 from Alex Deucher ag...@yahoo.com 2010-11-11 21:15:22 PST --- I think the app does not update it's itself properly after the screen geometry changes. -- 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: [PATCH 0/1][RFC] drm/ttm Improved io_mem_reserve / io_mem_free_calling
On 11/11/2010 11:46 PM, Ben Skeggs wrote: On Thu, 2010-11-11 at 17:50 +0100, Thomas Hellstrom wrote: On 11/11/2010 04:27 PM, Jerome Glisse wrote: On Thu, Nov 11, 2010 at 3:41 AM, Thomas Hellstromthellst...@vmware.com wrote: The following patch is really intended for the next merge window. RFC: 1) Are there any implementations of driver::io_mem_reserve today that can't use the fastpath? 2) Can we put an atomic requirement on driver::io_mem_reserve / driver::io_mem_free? The patch improves on the io_mem_reserve / io_mem_free calling sequences by introducing a fastpath and an optional eviction mechanism. The fastpath is enabled by default and is switched off by the driver setting struct ttm_mem_type_manager::io_reserve_fastpath to false on mem type init. With the fastpath no locking occurs, and io_mem_free is never called. I'm not sure if there are any implementations today that could not use the fastpath. As mentioned in the patch, if the fastpath is disabled, calls to io_mem_reserve and io_mem_free are exactly balanced, and refcounted within struct ttm_mem_reg so that io_mem_reserve should never be called recursively for the same struct ttm_mem_reg. Locking is required to make sure that ptes are never present on when the underlying memory region is not reserved. Currently I'm using man::io_reserve_mutex for this. Can we use a spinlock? That would require io_mem_reserve and io_mem_free to be atomic. Optionally, there is an eviction mechanism that is activated by setting struct ttm_mem_type_manager::use_io_reserve_lru to true when initialized. If the eviction mechanism is activated, and io_mem_reserve returns -EAGAIN, it will attempt to kill user-space mappings to free up reserved regions. Kernel mappings (ttm_bo_kmap) are not affected. Radeon can use fast path, i think nouveau can too. I am not sure we can consider io_mem_reserve as atomic. Use case i fear is GPU with remappable apperture i don't know what kind of code we would need for that and it might sleep. Thought my first guess is that it likely can be done atomicly. In that case, I think I will change it to a spinlock, with a code comment that it can be changed to a mutex later if it turns out to be very hard / impossible to implement atomic operations. Another possible concern is the execution of umap_mapping_range() that may in some cases be long. Perhaps too long to use a spinlock. I'd rather keep the mutex personally, the code I have in development uses mutexes itself beyond the io_mem_reserve/io_mem_free calls. An earlier revision used spinlocks, but it wasn't very nice. Ben. OK. Note that any per-mem-type shared objects accessed by io_mem_reserve / io_mem_free don't need any further protection beyond the lock we're discussing. For the same mem_type, io_mem_reserve / io_mem_free will be completely serialized with this patch. Anyway, let's keep the mutex. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
