[Bug 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)
https://bugs.freedesktop.org/show_bug.cgi?id=41086 --- Comment #11 from Andre Tomt 2011-12-10 19:43:05 UTC --- (In reply to comment #9) Ok, so that list wrapped badly. Lets remove redudant information and try again shall we ;-) libdrm-dev 2.4.28+git20111207.dd9a5b4f libdrm-intel1 2.4.28+git20111207.dd9a5b4f libdrm-nouveau1a 2.4.28+git20111207.dd9a5b4f libdrm-radeon1 2.4.28+git20111207.dd9a5b4f libdrm22.4.28+git20111207.dd9a5b4f libegl1-mesa 7.12.0~git20111209.eefff370 libegl1-mesa-dev 7.12.0~git20111209.eefff370 libegl1-mesa-drivers 7.12.0~git20111209.eefff370 libgbm17.12.0~git20111209.eefff370 libgl1-mesa-dev7.12.0~git20111209.eefff370 libgl1-mesa-dri7.12.0~git20111209.eefff370 libgl1-mesa-glx7.12.0~git20111209.eefff370 libglapi-mesa 7.12.0~git20111209.eefff370 libglu1-mesa 7.12.0~git20111209.eefff370 libkms12.4.28+git20111207.dd9a5b4f libopenvg1-mesa7.12.0~git20111209.eefff370 mesa-common-dev7.12.0~git20111209.eefff370 xserver-common 2:1.11.2.902+git20111209+server-1.11-branch.0ca8869e xserver-xorg-core 2:1.11.2.902+git20111209+server-1.11-branch.0ca8869e xserver-xorg-input-evdev 1:2.6.99+git20111201.a9cdb659 xserver-xorg-input-mouse 1:1.7.1+git20111207.8bc8502c xserver-xorg-video-ati 1:6.14.99+git20111207.bc54e415 xserver-xorg-video-intel 2:2.17.0+git20111209.429a36f7 xserver-xorg-video-nouveau 1:0.0.16+git20111207.3d2a752c xserver-xorg-video-radeon 1:6.14.99+git20111207.bc54e415 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)
https://bugs.freedesktop.org/show_bug.cgi?id=41086 --- Comment #10 from Andre Tomt 2011-12-10 19:37:05 UTC --- Created attachment 54311 --> https://bugs.freedesktop.org/attachment.cgi?id=54311 chromium and gnome-terminal corruption -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #6 from GhostlyDeath 2011-12-10 10:16:11 PST --- Created attachment 54304 --> https://bugs.freedesktop.org/attachment.cgi?id=54304 Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #4 from GhostlyDeath 2011-12-10 10:15:34 PST --- Created attachment 54302 --> https://bugs.freedesktop.org/attachment.cgi?id=54302 GLXInfo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #3 from GhostlyDeath 2011-12-10 10:15:12 PST --- Created attachment 54301 --> https://bugs.freedesktop.org/attachment.cgi?id=54301 AdanaxisGPL -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #2 from GhostlyDeath 2011-12-10 10:14:51 PST --- Created attachment 54300 --> https://bugs.freedesktop.org/attachment.cgi?id=54300 NeverBall -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #1 from GhostlyDeath 2011-12-10 10:14:25 PST --- Created attachment 54299 --> https://bugs.freedesktop.org/attachment.cgi?id=54299 OpenArena -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43698] New: On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 Bug #: 43698 Summary: On PPC, OpenGL programs use incorrect texture colors. Classification: Unclassified Product: Mesa Version: git Platform: PowerPC OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: ghostlydeath at gmail.com Created attachment 54298 --> https://bugs.freedesktop.org/attachment.cgi?id=54298 PrBoom With git b1a8b7b0196c73bcfe488cbfc9e9fcd1d7ce7d9b. Texture colors are incorrect, they appear to be ABGR instead of RGBA, thus blue becomes green, red becomes alpha, etc. The only thing that is not affected is glxgears, but that does not use any textures. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30227] [RADEON:KMS:AGP:R300:PPC] random X freeze by a GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=30227 --- Comment #10 from GhostlyDeath 2011-12-10 09:24:52 PST --- Created attachment 54296 --> https://bugs.freedesktop.org/attachment.cgi?id=54296 Dmesg crash This also occurs to me on my system, a PowerPC 7447A PowerMac G4 with an ATI Radeon 9800 Pro AGP (128MB). Using the packages from Debian Squeeze Backports (7.10.3) with a near-Vanilla 3.1.0 kernel with radeon DRM modules built in along with firmware. However, for me it crashes about 10-20 seconds when glxgears is running, or it instantly crashes when I attempt to move or resize a window in WindowMaker. Setting agpmode=-1 fixes the problem for me. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()
https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #7 from Marco Albanese 2011-12-10 03:12:06 PST --- Created attachment 54287 --> https://bugs.freedesktop.org/attachment.cgi?id=54287 Banshee crash with the patch in radeon_fbo.c Sorry, it is the first time I rebuild a pkg on Debian. I've rebuild the whole mesa and installed only the package which contains radeon_dri ( which I suppose is build from radeon_fbo.c ), the pkg libgl1-mesa-dri. However now, trying to show the ClutterFlow panel makes banshee crash. Output attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #5 from GhostlyDeath 2011-12-10 10:15:55 UTC --- Created attachment 54303 --> https://bugs.freedesktop.org/attachment.cgi?id=54303 lspci -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On 09-12-2011 20:50, Robert Morell wrote: > On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: >> On Friday 02 December 2011, Sumit Semwal wrote: >>> This is the first step in defining a dma buffer sharing mechanism. >> > [...] >> >>> + return dmabuf; >>> +} >>> +EXPORT_SYMBOL(dma_buf_export); >> >> I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, >> because it's really a low-level function that I would expect >> to get used by in-kernel subsystems providing the feature to >> users and having back-end drivers, but it's not the kind of thing >> we want out-of-tree drivers to mess with. > > Is this really necessary? If this is intended to be a > lowest-common-denominator between many drivers to allow buffer sharing, > it seems like it needs to be able to be usable by all drivers. > > If the interface is not accessible then I fear many drivers will be > forced to continue to roll their own buffer sharing mechanisms (which is > exactly what we're trying to avoid here, needless to say). Doing a buffer sharing with something that is not GPL is not fun, as, if any issue rises there, it would be impossible to discover if the problem is either at the closed-source driver or at the open source one. At the time I was using the Nvidia proprietary driver, it was very common to have unexplained issues caused likely by bad code there at the buffer management code, causing X applications and extensions (like xv) to break. We should really make this EXPORT_SYMBOL_GPL(), in order to be able to latter debug future share buffer issues, when needed. Regards, Mauro
[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Fri, Dec 9, 2011 at 15:24, Alan Cox wrote: >> I still don't think that's possible. Please explain how you expect >> to change the semantics of the streaming mapping API to allow multiple >> mappers without having explicit serialization points that are visible >> to all users. For simplicity, let's assume a cache coherent system I think I understand the cache flushing issues on arm (we're doing a similar madness with manually flushing caches for i915 because the gpu isn't coherent with the cpu and other dma devices). And I also agree that you cannot make concurrent mappings work without adding something on top of the current streaming api/dma-buf proposal. I just think that it's not the kernel's business (well, at least not dma_buf's business) to enforce that. If userspace (through some driver calls) tries to do stupid things, it'll just get garbage. See Message-ID: for my reasons why it think this is the right way to go forward. So in essence I'm really interested in the reasons why you want the kernel to enforce this (or I'm completely missing what's the contentious issue here). > I would agree. It's not just about barriers but in many cases where you > have multiple mappings by hardware devices the actual hardware interface > is specific to the devices. Just take a look at the fencing in TTM and > the graphics drivers. > > Its not something the low level API can deal with, it requires high level > knowledge. Yes, we might want to add some form of in-kernel sync objects on top of dma_buf, but I'm not really convinced that this will buy us much above simply synchronizing access in userspace with the existing ipc tools. In my experience the expensive part of syncing two graphics engines with the cpu is that we wake up the cpu and prevent it from going into low-power states if we do this too often. Adding some more overhead by going through userspace doesn't really make it much worse. It's a completely different story if there's a hw facility to synchronize engines without the cpu's involvement (like there is on every multi-pipe gpu) and there sync objects make tons of sense. But I'm not aware of that existing on SoCs between different IP blocks. Cheers, Daniel -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
[Bug 31213] [RADEON:KMS:RV370:INIT] [drm] cp init fail (any kernels 2.6.3x.x)
https://bugs.freedesktop.org/show_bug.cgi?id=31213 Jonathan Nieder changed: What|Removed |Added Status|NEW |NEEDINFO -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31213] [RADEON:KMS:RV370:INIT] [drm] cp init fail (any kernels 2.6.3x.x)
https://bugs.freedesktop.org/show_bug.cgi?id=31213 --- Comment #2 from Jonathan Nieder 2011-12-09 16:25:16 PST --- (In reply to comment #0) > when loading the 'radeon' driver with modeset=1 (KMS enabled) > the following error appears in dmesg | grep drm > > [drm:r100_ring_test] *ERROR* radeon: ring test failed > (sracth(0x15E4)=0xCAFEDEAD) > [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). Max: ping? How do current kernels behave? In suspense, Jonathan -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()
https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #7 from Marco Albanese deli...@gmail.com 2011-12-10 03:12:06 PST --- Created attachment 54287 -- https://bugs.freedesktop.org/attachment.cgi?id=54287 Banshee crash with the patch in radeon_fbo.c Sorry, it is the first time I rebuild a pkg on Debian. I've rebuild the whole mesa and installed only the package which contains radeon_dri ( which I suppose is build from radeon_fbo.c ), the pkg libgl1-mesa-dri. However now, trying to show the ClutterFlow panel makes banshee crash. Output attached. -- 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: [mipsel+rs780e]Occasionally GPU lockup after resuming from suspend.
Thank you for your reply. I found CP_RB_WPTR has changed when ring test failed, so I think CP is active, but what it get from ring buffer is wrong. Then, I want to know whether there is a way to check the content that GPU get from ring buffer. BTW, when I use echo shutdown /sys/power/disk; echo disk /sys/power/state to do a hibernation, there will be occasionally GPU reset just like suspend. However, if I use echo reboot /sys/power/disk; echo disk /sys/power/state to do a hibernation and wakeup automatically, there is no GPU reset after hundreds of tests. What does this imply? Power loss cause something break? Best regards, Huacai Chen 2011/12/7 che...@lemote.com: When MC timeout happens at GPU reset, we found the 12th and 13th bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these two bits are like this: #define G_000E50_MCDX_BUSY(x) (((x) 12) 1) #define G_000E50_MCDW_BUSY(x) (((x) 13) 1) Could you please tell me what does they mean? And if possible, They refer to sub-blocks in the memory controller. I don't really know off hand what the name mean. I want to know the functionalities of these 5 registers in detail: #define R_000E60_SRBM_SOFT_RESET 0x0E60 #define R_000E50_SRBM_STATUS 0x0E50 #define R_008020_GRBM_SOFT_RESET0x8020 #define R_008010_GRBM_STATUS0x8010 #define R_008014_GRBM_STATUS2 0x8014 A bit more info: If I reset the MC after resetting CP (this is what Linux-2.6.34 does, but removed since 2.6.35), then MC timeout will disappear, but there is still ring test failed. The bits are defined in r600d.h. As to the acronyms: BIF - Bus InterFace CG - clocks DC - Display Controller GRBM - Graphics block (3D engine) HDP - Host Data Path (CPU access to vram via the PCI BAR) IH, RLC - Interrupt controller MC - Memory controller ROM - ROM SEM - semaphore controller When you reset the MC, you will probably have to reset just about everything else since most blocks depend on the MC for access to memory. If you do reset the MC, you should do it at prior to calling asic_init so you make sure all the hw gets re-initialized properly. Additionally, you should probably reset the GRBM either via SRBM_SOFT_RESET or the individual sub-blocks via GRBM_SOFT_RESET. Alex Huacai Chen 2011/11/8 che...@lemote.com: And, I want to know something: 1, Does GPU use MC to access GTT? Yes. All GPU clients (display, 3D, etc.) go through the MC to access memory (vram or gart). 2, What can cause MC timeout？ Lots of things. Some GPU client still active, some GPU client hung or not properly initialized. Alex Hi, Some status update. 在 2011年9月29日 下午5:17，Chen Jie ch...@lemote.com 写道： Hi, Add more information. We got occasionally GPU lockup after resuming from suspend(on mipsel platform with a mips64 compatible CPU and rs780e, the kernel is 3.1.0-rc8 64bit). Related kernel message: /* return from STR */ [ 156.152343] radeon :01:05.0: WB enabled [ 156.187500] [drm] ring test succeeded in 0 usecs [ 156.187500] [drm] ib test succeeded in 0 usecs [ 156.398437] ata2: SATA link down (SStatus 0 SControl 300) [ 156.398437] ata3: SATA link down (SStatus 0 SControl 300) [ 156.398437] ata4: SATA link down (SStatus 0 SControl 300) [ 156.578125] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 156.597656] ata1.00: configured for UDMA/133 [ 156.613281] usb 1-5: reset high speed USB device number 4 using ehci_hcd [ 157.027343] usb 3-2: reset low speed USB device number 2 using ohci_hcd [ 157.609375] usb 3-3: reset low speed USB device number 3 using ohci_hcd [ 157.683593] r8169 :02:00.0: eth0: link up [ 165.621093] PM: resume of devices complete after 9679.556 msecs [ 165.628906] Restarting tasks ... done. [ 177.085937] radeon :01:05.0: GPU lockup CP stall for more than 10019msec [ 177.089843] [ cut here ] [ 177.097656] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:267 radeon_fence_wait+0x25c/0x33c() [ 177.105468] GPU lockup (waiting for 0x13C3 last fence id 0x13AD) [ 177.113281] Modules linked in: psmouse serio_raw [ 177.117187] Call Trace: [ 177.121093] [806f3e7c] dump_stack+0x8/0x34 [ 177.125000] [8022e4f4] warn_slowpath_common+0x78/0xa0 [ 177.132812] [8022e5b8] warn_slowpath_fmt+0x38/0x44 [ 177.136718] [80522ed8] radeon_fence_wait+0x25c/0x33c [ 177.144531] [804e9e70] ttm_bo_wait+0x108/0x220 [ 177.148437] [8053b478] radeon_gem_wait_idle_ioctl+0x80/0x114 [ 177.156250] [804d2fe8] drm_ioctl+0x2e4/0x3fc [ 177.160156] [805a1820] radeon_kms_compat_ioctl+0x28/0x38 [ 177.167968] [80311a04] compat_sys_ioctl+0x120/0x35c [ 177.171875] [80211d18] handle_sys+0x118/0x138 [ 177.179687] ---[ end trace
[PATCH] drm/vmwgfx: fix incorrect VRAM size check in vmw_kms_fb_create()
The commit e133e737 didn't correctly fix the overflow issue.
- unsigned int required_size;
+ u64 required_size;
...
required_size = mode_cmd-pitch * mode_cmd-height;
- if (unlikely(required_size dev_priv-vram_size)) {
+ if (unlikely(required_size (u64) dev_priv-vram_size)) {
Since pitch and height are u32, their product is still 32-bit and
would overflow. Converting the result to u64 cannot help. A correct
way is to convert pitch and height to u64 before the multiplication.
required_size = (u64)mode_cmd-pitch * (u64)mode_cmd-height;
This fix calls vmw_kms_validate_mode_vram() for validation.
Signed-off-by: Xi Wang xi.w...@gmail.com
Cc: Thomas Hellstrom thellst...@vmware.com
Cc: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 37d4054..582a4d7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1003,7 +1003,6 @@ static struct drm_framebuffer *vmw_kms_fb_create(struct
drm_device *dev,
struct vmw_surface *surface = NULL;
struct vmw_dma_buffer *bo = NULL;
struct ttm_base_object *user_obj;
- u64 required_size;
int ret;
/**
@@ -1012,8 +1011,9 @@ static struct drm_framebuffer *vmw_kms_fb_create(struct
drm_device *dev,
* requested framebuffer.
*/
- required_size = mode_cmd-pitch * mode_cmd-height;
- if (unlikely(required_size (u64) dev_priv-vram_size)) {
+ if (!vmw_kms_validate_mode_vram(dev_priv,
+ mode_cmd-pitch,
+ mode_cmd-height)) {
DRM_ERROR(VRAM size is too small for requested mode.\n);
return ERR_PTR(-ENOMEM);
}
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
On Tue, Dec 6, 2011 at 12:43 PM, Ben Widawsky b...@bwidawsk.net wrote: On Tue, Dec 06, 2011 at 12:12:33PM +0100, Daniel Vetter wrote: The recursion loop goes retire_requests-unbind-gpu_idle-retire_reqeusts. Every time we go through this we need a - active object that can be retired - and there are no other references to that object than the one from the active list, so that it gets unbound and freed immediately. Otherwise the recursion stops. So the recursion is only limited by the number of objects that fit these requirements sitting in the active list any time retire_request is called. Issue exercised by tests/gem_unref_active_buffers from i-g-t. There's been a decent bikeshed discussion whether it wouldn't be better to pass around a flag, but imo this is o.k. for such a limited case that only supports a w/a. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson chris@chris-wilson # we built better bikesheds, but this keeps the rain off for now --- What about: http://lists.freedesktop.org/archives/intel-gfx/2011-October/012984.html Did someone prove that doesn't work? This patch caused hard lockups for me after ~35 minutes of casual use (twice). I've attached the oopses. I'm running a Fedora 16 machine, Lenovo T420 (i5-2540M w/ VT-d enabled), and at each time had a Windows 7 KVM guest idling (not sure if that is relevant). With this patch reverted, I've had ~ 6 hours of oops free uptime. Let me know what additional information I can provide, or if there is anything I can test to help narrow the issue down. yours, Bobby ~~~ [bpowers@fina linux]$ lspci 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4) 00:1d.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset Family LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04) 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34) 0d:00.0 System peripheral: Ricoh Co Ltd Device e823 (rev 08) 0d:00.3 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev 04) [bpowers@fina linux]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz stepping: 7 microcode : 0x18 cpu MHz : 800.000 cache size : 3072 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips: 5184.24 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [3 other processors omitted] i915-list_add-corruption Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
On Fri, Dec 9, 2011 at 6:32 AM, Bobby Powers bobbypow...@gmail.com wrote: On Thu, Dec 8, 2011 at 11:05 PM, Bobby Powers bobbypow...@gmail.com wrote: On Tue, Dec 6, 2011 at 12:43 PM, Ben Widawsky b...@bwidawsk.net wrote: On Tue, Dec 06, 2011 at 12:12:33PM +0100, Daniel Vetter wrote: The recursion loop goes retire_requests-unbind-gpu_idle-retire_reqeusts. Every time we go through this we need a - active object that can be retired - and there are no other references to that object than the one from the active list, so that it gets unbound and freed immediately. Otherwise the recursion stops. So the recursion is only limited by the number of objects that fit these requirements sitting in the active list any time retire_request is called. Issue exercised by tests/gem_unref_active_buffers from i-g-t. There's been a decent bikeshed discussion whether it wouldn't be better to pass around a flag, but imo this is o.k. for such a limited case that only supports a w/a. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson chris@chris-wilson # we built better bikesheds, but this keeps the rain off for now --- What about: http://lists.freedesktop.org/archives/intel-gfx/2011-October/012984.html Did someone prove that doesn't work? This patch caused hard lockups for me after ~35 minutes of casual use (twice). I've attached the oopses. I'm running a Fedora 16 machine, Lenovo T420 (i5-2540M w/ VT-d enabled), and at each time had a Windows 7 KVM guest idling (not sure if that is relevant). With this patch reverted, I've had ~ 6 hours of oops free uptime. To be clear, by 'this patch' I mean commit eb1711bb [PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a on Linus's branch, not the patch Ben linked to. Let me know what additional information I can provide, or if there is anything I can test to help narrow the issue down. Additionally I have i915.i915_enable_rc6=1 on the kernel command line. yours, Bobby ~~~ [bpowers@fina linux]$ lspci 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4) 00:1d.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset Family LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04) 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34) 0d:00.0 System peripheral: Ricoh Co Ltd Device e823 (rev 08) 0d:00.3 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev 04) [bpowers@fina linux]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz stepping : 7 microcode : 0x18 cpu MHz : 800.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips : 5184.24 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [3 other processors omitted]
[PATCH] drm: Enable reading 3D capabilities of 3D monitor
This is first of the patches to enable reading the 3D capabilities of a
connected monitor on
HDMI. Similar functionality would also be implemented for other interface, eDP,
DP
The idea is to read the 3D capabilities via EDID and provide this to a user
space application
that would want to switch the mode of the connected monitor to a specific 3D
format. The
implementation follows the HDMI 1.4a specification.
From 95dc9536dc1a863a4a2d12836ead338835a4be59 Mon Sep 17 00:00:00 2001
From: Sateesh Kavuri sateesh.kav...@intel.com
Date: Wed, 7 Dec 2011 14:49:20 +0530
Subject: [PATCH] This patch enables the reading of the 3D capabilities of the
connected
HDMI monitor. Currently only the 3D format support fields are read.
Later this could be extended. This information is expected to be sent to
the user space which then sets the format on the monitor.
This patch also handles DIP register signaling to the HDMI connected 3D
monitor the 3D format to be set
---
Signed-off-by: Sateesh Kavuri sateesh.kav...@intel.com
---
---
drivers/gpu/drm/drm_edid.c| 109 +
drivers/gpu/drm/i915/intel_drv.h | 11
drivers/gpu/drm/i915/intel_hdmi.c | 119 +
include/drm/drm_crtc.h|2 +
include/drm/drm_edid.h| 20 ++
5 files changed, 261 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fe39c35..5d4a425 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1321,6 +1321,8 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
#define EDID_BASIC_AUDIO (1 6)
+#define MONITOR_VIDEO_PRESENT 0x01
+#define PANEL_SUPPORTS_3D 0x01
/**
* Search EDID for CEA extension block.
@@ -1610,6 +1612,113 @@ end:
}
EXPORT_SYMBOL(drm_detect_monitor_audio);
+enum {
+ NO_SPL_CAPS = 0x0,
+ STRUCTURE_PRESENT = 0x1,
+ STRUCTURE_MASK_PRESENT = 0x2
+} are_3d_caps_present;
+
+/**
+ * drm_detect_monitor_3D - check monitor 3D capabilities
+ *
+ * Monitor should have CEA extension block.
+ * Check if the monitor has 3D capabilities. If it does, store the capabilitie
+ * to a data structure
+ *
+ * FIXME: Currently returning bool (to denote 3D present or not), later should
+ * return the 3D capabilities (or can there be a separate function for that?)
+ */
+bool drm_detect_3D_monitor(struct edid *edid)
+{
+ u8 *edid_ext;
+ int i, hdmi_id;
+ int start_offset, end_offset;
+ bool is_hdmi = false;
+ bool is_3d = false;
+ struct panel_3d_caps *caps = kmalloc(sizeof(struct panel_3d_caps),
GFP_KERNEL);
+
+ edid_ext = drm_find_cea_extension(edid);
+ if (!edid_ext)
+ goto end;
+
+ /* Data block offset in CEA extension block */
+ start_offset = 4;
+ end_offset = edid_ext[2];
+
+ /* 3D vars */
+ int multi_present = 0;
+
+ /*
+* Because HDMI identifier is in Vendor Specific Block,
+* search it from all data blocks of CEA extension.
+*/
+ for (i = start_offset; i end_offset;
+ /* Increased by data block len */
+ i += ((edid_ext[i] 0x1f) + 1)) {
+ /* Find vendor specific block */
+ /* 6'th bit is the VIDEO_PRESENT bit */
+ if ( ((edid_ext[i] 5) == VENDOR_BLOCK)
+((edid_ext[i+8] 0x20) == MONITOR_VIDEO_PRESENT) ) {
+ hdmi_id = edid_ext[i + 1] | (edid_ext[i + 2] 8) |
+ edid_ext[i + 3] 16;
+ /* Find HDMI identifier */
+ if (hdmi_id == HDMI_IDENTIFIER)
+ is_hdmi = true;
+
+ /* Check for the 3D_Present flag */
+ if ((edid_ext[i+13] 6) == PANEL_SUPPORTS_3D) {
+ caps-panel_supports_3d = 1;
+ is_3d = true;
+ }
+
+ /* Check if 3D_Multi_present is set */
+ if ((edid_ext[i+13] 0x60) == 0x0) {
+ multi_present = true;
+ }
+
+ /* Collect 3D capabilities of the monitor */
+ int hdmi_3d_len = 0;
+ int hdmi_vic_len = 0;
+ hdmi_vic_len = (edid_ext[i+14] 0x05);
+ hdmi_3d_len = ((edid_ext[i+14] 0x03) 0x03);
+ int multi_val = edid_ext[i+13] 0x6;
+ if (multi_val == 0x0)
+ multi_present = NO_SPL_CAPS;
+ else if (multi_val == 0x1)
+ multi_present = STRUCTURE_PRESENT;
+ else if (multi_val == 0x2)
+ multi_val = STRUCTURE_MASK_PRESENT;
+
+
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: On Friday 02 December 2011, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. [...] + return dmabuf; +} +EXPORT_SYMBOL(dma_buf_export); I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, because it's really a low-level function that I would expect to get used by in-kernel subsystems providing the feature to users and having back-end drivers, but it's not the kind of thing we want out-of-tree drivers to mess with. Is this really necessary? If this is intended to be a lowest-common-denominator between many drivers to allow buffer sharing, it seems like it needs to be able to be usable by all drivers. If the interface is not accessible then I fear many drivers will be forced to continue to roll their own buffer sharing mechanisms (which is exactly what we're trying to avoid here, needless to say). - Robert ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On 09-12-2011 20:50, Robert Morell wrote: On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: On Friday 02 December 2011, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. [...] + return dmabuf; +} +EXPORT_SYMBOL(dma_buf_export); I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, because it's really a low-level function that I would expect to get used by in-kernel subsystems providing the feature to users and having back-end drivers, but it's not the kind of thing we want out-of-tree drivers to mess with. Is this really necessary? If this is intended to be a lowest-common-denominator between many drivers to allow buffer sharing, it seems like it needs to be able to be usable by all drivers. If the interface is not accessible then I fear many drivers will be forced to continue to roll their own buffer sharing mechanisms (which is exactly what we're trying to avoid here, needless to say). Doing a buffer sharing with something that is not GPL is not fun, as, if any issue rises there, it would be impossible to discover if the problem is either at the closed-source driver or at the open source one. At the time I was using the Nvidia proprietary driver, it was very common to have unexplained issues caused likely by bad code there at the buffer management code, causing X applications and extensions (like xv) to break. We should really make this EXPORT_SYMBOL_GPL(), in order to be able to latter debug future share buffer issues, when needed. Regards, Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30227] [RADEON:KMS:AGP:R300:PPC] random X freeze by a GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=30227 --- Comment #10 from GhostlyDeath ghostlyde...@gmail.com 2011-12-10 09:24:52 PST --- Created attachment 54296 -- https://bugs.freedesktop.org/attachment.cgi?id=54296 Dmesg crash This also occurs to me on my system, a PowerPC 7447A PowerMac G4 with an ATI Radeon 9800 Pro AGP (128MB). Using the packages from Debian Squeeze Backports (7.10.3) with a near-Vanilla 3.1.0 kernel with radeon DRM modules built in along with firmware. However, for me it crashes about 10-20 seconds when glxgears is running, or it instantly crashes when I attempt to move or resize a window in WindowMaker. Setting agpmode=-1 fixes the problem for me. -- 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 43698] New: On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 Bug #: 43698 Summary: On PPC, OpenGL programs use incorrect texture colors. Classification: Unclassified Product: Mesa Version: git Platform: PowerPC OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: ghostlyde...@gmail.com Created attachment 54298 -- https://bugs.freedesktop.org/attachment.cgi?id=54298 PrBoom With git b1a8b7b0196c73bcfe488cbfc9e9fcd1d7ce7d9b. Texture colors are incorrect, they appear to be ABGR instead of RGBA, thus blue becomes green, red becomes alpha, etc. The only thing that is not affected is glxgears, but that does not use any textures. -- 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 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #1 from GhostlyDeath ghostlyde...@gmail.com 2011-12-10 10:14:25 PST --- Created attachment 54299 -- https://bugs.freedesktop.org/attachment.cgi?id=54299 OpenArena -- 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 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #2 from GhostlyDeath ghostlyde...@gmail.com 2011-12-10 10:14:51 PST --- Created attachment 54300 -- https://bugs.freedesktop.org/attachment.cgi?id=54300 NeverBall -- 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 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #3 from GhostlyDeath ghostlyde...@gmail.com 2011-12-10 10:15:12 PST --- Created attachment 54301 -- https://bugs.freedesktop.org/attachment.cgi?id=54301 AdanaxisGPL -- 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 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #4 from GhostlyDeath ghostlyde...@gmail.com 2011-12-10 10:15:34 PST --- Created attachment 54302 -- https://bugs.freedesktop.org/attachment.cgi?id=54302 GLXInfo -- 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 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #5 from GhostlyDeath ghostlyde...@gmail.com 2011-12-10 10:15:55 UTC --- Created attachment 54303 -- https://bugs.freedesktop.org/attachment.cgi?id=54303 lspci -- 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 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #6 from GhostlyDeath ghostlyde...@gmail.com 2011-12-10 10:16:11 PST --- Created attachment 54304 -- https://bugs.freedesktop.org/attachment.cgi?id=54304 Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)
https://bugs.freedesktop.org/show_bug.cgi?id=41086 --- Comment #9 from Andre Tomt an...@tomt.net 2011-12-10 19:35:59 PST --- I'm seeing similar corruption with tvbrowser, however I cant make it 'stick'. It corrupts only during the scrolling, and as mentioned, only when scolling sideways to the right. I do however see similar corruption a lot in other apps, that sticks until redraw. And it seems related to text rendering, not especially to scrolling. I suspect its the same issue as the corruption looks quite similar. I see it most often in the bookmarks bar of Chromium, there it shows up usually after 1-2 hovers with the mouse pointer. Just make sure the bar is visible, and add some bookmarks there (with label). Sometimes gnome-terminal also corrupts, and for example the torrent list in Transmission. When I focus the window, the corruption disapears (until it corrupts again), probably gets redrawn? AFAICT it is independent of compositing; it happens in gnome's fallback mode also, and xfce4 w/ compositing disabled. Attaching a screen shot that shows both chromium and gnome-terminal corrupting. Using the same xorg stack I see it on AMD Radeon HD4780, HD5450, HD5770 and HD6670, but not on Intel HD2000 (Sandy Bridge). Verified with kernel 3.0.x, 3.1.x and 3.2-rc5. No xorg.conf, no weird radeon module options. The stack looks like this, its basicly pure builds from git, with xorg core from the 1.11 branch (xorg-edgers PPA on Ubuntu 11.10): libdrm-dev 2.4.28+git20111207.dd9a5b4f-0ubuntu0sarvatt~oneiric libdrm-intel1 2.4.28+git20111207.dd9a5b4f-0ubuntu0sarvatt~oneiric libdrm-nouveau1a 2.4.28+git20111207.dd9a5b4f-0ubuntu0sarvatt~oneiric libdrm-radeon1 2.4.28+git20111207.dd9a5b4f-0ubuntu0sarvatt~oneiric libdrm2 2.4.28+git20111207.dd9a5b4f-0ubuntu0sarvatt~oneiric libegl1-mesa 7.12.0~git20111209.eefff370-0ubuntu0sarvatt~oneiric libegl1-mesa-dev 7.12.0~git20111209.eefff370-0ubuntu0sarvatt~oneiric libegl1-mesa-drivers 7.12.0~git20111209.eefff370-0ubuntu0sarvatt~oneiric libgbm1 7.12.0~git20111209.eefff370-0ubuntu0sarvatt~oneiric libgl1-mesa-dev 7.12.0~git20111209.eefff370-0ubuntu0sarvatt~oneiric libgl1-mesa-dri 7.12.0~git20111209.eefff370-0ubuntu0sarvatt~oneiric libgl1-mesa-glx 7.12.0~git20111209.eefff370-0ubuntu0sarvatt~oneiric libglapi-mesa 7.12.0~git20111209.eefff370-0ubuntu0sarvatt~oneiric libglu1-mesa 7.12.0~git20111209.eefff370-0ubuntu0sarvatt~oneiric libkms1 2.4.28+git20111207.dd9a5b4f-0ubuntu0sarvatt~oneiric libopenvg1-mesa 7.12.0~git20111209.eefff370-0ubuntu0sarvatt~oneiric mesa-common-dev 7.12.0~git20111209.eefff370-0ubuntu0sarvatt~oneiric xserver-common 2:1.11.2.902+git20111209+server-1.11-branch.0ca8869e-0ubuntu0sarvatt~oneiric xserver-xorg-core 2:1.11.2.902+git20111209+server-1.11-branch.0ca8869e-0ubuntu0sarvatt~oneiric xserver-xorg-input-evdev 1:2.6.99+git20111201.a9cdb659-0ubuntu0sarvatt~oneiric xserver-xorg-input-mouse 1:1.7.1+git20111207.8bc8502c-0ubuntu0sarvatt~oneiric xserver-xorg-input-vmmouse 1:12.7.0+git2009.fd140bfb-0ubuntu0sarvatt2~oneiric xserver-xorg-video-ati 1:6.14.99+git20111207.bc54e415-0ubuntu0sarvatt~oneiric xserver-xorg-video-cirrus1:1.3.2+git20110912.e4f80ffd-0ubuntu0sarvatt xserver-xorg-video-fbdev 1:0.4.2+git2009.a8721393-0ubuntu0sarvatt~oneiric xserver-xorg-video-intel 2:2.17.0+git20111209.429a36f7-0ubuntu0sarvatt~oneiric xserver-xorg-video-mach64 6.9.0+git2009.0de23432-0ubuntu0sarvatt~oneiric xserver-xorg-video-mga 1:1.4.13.dsfg+git20110928.07792ef4-0ubuntu0sarvatt xserver-xorg-video-neomagic 1:1.2.5+git2009.f2a771c6-0ubuntu0sarvatt~oneiric xserver-xorg-video-nouveau 1:0.0.16+git20111207.3d2a752c-0ubuntu0sarvatt~oneiric xserver-xorg-video-openchrome1:0.2.904+svn920-1ubuntu0sarvatt xserver-xorg-video-r128 6.8.1+git2009.67aaa469-0ubuntu0sarvatt~oneiric xserver-xorg-video-radeon 1:6.14.99+git20111207.bc54e415-0ubuntu0sarvatt~oneiric xserver-xorg-video-s3 1:0.6.3+git2009.381ace93-0ubuntu0sarvatt~oneiric xserver-xorg-video-savage 1:2.3.3+git2009.8b9c81ba-0ubuntu0sarvatt~oneiric xserver-xorg-video-siliconmotion 1:1.7.5+git2018.7d9c1a49-0ubuntu0sarvatt~oneiric xserver-xorg-video-sis 1:0.10.3+git20110913.94f23a56+really0.10.3-0ubuntu0sarvatt xserver-xorg-video-sisusb 1:0.9.4+git2009.02451944-0ubuntu0sarvatt~oneiric xserver-xorg-video-tdfx 1:1.4.3+git2018.4ea96c22-0ubuntu0sarvatt~oneiric xserver-xorg-video-trident 1:1.3.4+git2009.6afbfaf6-0ubuntu0sarvatt~oneiric xserver-xorg-video-vesa
[Bug 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)
https://bugs.freedesktop.org/show_bug.cgi?id=41086 --- Comment #10 from Andre Tomt an...@tomt.net 2011-12-10 19:37:05 UTC --- Created attachment 54311 -- https://bugs.freedesktop.org/attachment.cgi?id=54311 chromium and gnome-terminal corruption -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)
https://bugs.freedesktop.org/show_bug.cgi?id=41086 --- Comment #11 from Andre Tomt an...@tomt.net 2011-12-10 19:43:05 UTC --- (In reply to comment #9) Ok, so that list wrapped badly. Lets remove redudant information and try again shall we ;-) libdrm-dev 2.4.28+git20111207.dd9a5b4f libdrm-intel1 2.4.28+git20111207.dd9a5b4f libdrm-nouveau1a 2.4.28+git20111207.dd9a5b4f libdrm-radeon1 2.4.28+git20111207.dd9a5b4f libdrm22.4.28+git20111207.dd9a5b4f libegl1-mesa 7.12.0~git20111209.eefff370 libegl1-mesa-dev 7.12.0~git20111209.eefff370 libegl1-mesa-drivers 7.12.0~git20111209.eefff370 libgbm17.12.0~git20111209.eefff370 libgl1-mesa-dev7.12.0~git20111209.eefff370 libgl1-mesa-dri7.12.0~git20111209.eefff370 libgl1-mesa-glx7.12.0~git20111209.eefff370 libglapi-mesa 7.12.0~git20111209.eefff370 libglu1-mesa 7.12.0~git20111209.eefff370 libkms12.4.28+git20111207.dd9a5b4f libopenvg1-mesa7.12.0~git20111209.eefff370 mesa-common-dev7.12.0~git20111209.eefff370 xserver-common 2:1.11.2.902+git20111209+server-1.11-branch.0ca8869e xserver-xorg-core 2:1.11.2.902+git20111209+server-1.11-branch.0ca8869e xserver-xorg-input-evdev 1:2.6.99+git20111201.a9cdb659 xserver-xorg-input-mouse 1:1.7.1+git20111207.8bc8502c xserver-xorg-video-ati 1:6.14.99+git20111207.bc54e415 xserver-xorg-video-intel 2:2.17.0+git20111209.429a36f7 xserver-xorg-video-nouveau 1:0.0.16+git20111207.3d2a752c xserver-xorg-video-radeon 1:6.14.99+git20111207.bc54e415 -- 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
