[Bug 22396] New: [KMS i915] ut2004 will crash the system
http://bugs.freedesktop.org/show_bug.cgi?id=22396 Summary: [KMS i915] ut2004 will crash the system Product: Mesa Version: unspecified Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: jian.j.z...@intel.com Created an attachment (id=26989) -- (http://bugs.freedesktop.org/attachment.cgi?id=26989) xorg.conf System Environment: -- Host: 945GM Arch: i386 Libdrm: (master)2fa2db138ba989bfa1a8cd9ab66d83fb7369249e Mesa: (master)df70d3049a396af3601d2a1747770635a74120bb Xserver:(master)ae20e748cd3a656173e1f50109bfd4af0712bb87 Xf86_video_intel:(master)0b7522372c82cd3b485c7e81867ccdbb710451e8 Bug detailed description: -- start X and run ut2004-demo, then it will crash the system leaving there a blurred screen. It failed both with KMS and UMS. On G45, it didn't crash the system, but sometimes has a black screen. And its log is unreadable. [r...@x-945gm ~]# ut2004 WARNING: ALC_EXT_capture is subject to change! libGL: OpenDriver: trying /opt/X11R7/lib/dri/i915_dri.so Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. Reproduce steps: 1.xinit 2. run ut2004(or its demo, benchmark.sh) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22396] [KMS i915] ut2004 will crash the system
http://bugs.freedesktop.org/show_bug.cgi?id=22396 --- Comment #1 from zhao jian jian.j.z...@intel.com 2009-06-21 02:27:03 PST --- Created an attachment (id=26990) -- (http://bugs.freedesktop.org/attachment.cgi?id=26990) xorg.0.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22396] [KMS i915] ut2004 will crash the system
http://bugs.freedesktop.org/show_bug.cgi?id=22396 --- Comment #2 from zhao jian jian.j.z...@intel.com 2009-06-21 02:33:33 PST --- And it works well with our RC2 image: Libdrm: (master)2fa2db138ba989bfa1a8cd9ab66d83fb7369249e Mesa: (mesa_7_5_branch)8f382fd3f396e182255fe084bc32648b98ca1d94 Xserver: (server-1.6-branch)6be19e8f43086fb4b7fb30a47b89b5f3eed798ef Xf86_video_intel: (master)b5cd2130f97591f4a387db1b98c940c30bc6404c -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20607] FlightGear asserts and aborts in r300_mipmap_tree.c:calculate_miptree_layout
http://bugs.freedesktop.org/show_bug.cgi?id=20607 --- Comment #15 from Mukund Sivaraman m...@banu.com 2009-06-21 04:04:34 PST --- (In reply to comment #7) (In reply to comment #6) (In reply to comment #4) *WARN_ONCE* File r300_state.c function r500SetupRSUnit line 1907 Don't know how to satisfy InputsRead=0x0008 This looks like bug 17929, which was fixed before Mesa 7.3, but maybe the fix needs to be adapted for R5xx cards as well... Nope, this bug and other fog related has been fixed by d8b8fb68954e6eebd0b38708c25a5bec4cf1a26c and 7ad7abc4cd5c94b83feea4553ffb5a69d8ad4757. These commits aren't in 7.3 neither in 7.4. Fedora 11 shipped with Mesa RPM versions 7.5-0.14.fc11.x86_64, but it's unclear what release they picked as Mesa 7.5 doesn't seem to be released (?). Maybe it's one of the RC releases. I am still able to reproduce the exact same bug as in the description with this RPM version on the same hardware. Let's keep this bug in the resolved state while I get a chance to verify if it has been fixed. Please do not mark this bug as closed until then. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20607] FlightGear asserts and aborts in r300_mipmap_tree.c:calculate_miptree_layout
http://bugs.freedesktop.org/show_bug.cgi?id=20607 --- Comment #16 from Mukund Sivaraman m...@banu.com 2009-06-21 04:13:08 PST --- The source file of the assertion is different, but it's in the same function, so maybe the file was renamed: [m...@naina ~]$ fgfs Model Author: Unknown Creation Date: 2002-01-01 Version: $Id: c172p.xml,v 1.20 2008/09/01 15:14:33 torsten Exp $ Description: Cessna C-172 FGMultiplayMgr - No receiver port, Multiplayermode disabled KI266 dme indicator #0 initialized Initializing Nasal Electrical System fgfs: radeon_mipmap_tree.c:142: calculate_miptree_layout: Assertion `numLevels = 12' failed. Aborted [m...@naina ~]$ New package versions: FlightGear-1.9.1-4.fc11.x86_64 xorg-x11-drv-ati-6.12.2-14.fc11.x86_64 mesa-libGL-7.5-0.14.fc11.x86_64 libdrm-2.4.6-7.fc11.x86_64 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 9253] rendering problems on radeon 9600 XT + compiz
http://bugs.freedesktop.org/show_bug.cgi?id=9253 Pauli suok...@gmail.com changed: What|Removed |Added CC||dragon_...@email.it --- Comment #3 from Pauli suok...@gmail.com 2009-06-21 04:29:15 PST --- *** Bug 22395 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22398] New: Googleearth crashes and Mplayer crash
http://bugs.freedesktop.org/show_bug.cgi?id=22398 Summary: Googleearth crashes and Mplayer crash Product: Mesa Version: CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: ashl1fut...@gmail.com I have Gentoo Linux amd64 (x86_64). 05:00.0 VGA compatible controller: ATI Technologies Inc RV380 0x3e50 [Radeon X600] media-libs/mesa-7.5_rc3 x11-apps/mesa-progs-7.4.1 DRI is enabled in kernel 2.6.29-r5 Google crash with this: libGL warning: 3D driver claims to not support visual 0x68 libGL warning: 3D driver claims to not support visual 0x69 libGL warning: 3D driver claims to not support visual 0x57 libGL warning: 3D driver claims to not support visual 0x6a libGL warning: 3D driver claims to not support visual 0x6b libGL warning: 3D driver claims to not support visual 0x6c libGL warning: 3D driver claims to not support visual 0x21 libGL warning: 3D driver claims to not support visual 0x6d libGL warning: 3D driver claims to not support visual 0x6e libGL warning: 3D driver claims to not support visual 0x6f libGL warning: 3D driver claims to not support visual 0x70 libGL warning: 3D driver claims to not support visual 0x71 libGL warning: 3D driver claims to not support visual 0x72 libGL warning: 3D driver claims to not support visual 0x73 libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x74 *WARN_ONCE* File r300_render.c function r300Fallback line 428 Software fallback:ctx-Line.SmoothFlag *** Try R300_SPAN_DISABLE_LOCKING env var if this hangs. *WARN_ONCE* File r300_state.c function r300Enable line 512 TODO - double side stencil ! *** *WARN_ONCE* File r300_state.c function r300_setup_rs_unit line 1391 fragprog wants coords for tex0, vp doesn't provide them! *** drmRadeonCmdBuffer: -22 (exiting) Mplayer randomly crashes with this: drmRadeonCmdBuffer: -12 or similar I cannot recognize it. It seems related to: https://bugs.freedesktop.org/show_bug.cgi?id=7445 https://bugs.freedesktop.org/show_bug.cgi?id=10753 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Bulding DRM on MIPS
HI all, I'm developing a driver for my embedded graphics device on a MIPS platform. I've really just started this effort when I encountered use of: #include asm/agp.h (in drmP.h, without any conditioning on AGP support in the OS) This lead to think - what is the proper configuration I need to use in order to build DRM for MIPS systems? -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Sat, 2009-06-20 at 17:42 -0700, Linus Torvalds wrote: On Sun, 21 Jun 2009, Maxim Levitsky wrote: Something from this tree breaks my i965. Using -git just before this was pulled, a552f0af753eb4b5bbbe9eff205fe874b04c4583 works, but using latest git makes google earth stall, it doesn't update its main window. It appears that openining and closing its menu, allows it to progress frame after frame. No crashes hangs however. Can you bisect? There's not a tons of commit there, so it shouldn't be more than a couple of recompiles/reboots, and you'd be able to pinpoint the exact commit that breaks. That will help people figure it out, or at worst just pinpoint what we need to revert. Linus Here the result: 52dc7d32b88156248167864f77a9026abe27b432 is first bad commit commit 52dc7d32b88156248167864f77a9026abe27b432 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Sat Jun 6 09:46:01 2009 +0100 drm/i915: Clear fence register on tiling stride change. The fence register value also depends upon the stride of the object, so we need to clear the fence if that is changed as well. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk [anholt: Added 8xx and 965 paths, and renamed the confusing i915_gem_object_tiling_ok function to i915_gem_object_fence_offset_ok] Signed-off-by: Eric Anholt e...@anholt.net However I can't reproduce the situation I have earlier, maybe I have changed some settings, don't know. Now, the bad behavior (and I reproduced it many times, is that GE shows incorrect textures (like they are divided in tiny interlaced rows, one row ok, other contain image from other part of world), only few textures are such it seems logical that this is related to tiling. Also, if I maximize it, it hangs. This seems to be a separate bug introduced by these series. commit 43813f399c72aa22e01a680559c1cb5274bf2140 both textures and maximize broken commit 52dc7d32b88156248167864f77a9026abe27b432, shows this incorect textures, but doesn't hang the system on maximize commit 8c4b8c3f34de4e2da20df042bba173fe557f8b45 works just fine Unfortunaly I have no time now to do another bisect now, I try to do such as soon as possible. Thanks, Maxim Levitsky -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Sun, 21 Jun 2009, Dave Airlie wrote: I tried this tree (specifically, a merge of Linus' fb20871 this tree) on Fedora 11 with modesetting enabled on an integrated Radeon 2100, and plymouthd crashes immediately with a corrupt page table. Photo attached. After the crash, bootup stops, although ctrl-alt-del works. You need a different userspace, -ati from koji in F11 should do it. Dave - no amount of userspace differences make a corrupted page table acceptable. This needs to be fixed. No excuses. Kernel crashes are never an issue of you used the wrong user space. Linus -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Sun, 21 Jun 2009, Linus Torvalds wrote:
Dave - no amount of userspace differences make a corrupted page table
acceptable.
This needs to be fixed. No excuses. Kernel crashes are never an issue of
you used the wrong user space.
So corrupted page table means that one of the reserved bits was set, and
we get a page fault with the PF_RSVD bit on in the error code.
Looking at the debug output, it says
PGD12148a067
PUD12148b067
PMD121496067
PTE c90011780237
where the top-level entries look fine, but the PTE is total crap. It looks
like it has filled in the page frame number with a virtual address rather
than with an actual page
The PTE _should_ look like this:
- bit 63: NX
- bits 62-52: zero (available to sw, but I don't think we use them)
- bits 51-47: zero (reserved)
- bits 46-12: page frame
- bits 11-0: protection and PAT bits etc (bits 8-7 are also reserved)
and that PTE clearly does not match.
Strictly speaking, that 47-bit physical address is purely theoretical. I
think existing CPU's are limited to 40 bits or so, so there are even more
reserved bits.
Anyway, here's a totally UNTESTED patch that hopefully gives a warning on
where exactly we set the invalid bits. Andy, mind trying it out? You
should get the warnign much earlier, and it should have a much more useful
back-trace.
(But this is _untested_, so maybe I screwed up and it doesn't compile or
work. The BAD_PTE_BITS mask could also be improved upon, but that mask
should be good enough - it doesn't include _all_ the bits it could,
but it certainly has enough bits set to trigger that obviously bad case).
Linus
---
arch/x86/include/asm/pgtable_64.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/pgtable_64.h
b/arch/x86/include/asm/pgtable_64.h
index c57a301..b95828e 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -49,8 +49,11 @@ static inline void native_pte_clear(struct mm_struct *mm,
unsigned long addr,
*ptep = native_make_pte(0);
}
+#define BAD_PTE_BITS (_PAGE_NX - (1ul __PHYSICAL_MASK_SHIFT))
+
static inline void native_set_pte(pte_t *ptep, pte_t pte)
{
+ WARN_ON_ONCE(pte.pte BAD_PTE_BITS);
*ptep = pte;
}
--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
i915: readpix demo regression
I was checking on some driver regressions this weekend, and thought that readpixels failure on i915 might have been my fault, but bisect claims it's: dd26899ca39111e0866afed9df94bfb1618dd363 is first bad commit commit dd26899ca39111e0866afed9df94bfb1618dd363 Author: Michel Dänzer daen...@vmware.com Date: Fri Jun 19 23:55:55 2009 +0200 intel: Fixups for 'mesa: create/destroy buffer objects via driver functions'. Initialize all driver function hooks before calling _mesa_initialize_context(), and handle all buffer objects in intel_buffer_object(). Fixes assertion failure when running glxinfo. :04 04 d2d5b6bc870422b08b9fb5a6d196fb390815cbdf 144a2d92751f48321a44430bfe8c4768eec59a97 M src The effect is that the Read/DrawPixels area of the readpix demo is white, and conformance tests all fail. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Sun, 21 Jun 2009, Andrew Lutomirski wrote:
Anyway, here's a totally UNTESTED patch that hopefully gives a warning on
where exactly we set the invalid bits. Andy, mind trying it out? You
should get the warnign much earlier, and it should have a much more useful
back-trace.
Your patch worked. Photo attached.
Ok.
So it's fb_mmap() that uses an invalid page frame number when it does the
io_remap_pfn_range() thing.
And the way it gets that page frame number is basically
- Offset (in bytes) from start of mapping:
off = vma-vm_pgoff PAGE_SHIFT;
..
- frame buffer start address:
/* frame buffer memory */
start = info-fix.smem_start;
len = PAGE_ALIGN((start ~PAGE_MASK) + info-fix.smem_len);
..
off += start;
- do the remap:
io_remap_pfn_range(vma, vma-vm_start, off PAGE_SHIFT, ..
and there has been no changes to this logic in drivers/video/fbmem.c
lately.
What *has* changed is that we have a newradeon driver, and it looks like
that new radeon driver is crap, and does this:
info-fix.smem_start = (unsigned long)fbptr;
which is totally screwed up. It assigns a _virtual_ address to that
smem_start thing, even though it should be a physical one.
I don't know the radeon driver, so I don't know where to find the physical
address. It's also possible that there is no good single physical
address, and the radeon driver should implement a fb_mmap function.
Does this patch make the warning and the oops at least go away? Obviously
it won't result in a working frame buffer, but that's a separate issue
Linus
---
drivers/gpu/drm/radeon/radeon_fb.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index fa86d39..4aa151e 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -380,6 +380,14 @@ int radeonfb_blank(int blank, struct fb_info *info)
return 0;
}
+/*
+ * Not yet implemented. The fix.smem_start is crap.
+ */
+static int radeonfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ return -EINVAL;
+}
+
static struct fb_ops radeonfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = radeonfb_check_var,
@@ -390,6 +398,7 @@ static struct fb_ops radeonfb_ops = {
.fb_imageblit = cfb_imageblit,
.fb_pan_display = radeonfb_pan_display,
.fb_blank = radeonfb_blank,
+ .fb_mmap = radeonfb_mmap,
};
/**
--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Sun, 2009-06-21 at 17:47 +0300, Maxim Levitsky wrote:
52dc7d32b88156248167864f77a9026abe27b432 is first bad commit
commit 52dc7d32b88156248167864f77a9026abe27b432
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Sat Jun 6 09:46:01 2009 +0100
The error here seems to be my presumption that only the i915 was using
fences for GPU access. (In hindsight, it seems obvious that we do not
know why the fence was allocated for the object and so if it has
outstanding rendering, we must assume that it is using a fence for a
rendering op.)
To confirm, please can you try:
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index fd2b8bd..0735518 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2347,7 +2347,7 @@ i915_gem_object_put_fence_reg(struct
drm_gem_object *obj)
* therefore we must wait for any outstanding access to complete
* before clearing the fence.
*/
- if (!IS_I965G(dev)) {
+ if (1) {
int ret;
i915_gem_object_flush_gpu_write_domain(obj);
(I'm travelling tomorrow, so if this does turn out to be the fault, I'd
appreciate it if someone wrote it up as a complete patch.)
However I can't reproduce the situation I have earlier, maybe I have changed
some settings, don't know.
Now, the bad behavior (and I reproduced it many times, is that GE shows
incorrect textures
(like they are divided in tiny interlaced rows, one row ok, other contain
image from other part of world), only few textures are such
it seems logical that this is related to tiling.
What you describe is exactly the artefact you would see when you access
a tiled texture using linear addressing. Pretty conclusive evidence that
we do need to flush outstanding GPU access.
Also, if I maximize it, it hangs. This seems to be a separate bug introduced
by these series.
It does seem like a separate bug. Hopefully, we can get a better handle
on it after we fix this obnoxious tiling issue.
-ickle
--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Sun, 21 Jun 2009, Andrew Lutomirski wrote:
Anyway, here's a totally UNTESTED patch that hopefully gives a warning on
where exactly we set the invalid bits. Andy, mind trying it out? You
should get the warnign much earlier, and it should have a much more useful
back-trace.
Your patch worked. Photo attached.
Ok.
So it's fb_mmap() that uses an invalid page frame number when it does the
io_remap_pfn_range() thing.
And the way it gets that page frame number is basically
- Offset (in bytes) from start of mapping:
off = vma-vm_pgoff PAGE_SHIFT;
..
- frame buffer start address:
/* frame buffer memory */
start = info-fix.smem_start;
len = PAGE_ALIGN((start ~PAGE_MASK) + info-fix.smem_len);
..
off += start;
- do the remap:
io_remap_pfn_range(vma, vma-vm_start, off PAGE_SHIFT, ..
and there has been no changes to this logic in drivers/video/fbmem.c
lately.
What *has* changed is that we have a newradeon driver, and it looks like
that new radeon driver is crap, and does this:
info-fix.smem_start = (unsigned long)fbptr;
which is totally screwed up. It assigns a _virtual_ address to that
smem_start thing, even though it should be a physical one.
I don't know the radeon driver, so I don't know where to find the physical
address. It's also possible that there is no good single physical
address, and the radeon driver should implement a fb_mmap function.
Does this patch make the warning and the oops at least go away? Obviously
it won't result in a working frame buffer, but that's a separate issue
Linus
I noticed the same bogus line myself last night, I'll get Jerome to look
at it since its his code, he was trying to be smart about how the
radeon fbdev emulation should work, but fbdev isn't smart enough to do
what he wants, so I've asked him to go back to the dumb pin the fbcon in
VRAM until we can fix fbdev to do some sort of prepare/commit type hooks
around blocks of reads/writes.
With the safe method we end up with an 8MB pinned fbcon on 32MB in some
scenarios, which is still totally unacceptable from a user pov.
Btw this driver is under staging for a good reason, nobody claimed it was
perfect, we just said we felt it was a good baseline to build the final
driver on top off. Maybe I can add
CONFIG_DONT_CC_LINUS_ON_STAGING_DRIVERS.
Dave.
---
drivers/gpu/drm/radeon/radeon_fb.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index fa86d39..4aa151e 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -380,6 +380,14 @@ int radeonfb_blank(int blank, struct fb_info *info)
return 0;
}
+/*
+ * Not yet implemented. The fix.smem_start is crap.
+ */
+static int radeonfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ return -EINVAL;
+}
+
static struct fb_ops radeonfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = radeonfb_check_var,
@@ -390,6 +398,7 @@ static struct fb_ops radeonfb_ops = {
.fb_imageblit = cfb_imageblit,
.fb_pan_display = radeonfb_pan_display,
.fb_blank = radeonfb_blank,
+ .fb_mmap = radeonfb_mmap,
};
/**
--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Sun, 21 Jun 2009, Dave Airlie wrote: I tried this tree (specifically, a merge of Linus' fb20871 this tree) on Fedora 11 with modesetting enabled on an integrated Radeon 2100, and plymouthd crashes immediately with a corrupt page table. Photo attached. After the crash, bootup stops, although ctrl-alt-del works. You need a different userspace, -ati from koji in F11 should do it. Dave - no amount of userspace differences make a corrupted page table acceptable. I was original responding to a line I saw in his dmesg (which was about an ioctl not being available, I only got to parsing the crash later. This needs to be fixed. No excuses. Kernel crashes are never an issue of you used the wrong user space. Agreed, and we block old userspaces running on KMS kernels (at least trying to use DRI) and I thought that was what he was seeing. Dave. Linus -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22405] New: [regression OGLC] most of cases failed due to commit dd26899ca39111e0866afed9df94bfb1618dd363
http://bugs.freedesktop.org/show_bug.cgi?id=22405 Summary: [regression OGLC] most of cases failed due to commit dd26899ca39111e0866afed9df94bfb1618dd363 Product: Mesa Version: CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: blocker Priority: highest Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: shuang...@intel.com System Environment: -- Arch: i386 Platform: 945GM Mesa(master)df70d3049a396af3601d2a1747770635a74120bb Xserver (master)ae20e748cd3a656173e1f50109bfd4af0712bb87 Xf86_video_intel(master)534e73ad4f234a04755917f2bf17ba821c27eb52 Libdrm (master)2fa2db138ba989bfa1a8cd9ab66d83fb7369249e Bug detailed description: - most OGLC case (like mustpass.c, xformmix.c, vorder.c, ...) failed now. This is caused by following commit: commit dd26899ca39111e0866afed9df94bfb1618dd363 Author: Michel Dänzer daen...@vmware.com Date: Fri Jun 19 23:55:55 2009 +0200 intel: Fixups for 'mesa: create/destroy buffer objects via driver functions'. Initialize all driver function hooks before calling _mesa_initialize_context(), and handle all buffer objects in intel_buffer_object(). Fixes assertion failure when running glxinfo. Reproduce steps: 1.xinit 2. run olgc/mustpass.c ... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
