dri-devel September 2010

dri-devel@lists.freedesktop.org

71 participants
367 discussions

video= semantics changed?
by Marius Gröger 14 Sep '10

14 Sep '10

I sent this message during the weekend and I'm afraid it might got lost during people's monday morning inbox purging ;-) Seriously, I'd be grateful for any insights on that matter which keeps me from moving on to 2.6.36... Thanks Marius -------- Original Message -------- Date: Sat, 11 Sep 2010 13:20:22 +0200 With the latest d-r-t my grub cmdline option video=1280x720@50 no longer works (RS780, output to LCD TV via HDMI). The fbcon apparently is enabled, but the TV doen't get a displayable picture anymore. Booting with d-r-t from 4 weeks ago works and correctly uses the EDID reported 1280x720@50 mode. Does anyone know what might have happened to the video= code? I also tried video=1280x720R@50, but that didn't work either. X works fine though. Thanks Marius

1 0

[Bug 30179] New: Video playback fails with Xvmc
by bugzilla-daemon＠freedesktop.org 14 Sep '10

14 Sep '10

https://bugs.freedesktop.org/show_bug.cgi?id=30179 Summary: Video playback fails with Xvmc Product: Mesa Version: unspecified Platform: x86-64 (AMD64) OS/Version: other Status: NEW Severity: major Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: hysvats(a)gmail.com KMS Driver Stack details : ========================= 1) Kernel-2.6.32-21-generic-pae 2) Libdrm-2.4.19 3) Mesa-7.8 4) Xorg-server-1.7.4 5) ddx: xf86-video-ati-6.13.0 System Environment : =================== O.S. - Ubuntu-10.04(32 bit) Asic - M97 Mobility RadeonHD 4830 CPU - AMD Athlon(tm) 64 FX-60 Dual Core Processor(a)2.60 GHz Steps to Reproduce: =================== 1) Install Phoronix-test-suite from http://www.phoronix-test-suite.com/releases/repo/pts.debian/files/phoronix-… 2) Install video-extensions phoronix-test-suite install video-extensions 3) phoronix-test-suite run video-extensions Observation : ============= The result is xvmc Playback failed -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[PATCH] drm/radeon/kms: only warn on mipmap size checks in r600 cs checker
by Alex Deucher 14 Sep '10

14 Sep '10

The texture base address registers are in units of 256 bytes. The original CS checker treated these offsets as bytes, so the original check was wrong. I fixed the units in a patch during the 2.6.36 cycle, but this ended up breaking some existing userspace (probably due to a bug in either userspace texture allocation or the drm texture mipmap checker). So for now, until we come up with a better fix, just warn if the mipmap size it too large. This will keep existing userspace working and it should be just as safe as before when we were checking the wrong units. These are GPU MC addresses, so if they fall outside of the VRAM or GART apertures, they end up at the GPU default page, so this should be safe from a security perspective. Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> Cc: Jerome Glisse <glisse(a)freedesktop.org> --- drivers/gpu/drm/radeon/r600_cs.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c index d886494..27023a3 100644 --- a/drivers/gpu/drm/radeon/r600_cs.c +++ b/drivers/gpu/drm/radeon/r600_cs.c @@ -1172,7 +1172,6 @@ static inline int r600_check_texture_resource(struct radeon_cs_parser *p, u32 i if ((mipmap_size + word0) > radeon_bo_size(mipmap)) { dev_warn(p->dev, "mipmap bo too small (%d %d %d %d %d %d -> %d have %ld)\n", w0, h0, bpe, blevel, nlevels, word0, mipmap_size, radeon_bo_size(texture)); - return -EINVAL; } return 0; } -- 1.7.1.1

3 3

[Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34
by bugzilla-daemon＠freedesktop.org 14 Sep '10

14 Sep '10

https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #68 from Martin Steigerwald <Martin(a)Lichtvoll.de> 2010-09-14 06:17:18 PDT --- I have two questions: 1) Now since we established that the vmembase at zero patch fixes or works around the problem - while the patch to align vram from comment #47 does not, and now that I bisected the range of commits down to about 10 and as far as I understand Da Fox and Lukas even bisected down to exact one commit: What next? Is the vmembase at zero patch the proper fix? Actually to me it seems more like a work-around. Is there another fix you propose? I would love to see a fix in time for 2.6.36, although I still have to figure out on how to get a kernel after 2.6.33 that does either userspace software suspend or TuxOnIce stably on my ThinkPad T42 (see bug #18162 regarding userspace software suspend and tuxonice-devel mailing list for TuxOnIce related stuff). 2) Re Comment #65: "The AGPMode xorg option isn't used with kms (the AGP mode is set before X starts when the drm loads). To force a particular AGP mode with kms, use the agpmode module parameter: radeon.agpmode=x where x=-1,1,2,4,8. -1 disables AGP and uses the on-chip gart mechanism instead." Is it necessary? How do I find out with AGP mode is used. I'd prefer when it used best AGP mode (that should be 4x on my ThinkPad T42) automatically. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[PATCH] drm: fix another race due to BKL removal.
by Dave Airlie 14 Sep '10

14 Sep '10

From: Dave Airlie <airlied(a)redhat.com> Since module loading was happening under the BKL, and the drm open path took the BKL you couldn't race between them. The drm adds the sysfs node before it really probably should, i.e. before driver load has completed. Then udev creates the device node, and plymouth opens the device before we've completed loading the driver. This results in fail. Fix this now by taking the global mutex around the driver loading procedure, which seems like the lesser of two evils patch to fix the regression. Reported-by: Toni Spets (hifi on #radeon) Cc: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- drivers/gpu/drm/drm_pci.c | 4 ++++ drivers/gpu/drm/drm_platform.c | 5 +++++ 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c index e20f78b..f5bd9e5 100644 --- a/drivers/gpu/drm/drm_pci.c +++ b/drivers/gpu/drm/drm_pci.c @@ -164,6 +164,8 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct pci_device_id *ent, dev->hose = pdev->sysdata; #endif + mutex_lock(&drm_global_mutex); + if ((ret = drm_fill_in_dev(dev, ent, driver))) { printk(KERN_ERR "DRM: Fill_in_dev failed.\n"); goto err_g2; @@ -199,6 +201,7 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct pci_device_id *ent, driver->name, driver->major, driver->minor, driver->patchlevel, driver->date, pci_name(pdev), dev->primary->index); + mutex_unlock(&drm_global_mutex); return 0; err_g4: @@ -210,6 +213,7 @@ err_g2: pci_disable_device(pdev); err_g1: kfree(dev); + mutex_unlock(&drm_global_mutex); return ret; } EXPORT_SYMBOL(drm_get_pci_dev); diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c index 460e9a3..92d1d0f 100644 --- a/drivers/gpu/drm/drm_platform.c +++ b/drivers/gpu/drm/drm_platform.c @@ -53,6 +53,8 @@ int drm_get_platform_dev(struct platform_device *platdev, dev->platformdev = platdev; dev->dev = &platdev->dev; + mutex_lock(&drm_global_mutex); + ret = drm_fill_in_dev(dev, NULL, driver); if (ret) { @@ -87,6 +89,8 @@ int drm_get_platform_dev(struct platform_device *platdev, list_add_tail(&dev->driver_item, &driver->device_list); + mutex_unlock(&drm_global_mutex); + DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n", driver->name, driver->major, driver->minor, driver->patchlevel, driver->date, dev->primary->index); @@ -100,6 +104,7 @@ err_g2: drm_put_minor(&dev->control); err_g1: kfree(dev); + mutex_unlock(&drm_global_mutex); return ret; } EXPORT_SYMBOL(drm_get_platform_dev); -- 1.7.2.2

2 1

[drm-fixes] drm/vmwgfx: error: too few arguments to function ‘vmw_ldu_connector_detect’ in vmw_ldu_connector_detect()
by Sedat Dilek 14 Sep '10

14 Sep '10

Hi, I pulled drm-fixes GIT branch into mainline. Unfortunately, the build breaks: ... ... CC [M] drivers/gpu/drm/vmwgfx/vmwgfx_ldu.o /home/sd/src/linux-2.6/linux-2.6.36-rc4/debian/build/source_i386_none/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c: In function ‘vmw_ldu_init’: /home/sd/src/linux-2.6/linux-2.6.36-rc4/debian/build/source_i386_none/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:520: error: too few arguments to function ‘vmw_ldu_connector_detect’ /home/sd/src/linux-2.6/linux-2.6.36-rc4/debian/build/source_i386_none/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c: In function ‘vmw_kms_ldu_update_layout’: /home/sd/src/linux-2.6/linux-2.6.36-rc4/debian/build/source_i386_none/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:614: error: too few arguments to function ‘vmw_ldu_connector_detect’ make[4]: *** [drivers/gpu/drm/vmwgfx/vmwgfx_ldu.o] Error 1 make[3]: *** [drivers/gpu/drm/vmwgfx] Error 2 make[2]: *** [_module_drivers/gpu/drm] Error 2 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 As far as I can see the cause aroses from: commit 7b334fcb45b757ffb093696ca3de1b0c8b4a33f1 "drm: Use a nondestructive mode for output detect when polling" Looks like vmw_ldu_connector_detect(connector); needs to be enhanced with "bool nondestructive". Kind Regards, - Sedat -

2 1

[PATCH next 00/16] treewide: Use static const char * const where possible
by Joe Perches 14 Sep '10

14 Sep '10

Convert the uses that should be const of char *foo[] = {"bar", "baz"}; to const char * const foo[] = {"bar", "baz"}; or static const char * const foo[] = {"bar", "baz"}; Joe Perches (16): arch/alpha: Use static const char * const where possible arch/ia64: Use static const char * const where possible arch/microblaze: Use static const char * const where possible arch/x86: Use static const char * const where possible drivers/gpu: Use static const char * const where possible drivers/isdn: Use static const char * const where possible drivers/net: Use static const char * const where possible drivers/net/pcmcia: Use static const char * const where possible drivers/net/wireless: Use static const char * const where possible drivers/scsi: Use static const char * const where possible drivers/staging: Use static const char * const where possible drivers/usb: Use static const char * const where possible drivers/watchdog: Use static const char * const where possible fs: Use static const char * const where possible net/irda: Use static const char * const where possible sound: Use static const char * const where possible arch/alpha/kernel/err_ev6.c | 12 +++++--- arch/alpha/kernel/err_marvel.c | 33 ++++++++++++------------ arch/alpha/kernel/err_titan.c | 35 ++++++++++++++----------- arch/alpha/kernel/osf_sys.c | 4 +- arch/ia64/kernel/palinfo.c | 2 +- arch/microblaze/kernel/heartbeat.c | 10 +++--- arch/microblaze/kernel/timer.c | 12 ++++---- arch/x86/kernel/smpboot.c | 2 +- arch/x86/kvm/mmu.c | 2 +- drivers/gpu/drm/ttm/ttm_page_alloc.c | 4 ++- drivers/isdn/pcbit/edss1.c | 2 +- drivers/isdn/pcbit/edss1.h | 2 +- drivers/net/3c515.c | 4 ++- drivers/net/eth16i.c | 4 ++- drivers/net/pcmcia/3c589_cs.c | 2 +- drivers/net/wireless/rt2x00/rt2x00debug.c | 2 +- drivers/scsi/bfa/rport.c | 4 ++- drivers/scsi/pcmcia/nsp_debug.c | 2 +- drivers/scsi/qla2xxx/qla_nx.c | 4 +- drivers/scsi/qla4xxx/ql4_nx.c | 2 +- drivers/staging/ath6kl/os/linux/ar6000_drv.c | 14 +++++----- drivers/staging/bcm/Debug.c | 5 ++- drivers/usb/host/oxu210hp-hcd.c | 2 +- drivers/watchdog/machzwd.c | 2 +- fs/binfmt_flat.c | 4 ++- include/net/irda/irlan_event.h | 2 +- net/irda/irlan/irlan_event.c | 2 +- sound/core/misc.c | 5 +--- sound/core/pcm_native.c | 2 +- 29 files changed, 99 insertions(+), 83 deletions(-) -- 1.7.3.rc1

1 1

[Bug 30145] New: [r300g] Warcraft's login screen is now flickering mess (bisected)
by bugzilla-daemon＠freedesktop.org 13 Sep '10

13 Sep '10

https://bugs.freedesktop.org/show_bug.cgi?id=30145 Summary: [r300g] Warcraft's login screen is now flickering mess (bisected) Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: rankincj(a)googlemail.com Created an attachment (id=38644) --> (https://bugs.freedesktop.org/attachment.cgi?id=38644) WoW login screen, with artifacts The input fields and menu items on Warcraft's login screen are now being misrendered; things are appearing and disappearing, apparently at random. Git bisect points the finger here: b5fcf0c8e07e666523b007fab1d0fc18c2c89241 is the first bad commit commit b5fcf0c8e07e666523b007fab1d0fc18c2c89241 Author: Dave Airlie <airlied(a)redhat.com> Date: Sat Aug 28 18:59:32 2010 +1000 pb: add void * for flush ctx to mapping functions If the buffer we are attempting to map is referenced by the unsubmitted command stream for this context, we need to flush the command stream, however to do that we need to be able to access the context at the lowest level map function, currently we set the buffer in the toplevel map, but this racy between context. (we probably have a lot more issues than that.) I'll look into a proper solution as suggested by jrfonseca when I get some time. :040000 040000 92125dde35466f2db79e9d074127928621b5cad6 ec868c65f2cec90b5ce76a4fc3a2deee6d6a49c9 M src -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 6

[Bug 28671] New: Seg. fault and Oops with Radeon KMS (v2.6.34) on PPC ATI Radeon AGP r420 JH.
by bugzilla-daemon＠freedesktop.org 13 Sep '10

13 Sep '10

https://bugs.freedesktop.org/show_bug.cgi?id=28671 Summary: Seg. fault and Oops with Radeon KMS (v2.6.34) on PPC ATI Radeon AGP r420 JH. Product: DRI Version: unspecified Platform: PowerPC OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: brett.witherspoon(a)comcast.net Created an attachment (id=36419) --> (https://bugs.freedesktop.org/attachment.cgi?id=36419) Dmesg with call trace. Mentioned on #radeon: Hello, I have recently adopted a PowerMac G5 (machine7,3 circa 2003-04) with a ATI Radeon x800 XT Mac edition (AGP chipset R420 JH). When attempting to use the new KMS Radeon drivers (kernel v. 2.4.34) I get a seg. fault and kernel Oops. I am using PPC gentoo linux with 64bit kernel and 32bit userland. I have collected the call trace that is given after inserting the module with modesetting enabled. Attached is my entire dmesg with the call trace at the bottom. Inserting the module was done via SSH with no other fb or video drivers enabled in the kernel. Let me know if I can provide any additional information that would be useful and I am happy to do any testing. Thanks, B. Witherspoon -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 36

[Bug 22576] [KMS] mesa demo spectex broken on rv280
by bugzilla-daemon＠freedesktop.org 13 Sep '10

13 Sep '10

https://bugs.freedesktop.org/show_bug.cgi?id=22576 --- Comment #13 from Andrew Randrianasulu <randrik(a)mail.ru> 2010-09-13 11:50:05 PDT --- Created an attachment (id=38679) --> (https://bugs.freedesktop.org/attachment.cgi?id=38679) RADEON_DEBUG=state ./spectex What puzzled me most - even after i reverted my patch and tried to use another (system-wise installed) version of mesa, even with different demo - same assert hit me again. But after some time at least lodbias demo working again .... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

← Newer
1
...
22
23
24
25
26
27
28
...
37
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2010