Re: GPU hung with Linux-3.2-rc6
On Thu, Dec 22, 2011 at 01:45:20AM +0100, Udo Steinberg wrote: > On Wed, 21 Dec 2011 14:55:07 -0800 Keith Packard (KP) wrote: > > KP> On Wed, 21 Dec 2011 22:26:26 +0100, Udo Steinberg > wrote: > KP> > KP> > That makes the problem go away. If you need more help tracking down the > KP> > problem, then let me know. I can reproduce it fairly easily with > something > KP> > as simple as: > KP> > > KP> > while true; do dmesg; done > KP> > KP> Are you using SNA? > > I don't think so. I'm using the following packages: > > xorg-server-1.9.5 > xf86-video-intel-2.15.0 > libdrm-2.4.25 > mesa-7.10.2 > > I quick google search suggests that at least some of them are too old to > support SNA. Can you please apply the patch available at http://cgit.freedesktop.org/~danvet/drm/patch/?id=0b3ecfa8c9b00f50d514fbcc12e34882b0fa695a This one will let your gpu keep hanging in the "stuck on semphore wait" condition. Later on the hangcheck should kick in and grab a gpu error state (in the file i915_error_state in debugfs). Can you please attach that one? Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GPU hung with Linux-3.2-rc6
On Thu, 22 Dec 2011 01:45:20 +0100, Udo Steinberg wrote: > I quick google search suggests that at least some of them are too old to > support SNA. Sounds good. If you can capture the error as Daniel suggests, that would be great. In any case, I'll post a revert of the semaphore enable patch as it looks like that's still not working right... -- keith.pack...@intel.com pgpgeketNOZlC.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] remove drm_sman and some i815 fixes
Hi Dave, I've failed to correctly fix the via hang in the reclaim buffers rework till now, so I'm only submitting the drm_sman removal of my drm cruft removal series. While beating on this stuff with my i815 I've discovered a preexisting use-after free issue in lastclose (which is new compared to what I've submitted to dri-devel) and a reclaim buffers locking problem. Also added these two patches. Please pull for 3.3. Thanks, Daniel -- The following changes since commit 4cf73129cbe001b41be2f8b56f763fbf3acaa4ce: Merge remote-tracking branch 'pfdo/drm-fixes' into drm-core-next (2011-12-21 09:50:56 +) are available in the git repository at: git://people.freedesktop.org/~danvet/drm for-airlied Daniel Vetter (12): drm/sis: track obj->drm_fd relations in the driver drm/via: track obj->drm_fd relations in the driver drm/sman: kill owner tracking interface functions drm/sman: rip out owner tracking drm/via: track user->memblock mapping with idr drm/sis: track user->memblock mapping with idr drm/sman: kill user_hash_tab drm/via: use drm_mm instead of drm_sman drm/sis: use drm_mm instead of drm_sman drm: kill drm_sman drm/i810: cleanup reclaim_buffers drm/i810: don't acces hw regs in lastclose drivers/gpu/drm/Makefile|2 +- drivers/gpu/drm/drm_sman.c | 351 --- drivers/gpu/drm/i810/i810_dma.c | 19 ++- drivers/gpu/drm/i810/i810_drv.c |1 - drivers/gpu/drm/i810/i810_drv.h |6 +- drivers/gpu/drm/sis/sis_drv.c | 33 - drivers/gpu/drm/sis/sis_drv.h |7 +- drivers/gpu/drm/sis/sis_mm.c| 196 +-- drivers/gpu/drm/via/via_drv.c | 25 +++ drivers/gpu/drm/via/via_drv.h |7 +- drivers/gpu/drm/via/via_map.c | 10 +- drivers/gpu/drm/via/via_mm.c| 132 ++- include/drm/drm_sman.h | 176 include/drm/sis_drm.h |4 + include/drm/via_drm.h |4 + 15 files changed, 289 insertions(+), 684 deletions(-) delete mode 100644 drivers/gpu/drm/drm_sman.c delete mode 100644 include/drm/drm_sman.h -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()
https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #8 from Johannes Obermayr 2011-12-22 12:35:52 PST --- Created attachment 54712 --> https://bugs.freedesktop.org/attachment.cgi?id=54712 'grep radeon_update_wrapper' from debug build OpenGL version string: 1.3 Mesa 7.12-devel (9f8573b) I hope this is enough. I can also provide the full log (~3.2 MiB uncompressed). -- 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/i915: kill i915_mem.c
Some decent history digging indicates that this was to be used for the
GLX_MESA_allocate_memory extension but never actually implemented for
any released i915 userspace code.
So just rip it out.
Cc: Dave Airlie
Cc: Keith Whitwell
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c |2 +
drivers/gpu/drm/i915/i915_dma.c | 13 +-
drivers/gpu/drm/i915/i915_drv.h | 13 --
drivers/gpu/drm/i915/i915_mem.c | 387 ---
4 files changed, 6 insertions(+), 409 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/i915_mem.c
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 904d7e9..6bfc5ce 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -37,6 +37,7 @@
#include "drm_core.h"
#include "linux/pci.h"
+#include "linux/export.h"
/**
* Get the bus id.
@@ -353,3 +354,4 @@ int drm_noop(struct drm_device *dev, void *data,
DRM_DEBUG("\n");
return 0;
}
+EXPORT_SYMBOL(drm_noop);
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a9ae374..71a1946 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2243,9 +2243,6 @@ void i915_driver_lastclose(struct drm_device * dev)
i915_gem_lastclose(dev);
- if (dev_priv->agp_heap)
- i915_mem_takedown(&(dev_priv->agp_heap));
-
i915_dma_cleanup(dev);
}
@@ -2253,8 +2250,6 @@ void i915_driver_preclose(struct drm_device * dev, struct
drm_file *file_priv)
{
drm_i915_private_t *dev_priv = dev->dev_private;
i915_gem_release(dev, file_priv);
- if (!drm_core_check_feature(dev, DRIVER_MODESET))
- i915_mem_release(dev, file_priv, dev_priv->agp_heap);
}
void i915_driver_postclose(struct drm_device *dev, struct drm_file *file)
@@ -2273,11 +2268,11 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF_DRV(I915_ALLOC, i915_mem_alloc, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_FREE, i915_mem_free, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, i915_mem_init_heap,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_CMDBUFFER, i915_cmdbuffer, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP, i915_mem_destroy_heap,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_SET_VBLANK_PIPE, i915_vblank_pipe_set,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GET_VBLANK_PIPE, i915_vblank_pipe_get,
DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_VBLANK_SWAP, i915_vblank_swap, DRM_AUTH),
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 554bef7..0dceb4a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -327,7 +327,6 @@ typedef struct drm_i915_private {
int tex_lru_log_granularity;
int allow_batchbuffer;
- struct mem_block *agp_heap;
unsigned int sr01, adpa, ppcr, dvob, dvoc, lvds;
int vblank_pipe;
int num_pipe;
@@ -1070,18 +1069,6 @@ extern void i915_destroy_error_state(struct drm_device
*dev);
#endif
-/* i915_mem.c */
-extern int i915_mem_alloc(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-extern int i915_mem_free(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
-extern int i915_mem_init_heap(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-extern int i915_mem_destroy_heap(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
-extern void i915_mem_takedown(struct mem_block **heap);
-extern void i915_mem_release(struct drm_device * dev,
-struct drm_file *file_priv, struct mem_block
*heap);
/* i915_gem.c */
int i915_gem_init_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/i915/i915_mem.c b/drivers/gpu/drm/i915/i915_mem.c
deleted file mode 100644
index cc8f6d4..000
--- a/drivers/gpu/drm/i915/i915_mem.c
+++ /dev/null
@@ -1,387 +0,0 @@
-/* i915_mem.c -- Simple agp/fb memory manager for i915 -*- linux-c -*-
- */
-/*
- * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
Re: [PULL] remove drm_sman and some i815 fixes
> Hi Dave, > > I've failed to correctly fix the via hang in the reclaim buffers rework > till now, so I'm only submitting the drm_sman removal of my drm cruft > removal series. Last attempt at your branch still had problem. Start I didn't have time track down the exact issue. I'm cloning the below branch and will test it. Thanks for cleanup. > While beating on this stuff with my i815 I've discovered a preexisting > use-after free issue in lastclose (which is new compared to what I've > submitted to dri-devel) and a reclaim buffers locking problem. Also added > these two patches. > > Please pull for 3.3. > > Thanks, Daniel > > -- > The following changes since commit 4cf73129cbe001b41be2f8b56f763fbf3acaa4ce: > > Merge remote-tracking branch 'pfdo/drm-fixes' into drm-core-next > (2011-12-21 09:50:56 +) > > are available in the git repository at: > > git://people.freedesktop.org/~danvet/drm for-airlied > > Daniel Vetter (12): > drm/sis: track obj->drm_fd relations in the driver > drm/via: track obj->drm_fd relations in the driver > drm/sman: kill owner tracking interface functions > drm/sman: rip out owner tracking > drm/via: track user->memblock mapping with idr > drm/sis: track user->memblock mapping with idr > drm/sman: kill user_hash_tab > drm/via: use drm_mm instead of drm_sman > drm/sis: use drm_mm instead of drm_sman > drm: kill drm_sman > drm/i810: cleanup reclaim_buffers > drm/i810: don't acces hw regs in lastclose > > drivers/gpu/drm/Makefile|2 +- > drivers/gpu/drm/drm_sman.c | 351 > --- > drivers/gpu/drm/i810/i810_dma.c | 19 ++- > drivers/gpu/drm/i810/i810_drv.c |1 - > drivers/gpu/drm/i810/i810_drv.h |6 +- > drivers/gpu/drm/sis/sis_drv.c | 33 - > drivers/gpu/drm/sis/sis_drv.h |7 +- > drivers/gpu/drm/sis/sis_mm.c| 196 +-- > drivers/gpu/drm/via/via_drv.c | 25 +++ > drivers/gpu/drm/via/via_drv.h |7 +- > drivers/gpu/drm/via/via_map.c | 10 +- > drivers/gpu/drm/via/via_mm.c| 132 ++- > include/drm/drm_sman.h | 176 > include/drm/sis_drm.h |4 + > include/drm/via_drm.h |4 + > 15 files changed, 289 insertions(+), 684 deletions(-) > delete mode 100644 drivers/gpu/drm/drm_sman.c > delete mode 100644 include/drm/drm_sman.h > -- > Daniel Vetter > Mail: dan...@ffwll.ch > Mobile: +41 (0)79 365 57 48 > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
TTM and AGP conflicts
Hi! I updated the openchrome tree and while testing on the AGP system discovered some interesting problems with the new TTM changes. The problems center around the ttm_tt_[un]populate which I modeled after the radeon and nouveau driver. First problem I noticed was on a AGP system that my ttm_tt_populate function would oops. Tracking it down I found the problem was the ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once my ttm_tt_populate function would attempt to touch the dma_address it would oops. The second issue is the assumption of the cast for struct ttm_tt in both the populate and unpopulate function. For the AGP case the proper case would be to ttm_agp_backend. At this point my assumption is the ttm_bo_move function has to be rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau drivers I don't see that testing happening. Am I just missing something? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: TTM and AGP conflicts
On Thu, Dec 22, 2011 at 4:56 PM, James Simmons wrote: > > Hi! > > I updated the openchrome tree and while testing on the AGP system > discovered some interesting problems with the new TTM changes. The > problems center around the ttm_tt_[un]populate which I modeled after the > radeon and nouveau driver. > First problem I noticed was on a AGP system that my ttm_tt_populate > function would oops. Tracking it down I found the problem was the > ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once my > ttm_tt_populate function would attempt to touch the dma_address it would > oops. The second issue is the assumption of the cast for struct ttm_tt in > both the populate and unpopulate function. For the AGP case the proper > case would be to ttm_agp_backend. > At this point my assumption is the ttm_bo_move function has to be > rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all > cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau > drivers I don't see that testing happening. Am I just missing something? Happens on AGP radeons as well: https://bugs.freedesktop.org/show_bug.cgi?id=43719 Alex > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] remove drm_sman and some i815 fixes
On Thu, Dec 22, 2011 at 09:48:35PM +, James Simmons wrote: > > > Hi Dave, > > > > I've failed to correctly fix the via hang in the reclaim buffers rework > > till now, so I'm only submitting the drm_sman removal of my drm cruft > > removal series. > > Last attempt at your branch still had problem. Start I didn't have time > track down the exact issue. I'm cloning the below branch and will test it. > Thanks for cleanup. Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've reported and noticed that the X server fails to start up (and that the kernel hangs). Is that the same you're seeing? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] remove drm_sman and some i815 fixes
> > > Hi Dave, > > > > > > I've failed to correctly fix the via hang in the reclaim buffers rework > > > till now, so I'm only submitting the drm_sman removal of my drm cruft > > > removal series. > > > > Last attempt at your branch still had problem. Start I didn't have time > > track down the exact issue. I'm cloning the below branch and will test it. > > Thanks for cleanup. > > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've > reported and noticed that the X server fails to start up (and that the > kernel hangs). Is that the same you're seeing? What was just merged to drm-next works fine. Its the reclaim buffer patches that cause the problem. In my case the X server starts but I get a blank screen. I have full debug on so this is what happens. Initializing cgroup subsys cpu Linux version 3.2.0-rc6-openchrome+ (jsimmons@debian) (gcc version 4.6.2 (Debian 4.6.2-7) ) #41 SMP Thu Dec 22 17:37:42 EST 2011 Command line: BOOT_IMAGE=/boot/vmlinuz-test root=UUID=2539cb3b-47b9-47fc-81c1-97dabc51b2b2 ro drm.debug=255 BIOS-provided physical RAM map: BIOS-e820: - 0009f400 (usable) BIOS-e820: 0009f400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7bef (usable) BIOS-e820: 7bef - 7bef3000 (ACPI NVS) BIOS-e820: 7bef3000 - 7bf0 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) NX (Execute Disable) protection: active DMI 2.3 present. DMI: MICRO-STAR INTERNATIONAL CO., LTD MS-7312/MS-7312, BIOS V1.2 01/25/2007 e820 update range: - 0001 (usable) ==> (reserved) e820 remove range: 000a - 0010 (usable) AGP bridge at 00:00:00 Aperture from AGP @ e800 old size 32 MB Aperture from AGP @ e800 size 128 MB (APSIZE f20) last_pfn = 0x7bef0 max_arch_pfn = 0x4 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-B uncachable C-C7FFF write-protect C8000-CBFFF uncachable CC000-D3FFF write-back D4000-F uncachable MTRR variable ranges enabled: 0 base 00 mask FFC000 write-back 1 base 004000 mask FFE000 write-back 2 base 006000 mask FFF000 write-back 3 base 007000 mask FFF800 write-back 4 base 007800 mask FFFC00 write-back 5 base 007BF0 mask F0 uncachable 6 base 00E800 mask FFF800 write-combining 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 initial memory mapped : 0 - 2000 Base memory trampoline at [8809d000] 9d000 size 8192 init_memory_mapping: -7bef 00 - 007be0 page 2M 007be0 - 007bef page 4k kernel direct mapping tables up to 7bef @ 1fffc000-2000 RAMDISK: 37aba000 - 37d55000 ACPI: RSDP 000f78c0 00014 (v00 VIAK8M) ACPI: RSDT 7bef3040 0002C (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: FACP 7bef30c0 00074 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: DSDT 7bef3180 05396 (v01 VIAK8M AWRDACPI 1000 MSFT 010E) ACPI: FACS 7bef 00040 ACPI: APIC 7bef8580 00068 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: Local APIC address 0xfee0 [ea00-ea0001bf] PMD -> [88007960-88007b1f] on node 0 Zone PFN ranges: DMA 0x0010 -> 0x1000 DMA320x1000 -> 0x0010 Normal empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x0010 -> 0x009f 0: 0x0100 -> 0x0007bef0 On node 0 totalpages: 507519 DMA zone: 56 pages used for memmap DMA zone: 2 pages reserved DMA zone: 3925 pages, LIFO batch:0 DMA32 zone: 6885 pages used for memmap DMA32 zone: 496651 pages, LIFO batch:31 Detected use of extended apic ids on hypertransport bus ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information SMP: Allowing 2 CPUs, 0 hotplug CPUs nr_irqs_gsi: 40 Allocating PCI resources starting at 7bf0 (gap: 7bf0:82d0) setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 PERCPU: Embedded 25 pages/cpu @88007bc0 s70592 r8192 d23616 u1048576 pcpu-alloc: s70592 r8192 d23616 u1048576 alloc=1*2097152 pcpu-alloc: [0] 0 1 Built 1 zonelists in Zone order, mobility grouping on.
[Bug 43993] 3d game in vmware workstation cause X hang up (ati Gallium r600)
https://bugs.freedesktop.org/show_bug.cgi?id=43993 lschin...@gmail.com changed: What|Removed |Added Attachment #54616|0 |1 is obsolete|| --- Comment #2 from lschin...@gmail.com 2011-12-22 16:17:51 PST --- Created attachment 54733 --> https://bugs.freedesktop.org/attachment.cgi?id=54733 updated 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 43993] 3d game in vmware workstation cause X hang up (ati Gallium r600)
https://bugs.freedesktop.org/show_bug.cgi?id=43993 --- Comment #3 from lschin...@gmail.com 2011-12-22 16:19:24 PST --- Created attachment 54734 --> https://bugs.freedesktop.org/attachment.cgi?id=54734 backtrace -- 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 43993] 3d game in vmware workstation cause X hang up (ati Gallium r600)
https://bugs.freedesktop.org/show_bug.cgi?id=43993 --- Comment #4 from lschin...@gmail.com 2011-12-22 16:21:35 PST --- (In reply to comment #1) > > I install ppa:oibaf/graphics-drivers on Ubuntu Oneiric x64 > > Does the problem also occur without the PPA? > > Ubuntu Oneiric x64 do not come with s3tc, and the game do not run. in my point of view, its mesa is "outdated" > > When i run a old 3d game in vmware workstation 8.0.1, X hang up and i am > > forced > > to hard-reboot. > > I suspect the hang may be due to Workstation failing to release an X server > grab. > > > > 2011-12-21T08:16:58+08:00[+36.736]| mks| W110: VMGL Panic: *** Caught > > signal 11 > > in glXMakeContextCurrent() *** > > 2011-12-21T08:16:58+08:00[+36.736]| mks| W110: VMGL Panic: Fault occurred at > > 7FBBFAF7122B ((null) + -84471253, in > > /usr/lib/x86_64-linux-gnu/dri/r600_dri.so) > > In order to get more information about this crash, can you try: > > * Power on the VM. > * Log in remotely via ssh, and attach gdb to the VM's vmware-vmx process. You > may > need to enter 'handle SIGPIPE nostop noprint' at the gdb prompt to prevent > gdb > from constantly interrupting the VM from executing. > * Enter 'continue' at the gdb prompt, and start the game in the VM. > * After the crash, enter 'bt full' at the gdb prompt, and attach the resulting > output. > > Make sure debugging symbols are available for > /usr/lib/x86_64-linux-gnu/dri/r600_dri.so, e.g. by installing the > libgl1-mesa-dri-dbg package. sorry, that i accidentially update my ubuntu lsat night and the glxinfo is updated. backtrace is dumped and 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: TTM and AGP conflicts
> > Hi! > > > > I updated the openchrome tree and while testing on the AGP system > > discovered some interesting problems with the new TTM changes. The > > problems center around the ttm_tt_[un]populate which I modeled after the > > radeon and nouveau driver. > > First problem I noticed was on a AGP system that my ttm_tt_populate > > function would oops. Tracking it down I found the problem was the > > ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once my > > ttm_tt_populate function would attempt to touch the dma_address it would > > oops. The second issue is the assumption of the cast for struct ttm_tt in > > both the populate and unpopulate function. For the AGP case the proper > > case would be to ttm_agp_backend. > > At this point my assumption is the ttm_bo_move function has to be > > rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all > > cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau > > drivers I don't see that testing happening. Am I just missing something? > > Happens on AGP radeons as well: > https://bugs.freedesktop.org/show_bug.cgi?id=43719 So I'm not crazy, so this needs to be fixed. Here is what my understanding of the TTM layer is. My impression is that struct ttm_bo_driver handles multiple domains, AGP, pcie etc and in each method you have to handle each specific domain you support. Also *move gives the impression of moving between these different domains. Where as for struct ttm_backend_func was more for allocating from a specific domain. Also I never saw a clear way to handle multiple backends. For example my AGP systems can also do pci dma as well. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism
On Wed, Dec 21, 2011 at 3:56 AM, Rob Clark wrote: > On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie wrote: >>> >>> I think this is a really good v1 version of dma_buf. It contains all the >>> required bits (with well-specified semantics in the doc patch) to >>> implement some basic use-cases and start fleshing out the integration with >>> various subsystem (like drm and v4l). All the things still under >>> discussion like >>> - userspace mmap support >>> - more advanced (and more strictly specified) coherency models >>> - and shared infrastructure for implementing exporters >>> are imo much clearer once we have a few example drivers at hand and a >>> better understanding of some of the insane corner cases we need to be able >>> to handle. >>> >>> And I think any risk that the resulting clarifications will break a basic >>> use-case is really minimal, so I think it'd be great if this could go into >>> 3.3 (maybe as some kind of staging/experimental infrastructure). >>> >>> Hence for both patches: >>> Reviewed-by: Daniel Vetter >> >> Yeah I'm with Daniel, I like this one, I can definitely build the drm >> buffer sharing layer on top of this. >> >> How do we see this getting merged? I'm quite happy to push it to Linus >> if we don't have an identified path, though it could go via a Linaro >> tree as well. >> >> so feel free to add: >> Reviewed-by: Dave Airlie > > fwiw, patches to share buffers between drm and v4l2 are here: > > https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf > > (need a bit of cleanup before the vb2 patches are submitted.. but that > is unrelated to the dmabuf patches) > > so, > > Reviewed-and-Tested-by: Rob Clark Thanks Daniel, Dave, and Rob! BR, Sumit. > >> Dave. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
please add datasheet URL to dri.freedesktop.org/wiki/SMedia
Hi all, Sean from OpenMoko recently released the SMedia Glamo datasheets[1]. Could someone with permission add them to the wiki page[2]? My account (PaulWise) does not appear to be able to edit the page. 1. http://people.openmoko.org/sean/datasheets/glamo3362/ 2. http://dri.freedesktop.org/wiki/SMedia -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
GPU hung with Linux-3.2-rc6
On Wed, 21 Dec 2011 14:55:07 -0800 Keith Packard (KP) wrote: KP> On Wed, 21 Dec 2011 22:26:26 +0100, Udo Steinberg wrote: KP> KP> > That makes the problem go away. If you need more help tracking down the KP> > problem, then let me know. I can reproduce it fairly easily with something KP> > as simple as: KP> > KP> > while true; do dmesg; done KP> KP> Are you using SNA? I don't think so. I'm using the following packages: xorg-server-1.9.5 xf86-video-intel-2.15.0 libdrm-2.4.25 mesa-7.10.2 I quick google search suggests that at least some of them are too old to support SNA. Cheers, - Udo -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111222/8297fe03/attachment-0001.pgp>
GPU hung with Linux-3.2-rc6
On Thu, Dec 22, 2011 at 01:45:20AM +0100, Udo Steinberg wrote: > On Wed, 21 Dec 2011 14:55:07 -0800 Keith Packard (KP) wrote: > > KP> On Wed, 21 Dec 2011 22:26:26 +0100, Udo Steinberg > wrote: > KP> > KP> > That makes the problem go away. If you need more help tracking down the > KP> > problem, then let me know. I can reproduce it fairly easily with > something > KP> > as simple as: > KP> > > KP> > while true; do dmesg; done > KP> > KP> Are you using SNA? > > I don't think so. I'm using the following packages: > > xorg-server-1.9.5 > xf86-video-intel-2.15.0 > libdrm-2.4.25 > mesa-7.10.2 > > I quick google search suggests that at least some of them are too old to > support SNA. Can you please apply the patch available at http://cgit.freedesktop.org/~danvet/drm/patch/?id=0b3ecfa8c9b00f50d514fbcc12e34882b0fa695a This one will let your gpu keep hanging in the "stuck on semphore wait" condition. Later on the hangcheck should kick in and grab a gpu error state (in the file i915_error_state in debugfs). Can you please attach that one? Thanks, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
GPU hung with Linux-3.2-rc6
On Thu, 22 Dec 2011 01:45:20 +0100, Udo Steinberg wrote: > I quick google search suggests that at least some of them are too old to > support SNA. Sounds good. If you can capture the error as Daniel suggests, that would be great. In any case, I'll post a revert of the semaphore enable patch as it looks like that's still not working right... -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111222/93e09e6e/attachment.pgp>
[PULL] remove drm_sman and some i815 fixes
Hi Dave, I've failed to correctly fix the via hang in the reclaim buffers rework till now, so I'm only submitting the drm_sman removal of my drm cruft removal series. While beating on this stuff with my i815 I've discovered a preexisting use-after free issue in lastclose (which is new compared to what I've submitted to dri-devel) and a reclaim buffers locking problem. Also added these two patches. Please pull for 3.3. Thanks, Daniel -- The following changes since commit 4cf73129cbe001b41be2f8b56f763fbf3acaa4ce: Merge remote-tracking branch 'pfdo/drm-fixes' into drm-core-next (2011-12-21 09:50:56 +) are available in the git repository at: git://people.freedesktop.org/~danvet/drm for-airlied Daniel Vetter (12): drm/sis: track obj->drm_fd relations in the driver drm/via: track obj->drm_fd relations in the driver drm/sman: kill owner tracking interface functions drm/sman: rip out owner tracking drm/via: track user->memblock mapping with idr drm/sis: track user->memblock mapping with idr drm/sman: kill user_hash_tab drm/via: use drm_mm instead of drm_sman drm/sis: use drm_mm instead of drm_sman drm: kill drm_sman drm/i810: cleanup reclaim_buffers drm/i810: don't acces hw regs in lastclose drivers/gpu/drm/Makefile|2 +- drivers/gpu/drm/drm_sman.c | 351 --- drivers/gpu/drm/i810/i810_dma.c | 19 ++- drivers/gpu/drm/i810/i810_drv.c |1 - drivers/gpu/drm/i810/i810_drv.h |6 +- drivers/gpu/drm/sis/sis_drv.c | 33 - drivers/gpu/drm/sis/sis_drv.h |7 +- drivers/gpu/drm/sis/sis_mm.c| 196 +-- drivers/gpu/drm/via/via_drv.c | 25 +++ drivers/gpu/drm/via/via_drv.h |7 +- drivers/gpu/drm/via/via_map.c | 10 +- drivers/gpu/drm/via/via_mm.c| 132 ++- include/drm/drm_sman.h | 176 include/drm/sis_drm.h |4 + include/drm/via_drm.h |4 + 15 files changed, 289 insertions(+), 684 deletions(-) delete mode 100644 drivers/gpu/drm/drm_sman.c delete mode 100644 include/drm/drm_sman.h -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()
https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #8 from Johannes Obermayr 2011-12-22 12:35:52 PST --- Created attachment 54712 --> https://bugs.freedesktop.org/attachment.cgi?id=54712 'grep radeon_update_wrapper' from debug build OpenGL version string: 1.3 Mesa 7.12-devel (9f8573b) I hope this is enough. I can also provide the full log (~3.2 MiB uncompressed). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/i915: kill i915_mem.c
Some decent history digging indicates that this was to be used for the
GLX_MESA_allocate_memory extension but never actually implemented for
any released i915 userspace code.
So just rip it out.
Cc: Dave Airlie
Cc: Keith Whitwell
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c |2 +
drivers/gpu/drm/i915/i915_dma.c | 13 +-
drivers/gpu/drm/i915/i915_drv.h | 13 --
drivers/gpu/drm/i915/i915_mem.c | 387 ---
4 files changed, 6 insertions(+), 409 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/i915_mem.c
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 904d7e9..6bfc5ce 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -37,6 +37,7 @@
#include "drm_core.h"
#include "linux/pci.h"
+#include "linux/export.h"
/**
* Get the bus id.
@@ -353,3 +354,4 @@ int drm_noop(struct drm_device *dev, void *data,
DRM_DEBUG("\n");
return 0;
}
+EXPORT_SYMBOL(drm_noop);
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a9ae374..71a1946 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2243,9 +2243,6 @@ void i915_driver_lastclose(struct drm_device * dev)
i915_gem_lastclose(dev);
- if (dev_priv->agp_heap)
- i915_mem_takedown(&(dev_priv->agp_heap));
-
i915_dma_cleanup(dev);
}
@@ -2253,8 +2250,6 @@ void i915_driver_preclose(struct drm_device * dev, struct
drm_file *file_priv)
{
drm_i915_private_t *dev_priv = dev->dev_private;
i915_gem_release(dev, file_priv);
- if (!drm_core_check_feature(dev, DRIVER_MODESET))
- i915_mem_release(dev, file_priv, dev_priv->agp_heap);
}
void i915_driver_postclose(struct drm_device *dev, struct drm_file *file)
@@ -2273,11 +2268,11 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF_DRV(I915_ALLOC, i915_mem_alloc, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_FREE, i915_mem_free, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, i915_mem_init_heap,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_CMDBUFFER, i915_cmdbuffer, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP, i915_mem_destroy_heap,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_SET_VBLANK_PIPE, i915_vblank_pipe_set,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GET_VBLANK_PIPE, i915_vblank_pipe_get,
DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_VBLANK_SWAP, i915_vblank_swap, DRM_AUTH),
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 554bef7..0dceb4a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -327,7 +327,6 @@ typedef struct drm_i915_private {
int tex_lru_log_granularity;
int allow_batchbuffer;
- struct mem_block *agp_heap;
unsigned int sr01, adpa, ppcr, dvob, dvoc, lvds;
int vblank_pipe;
int num_pipe;
@@ -1070,18 +1069,6 @@ extern void i915_destroy_error_state(struct drm_device
*dev);
#endif
-/* i915_mem.c */
-extern int i915_mem_alloc(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-extern int i915_mem_free(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
-extern int i915_mem_init_heap(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-extern int i915_mem_destroy_heap(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
-extern void i915_mem_takedown(struct mem_block **heap);
-extern void i915_mem_release(struct drm_device * dev,
-struct drm_file *file_priv, struct mem_block
*heap);
/* i915_gem.c */
int i915_gem_init_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/i915/i915_mem.c b/drivers/gpu/drm/i915/i915_mem.c
deleted file mode 100644
index cc8f6d4..000
--- a/drivers/gpu/drm/i915/i915_mem.c
+++ /dev/null
@@ -1,387 +0,0 @@
-/* i915_mem.c -- Simple agp/fb memory manager for i915 -*- linux-c -*-
- */
-/*
- * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Sof
[PULL] remove drm_sman and some i815 fixes
> Hi Dave, > > I've failed to correctly fix the via hang in the reclaim buffers rework > till now, so I'm only submitting the drm_sman removal of my drm cruft > removal series. Last attempt at your branch still had problem. Start I didn't have time track down the exact issue. I'm cloning the below branch and will test it. Thanks for cleanup. > While beating on this stuff with my i815 I've discovered a preexisting > use-after free issue in lastclose (which is new compared to what I've > submitted to dri-devel) and a reclaim buffers locking problem. Also added > these two patches. > > Please pull for 3.3. > > Thanks, Daniel > > -- > The following changes since commit 4cf73129cbe001b41be2f8b56f763fbf3acaa4ce: > > Merge remote-tracking branch 'pfdo/drm-fixes' into drm-core-next > (2011-12-21 09:50:56 +) > > are available in the git repository at: > > git://people.freedesktop.org/~danvet/drm for-airlied > > Daniel Vetter (12): > drm/sis: track obj->drm_fd relations in the driver > drm/via: track obj->drm_fd relations in the driver > drm/sman: kill owner tracking interface functions > drm/sman: rip out owner tracking > drm/via: track user->memblock mapping with idr > drm/sis: track user->memblock mapping with idr > drm/sman: kill user_hash_tab > drm/via: use drm_mm instead of drm_sman > drm/sis: use drm_mm instead of drm_sman > drm: kill drm_sman > drm/i810: cleanup reclaim_buffers > drm/i810: don't acces hw regs in lastclose > > drivers/gpu/drm/Makefile|2 +- > drivers/gpu/drm/drm_sman.c | 351 > --- > drivers/gpu/drm/i810/i810_dma.c | 19 ++- > drivers/gpu/drm/i810/i810_drv.c |1 - > drivers/gpu/drm/i810/i810_drv.h |6 +- > drivers/gpu/drm/sis/sis_drv.c | 33 - > drivers/gpu/drm/sis/sis_drv.h |7 +- > drivers/gpu/drm/sis/sis_mm.c| 196 +-- > drivers/gpu/drm/via/via_drv.c | 25 +++ > drivers/gpu/drm/via/via_drv.h |7 +- > drivers/gpu/drm/via/via_map.c | 10 +- > drivers/gpu/drm/via/via_mm.c| 132 ++- > include/drm/drm_sman.h | 176 > include/drm/sis_drm.h |4 + > include/drm/via_drm.h |4 + > 15 files changed, 289 insertions(+), 684 deletions(-) > delete mode 100644 drivers/gpu/drm/drm_sman.c > delete mode 100644 include/drm/drm_sman.h > -- > Daniel Vetter > Mail: daniel at ffwll.ch > Mobile: +41 (0)79 365 57 48 > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
TTM and AGP conflicts
Hi! I updated the openchrome tree and while testing on the AGP system discovered some interesting problems with the new TTM changes. The problems center around the ttm_tt_[un]populate which I modeled after the radeon and nouveau driver. First problem I noticed was on a AGP system that my ttm_tt_populate function would oops. Tracking it down I found the problem was the ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once my ttm_tt_populate function would attempt to touch the dma_address it would oops. The second issue is the assumption of the cast for struct ttm_tt in both the populate and unpopulate function. For the AGP case the proper case would be to ttm_agp_backend. At this point my assumption is the ttm_bo_move function has to be rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau drivers I don't see that testing happening. Am I just missing something?
TTM and AGP conflicts
On Thu, Dec 22, 2011 at 4:56 PM, James Simmons wrote: > > Hi! > > ? ? ? ?I updated the openchrome tree and while testing on the AGP system > discovered some interesting problems with the new TTM changes. The > problems center around the ttm_tt_[un]populate which I modeled after the > radeon and nouveau driver. > ? ? ? ?First problem I noticed was on a AGP system that my ttm_tt_populate > function would oops. Tracking it down I found the problem was the > ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once my > ttm_tt_populate function would attempt to touch the dma_address it would > oops. The second issue is the assumption of the cast for struct ttm_tt in > both the populate and unpopulate function. For the AGP case the proper > case would be to ttm_agp_backend. > ? ? ? ?At this point my assumption is the ttm_bo_move function has to be > rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all > cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau > drivers I don't see that testing happening. Am I just missing something? Happens on AGP radeons as well: https://bugs.freedesktop.org/show_bug.cgi?id=43719 Alex > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] remove drm_sman and some i815 fixes
On Thu, Dec 22, 2011 at 09:48:35PM +, James Simmons wrote: > > > Hi Dave, > > > > I've failed to correctly fix the via hang in the reclaim buffers rework > > till now, so I'm only submitting the drm_sman removal of my drm cruft > > removal series. > > Last attempt at your branch still had problem. Start I didn't have time > track down the exact issue. I'm cloning the below branch and will test it. > Thanks for cleanup. Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've reported and noticed that the X server fails to start up (and that the kernel hangs). Is that the same you're seeing? -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PULL] remove drm_sman and some i815 fixes
> > > Hi Dave, > > > > > > I've failed to correctly fix the via hang in the reclaim buffers rework > > > till now, so I'm only submitting the drm_sman removal of my drm cruft > > > removal series. > > > > Last attempt at your branch still had problem. Start I didn't have time > > track down the exact issue. I'm cloning the below branch and will test it. > > Thanks for cleanup. > > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've > reported and noticed that the X server fails to start up (and that the > kernel hangs). Is that the same you're seeing? What was just merged to drm-next works fine. Its the reclaim buffer patches that cause the problem. In my case the X server starts but I get a blank screen. I have full debug on so this is what happens. Initializing cgroup subsys cpu Linux version 3.2.0-rc6-openchrome+ (jsimmons at debian) (gcc version 4.6.2 (Debian 4.6.2-7) ) #41 SMP Thu Dec 22 17:37:42 EST 2011 Command line: BOOT_IMAGE=/boot/vmlinuz-test root=UUID=2539cb3b-47b9-47fc-81c1-97dabc51b2b2 ro drm.debug=255 BIOS-provided physical RAM map: BIOS-e820: - 0009f400 (usable) BIOS-e820: 0009f400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7bef (usable) BIOS-e820: 7bef - 7bef3000 (ACPI NVS) BIOS-e820: 7bef3000 - 7bf0 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) NX (Execute Disable) protection: active DMI 2.3 present. DMI: MICRO-STAR INTERNATIONAL CO., LTD MS-7312/MS-7312, BIOS V1.2 01/25/2007 e820 update range: - 0001 (usable) ==> (reserved) e820 remove range: 000a - 0010 (usable) AGP bridge at 00:00:00 Aperture from AGP @ e800 old size 32 MB Aperture from AGP @ e800 size 128 MB (APSIZE f20) last_pfn = 0x7bef0 max_arch_pfn = 0x4 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-B uncachable C-C7FFF write-protect C8000-CBFFF uncachable CC000-D3FFF write-back D4000-F uncachable MTRR variable ranges enabled: 0 base 00 mask FFC000 write-back 1 base 004000 mask FFE000 write-back 2 base 006000 mask FFF000 write-back 3 base 007000 mask FFF800 write-back 4 base 007800 mask FFFC00 write-back 5 base 007BF0 mask F0 uncachable 6 base 00E800 mask FFF800 write-combining 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 initial memory mapped : 0 - 2000 Base memory trampoline at [8809d000] 9d000 size 8192 init_memory_mapping: -7bef 00 - 007be0 page 2M 007be0 - 007bef page 4k kernel direct mapping tables up to 7bef @ 1fffc000-2000 RAMDISK: 37aba000 - 37d55000 ACPI: RSDP 000f78c0 00014 (v00 VIAK8M) ACPI: RSDT 7bef3040 0002C (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: FACP 7bef30c0 00074 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: DSDT 7bef3180 05396 (v01 VIAK8M AWRDACPI 1000 MSFT 010E) ACPI: FACS 7bef 00040 ACPI: APIC 7bef8580 00068 (v01 VIAK8M AWRDACPI 42302E31 AWRD ) ACPI: Local APIC address 0xfee0 [ea00-ea0001bf] PMD -> [88007960-88007b1f] on node 0 Zone PFN ranges: DMA 0x0010 -> 0x1000 DMA320x1000 -> 0x0010 Normal empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x0010 -> 0x009f 0: 0x0100 -> 0x0007bef0 On node 0 totalpages: 507519 DMA zone: 56 pages used for memmap DMA zone: 2 pages reserved DMA zone: 3925 pages, LIFO batch:0 DMA32 zone: 6885 pages used for memmap DMA32 zone: 496651 pages, LIFO batch:31 Detected use of extended apic ids on hypertransport bus ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information SMP: Allowing 2 CPUs, 0 hotplug CPUs nr_irqs_gsi: 40 Allocating PCI resources starting at 7bf0 (gap: 7bf0:82d0) setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 PERCPU: Embedded 25 pages/cpu @88007bc0 s70592 r8192 d23616 u1048576 pcpu-alloc: s70592 r8192 d23616 u1048576 alloc=1*2097152 pcpu-alloc: [0] 0 1 Built 1 zonelists in Zone order, mobility grouping
