dri-devel October 2010

dri-devel@lists.freedesktop.org

76 participants
345 discussions

Re: Any SYSRQ key to force mode switch to console mode when using KMS?
by Randy Dunlap 06 Oct '10

06 Oct '10

On Thu, 23 Sep 2010 18:31:32 +0200 Uwe Bonnes wrote: [just adding cc's] > >>>>> "Randy" == Randy Dunlap <rdunlap(a)xenotime.net> writes: > > > Randy> Is CONFIG_DRM_KMS_HELPER enabled in your kernel .config file? If > Randy> not, we need to find out how to enable it (there is no kconfig > Randy> prompt for it). > > Yes, it is enabled > > Randy> Can you check if Alt-Sysrq-H (help) lists V for "force-fb(V)"? > Yes, it is listed. > > And yes, my last experiments where with ALT-CTL-sysreq, so doomed for non > function due to operator error. > > However: > When running X, X.Org X Server 1.9.0 on Thinkpad R50 RV250, Alt-Sysrq-v > switches to an all-black display. By console switching with ALT-CLT-F1 I > get back to the booting console and ALT-CLT-F7 brings me back to X. Running > on the console and calling Alt-Sysrq-v prints > SysRq : Restore framebuffer console > > Is there some omission by the distribution or my setup that Alt-Sysrq-v when > running X results in an all-black screen? > > And when I hit the hibernate problem, the screen stays black even with a > console switch after Alt-Sysrq-v > > Bye > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***

2 1

[Bug 30650] New: ut2004-demo segfault since r600g: use dirty list to track dirty blocks
by bugzilla-daemon＠freedesktop.org 06 Oct '10

06 Oct '10

https://bugs.freedesktop.org/show_bug.cgi?id=30650 Summary: ut2004-demo segfault since r600g: use dirty list to track dirty blocks Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: lists(a)andyfurniss.entadsl.com rv790, d-r-t, git ddx,mesa,libdrm and xserver 1.9 ut2004 demo segfaults for me since - commit ac8a1ebe55b08180945ffaebcff6b3bed336c9ec Author: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Date: Tue Oct 5 21:01:43 2010 +0200 r600g: use dirty list to track dirty blocks Got a speed up by tracking the dirty blocks in a seperate list instead of looping through all blocks. This version should work with block that get their dirty state disabled again and I added a dirty check during the flush as some blocks were already dirty. Log: [ 1] ./ut2004-bin [0x85a5921] Log: [ 2] [0xffffe400] Log: [ 3] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so [0xb40d31a1] Log: [ 4] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so [0xb40b20e1] Log: [ 5] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so [0xb42565cd] Log: [ 6] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so [0xb42342aa] Log: [ 7] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so [0xb4231539] Log: [ 8] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so [0xb42047be] Log: [ 9] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so [0xb4228cfe] Log: [10] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so [0xb422936a] Log: [11] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so [0xb4185585] Log: [12] ./ut2004-bin(_ZN22FOpenGLRenderInterface13DrawPrimitiveE14EPrimitiveTypeiiii+0x2dd) [0x87089cd] Log: [13] ./ut2004-bin(_Z11DrawSectionP11UStaticMeshiP9UMaterialP16FRenderInterface+0xbf) [0x834b77f] Log: [14] ./ut2004-bin(_Z16RenderStaticMeshP13FDynamicActorP15FLevelSceneNodeP5TListIP13FDynamicLightEPS3_IP20FProjectorRenderInfoEP16FRenderInterface+0x14f4) [0x834d5c4] Log: [15] ./ut2004-bin(_ZN13FDynamicActor6RenderEP15FLevelSceneNodeP5TListIP13FDynamicLightEPS2_IP20FProjectorRenderInfoEP16FRenderInterface+0x22eb) [0x83134cb] Log: [16] ./ut2004-bin [0x83378ec] Log: [17] ./ut2004-bin(_Z11RenderLevelP15FLevelSceneNodeP16FRenderInterface+0xed2) [0x8334212] Log: [18] ./ut2004-bin(_ZN15FLevelSceneNode6RenderEP16FRenderInterface+0x66c) [0x831b52c] Log: [19] ./ut2004-bin(_Z11RenderLevelP15FLevelSceneNodeP16FRenderInterface+0xc79) [0x8333fb9] Log: [20] ./ut2004-bin(_ZN15FLevelSceneNode6RenderEP16FRenderInterface+0x66c) [0x831b52c] Log: [21] ./ut2004-bin(_Z11RenderLevelP15FLevelSceneNodeP16FRenderInterface+0xc79) [0x8333fb9] Log: [22] ./ut2004-bin(_ZN15FLevelSceneNode6RenderEP16FRenderInterface+0x66c) [0x831b52c] Log: [23] ./ut2004-bin(_Z11RenderLevelP15FLevelSceneNodeP16FRenderInterface+0xc79) [0x8333fb9] Log: [24] ./ut2004-bin(_ZN15FLevelSceneNode6RenderEP16FRenderInterface+0x66c) [0x831b52c] Log: [25] ./ut2004-bin(_ZN16FPlayerSceneNode6RenderEP16FRenderInterface+0x1da) [0x831f8ba] Log: [26] ./ut2004-bin(_ZN11UGameEngine4DrawEP9UViewportiPhPi+0x6c4) [0x8240f04] Log: [27] ./ut2004-bin(_ZN12USDLViewport7RepaintEi+0x56) [0x86f8136] Log: [28] ./ut2004-bin(_ZN10USDLClient4TickEv+0x159) [0x86f6359] Log: [29] ./ut2004-bin(_ZN11UGameEngine4TickEf+0x517) [0x82459b7] Log: [30] ./ut2004-bin(_ZN9CMainLoop7RunLoopEv+0x108) [0x815a7a8] Log: [31] ./ut2004-bin [0x81521cf] Log: [32] ./ut2004-bin(main+0x2c8f) [0x814e1df] Log: [33] /lib/libc.so.6(__libc_start_main+0xd0) [0xb74f7380] Log: [34] ./ut2004-bin(readdir+0x95) [0x814b321] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[Bug 29833] radeon crashes kicad when using modeset
by bugzilla-daemon＠freedesktop.org 06 Oct '10

06 Oct '10

https://bugs.freedesktop.org/show_bug.cgi?id=29833 --- Comment #9 from Alex Deucher <agd5f(a)yahoo.com> 2010-10-06 09:15:57 PDT --- The kernel is rejecting your command stream as invalid. The command stream is the stream of register writes produced by the 3D driver based on the GL state. The bug is either in the drm command checker in the kernel or in the mesa 3D driver. The error in your dmesg is saying that the Z buffer is enabled in the command stream, but that there is no buffer associated with it. I would guess perhaps ZB_CNTL (0x4F00) is not getting emitted as part of the command stream. -- 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

[Bug 29833] radeon crashes kicad when using modeset
by bugzilla-daemon＠freedesktop.org 06 Oct '10

06 Oct '10

https://bugs.freedesktop.org/show_bug.cgi?id=29833 Fabio Pedretti <fabio.ped(a)libero.it> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fabio.ped(a)libero.it --- Comment #8 from Fabio Pedretti <fabio.ped(a)libero.it> 2010-10-06 09:11:19 PDT --- You may want to try the r300 gallium driver that should be more stable e.g. installing the mesa packages from the xorg-edgers ppa: https://edge.launchpad.net/~xorg-edgers/+archive/ppa -- 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

[Bug 29833] radeon crashes kicad when using modeset
by bugzilla-daemon＠freedesktop.org 06 Oct '10

06 Oct '10

https://bugs.freedesktop.org/show_bug.cgi?id=29833 --- Comment #7 from Fabio Varesano <fabio.varesano(a)gmail.com> 2010-10-06 08:51:18 PDT --- Guys, would you please explain me how to troubleshoot this one? I do have programming knowledge but I need guidance on how to debug this one. How can I check if this is a radeon bug or kicad bug or what else??? -- 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/radeon/kms: make sure blit addr masks are 64 bit
by Alex Deucher 06 Oct '10

06 Oct '10

Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/evergreen_blit_kms.c | 8 ++++---- drivers/gpu/drm/radeon/r600_blit_kms.c | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c b/drivers/gpu/drm/radeon/evergreen_blit_kms.c index d128aa1..086b9b0 100644 --- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c +++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c @@ -607,8 +607,8 @@ void evergreen_kms_blit_copy(struct radeon_device *rdev, int src_x = src_gpu_addr & 255; int dst_x = dst_gpu_addr & 255; int h = 1; - src_gpu_addr = src_gpu_addr & ~255; - dst_gpu_addr = dst_gpu_addr & ~255; + src_gpu_addr = src_gpu_addr & ~255ULL; + dst_gpu_addr = dst_gpu_addr & ~255ULL; if (!src_x && !dst_x) { h = (cur_size / max_bytes); @@ -691,8 +691,8 @@ void evergreen_kms_blit_copy(struct radeon_device *rdev, int src_x = (src_gpu_addr & 255); int dst_x = (dst_gpu_addr & 255); int h = 1; - src_gpu_addr = src_gpu_addr & ~255; - dst_gpu_addr = dst_gpu_addr & ~255; + src_gpu_addr = src_gpu_addr & ~255ULL; + dst_gpu_addr = dst_gpu_addr & ~255ULL; if (!src_x && !dst_x) { h = (cur_size / max_bytes); diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c b/drivers/gpu/drm/radeon/r600_blit_kms.c index 2a4747d..39d566d 100644 --- a/drivers/gpu/drm/radeon/r600_blit_kms.c +++ b/drivers/gpu/drm/radeon/r600_blit_kms.c @@ -661,8 +661,8 @@ void r600_kms_blit_copy(struct radeon_device *rdev, int src_x = src_gpu_addr & 255; int dst_x = dst_gpu_addr & 255; int h = 1; - src_gpu_addr = src_gpu_addr & ~255; - dst_gpu_addr = dst_gpu_addr & ~255; + src_gpu_addr = src_gpu_addr & ~255ULL; + dst_gpu_addr = dst_gpu_addr & ~255ULL; if (!src_x && !dst_x) { h = (cur_size / max_bytes); @@ -744,8 +744,8 @@ void r600_kms_blit_copy(struct radeon_device *rdev, int src_x = (src_gpu_addr & 255); int dst_x = (dst_gpu_addr & 255); int h = 1; - src_gpu_addr = src_gpu_addr & ~255; - dst_gpu_addr = dst_gpu_addr & ~255; + src_gpu_addr = src_gpu_addr & ~255ULL; + dst_gpu_addr = dst_gpu_addr & ~255ULL; if (!src_x && !dst_x) { h = (cur_size / max_bytes); -- 1.7.1.1

1 0

[PATCH 1/2] KMS/Radeon: Add function for display scanout position query.
by Alex Deucher 05 Oct '10

05 Oct '10

From: Mario Kleiner <mario.kleiner(a)tuebingen.mpg.de> radeon_get_crtc_scanoutpos() returns the current horizontal and vertical scanout position of a crtc. It also reports if the display scanout is currently inside the vblank area. hpos reports current horizontal pixel scanout position. vpos reports the current scanned out line as a value >= 0 in active scanout. If the scanout is inside vblank area, it reports a negative value, the number of scanlines until end of vblank aka start of active scanout, e.g., -3 == "At most 3 scanlines until end of vblank". This code is derived from radeon_pm_in_vbl(), tested on R500 and R600. Signed-off-by: Mario Kleiner <mario.kleiner(a)tuebingen.mpg.de> Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_display.c | 153 +++++++++++++++++++++++++++++++ drivers/gpu/drm/radeon/radeon_mode.h | 7 ++ 2 files changed, 160 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index b418285..a7963df 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -964,3 +964,156 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc, } return true; } + +/* + * Retrieve current video scanout position of crtc on a given gpu. + * + * \param rdev Device to query. + * \param crtc Crtc to query. + * \param *vpos Location where vertical scanout position should be stored. + * \param *hpos Location where horizontal scanout position should go. + * + * Returns vpos as a positive number while in active scanout area. + * Returns vpos as a negative number inside vblank, counting the number + * of scanlines to go until end of vblank, e.g., -1 means "one scanline + * until start of active scanout / end of vblank." + * + * \return Flags, or'ed together as follows: + * + * RADEON_SCANOUTPOS_VALID = Query successfull. + * RADEON_SCANOUTPOS_INVBL = Inside vblank. + * RADEON_SCANOUTPOS_ACCURATE = Returned position is accurate. A lack of + * this flag means that returned position may be offset by a constant but + * unknown small number of scanlines wrt. real scanout position. + * + */ +int radeon_get_crtc_scanoutpos(struct radeon_device *rdev, int crtc, int *vpos, int *hpos) +{ + u32 stat_crtc = 0, vbl = 0, position = 0; + int vbl_start, vbl_end, vtotal, ret = 0; + bool in_vbl = true; + + if (ASIC_IS_DCE4(rdev)) { + if (crtc == 0) { + vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END + + EVERGREEN_CRTC0_REGISTER_OFFSET); + position = RREG32(EVERGREEN_CRTC_STATUS_POSITION + + EVERGREEN_CRTC0_REGISTER_OFFSET); + ret |= RADEON_SCANOUTPOS_VALID; + } + if (crtc == 1) { + vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END + + EVERGREEN_CRTC1_REGISTER_OFFSET); + position = RREG32(EVERGREEN_CRTC_STATUS_POSITION + + EVERGREEN_CRTC1_REGISTER_OFFSET); + ret |= RADEON_SCANOUTPOS_VALID; + } + if (crtc == 2) { + vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END + + EVERGREEN_CRTC2_REGISTER_OFFSET); + position = RREG32(EVERGREEN_CRTC_STATUS_POSITION + + EVERGREEN_CRTC2_REGISTER_OFFSET); + ret |= RADEON_SCANOUTPOS_VALID; + } + if (crtc == 3) { + vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END + + EVERGREEN_CRTC3_REGISTER_OFFSET); + position = RREG32(EVERGREEN_CRTC_STATUS_POSITION + + EVERGREEN_CRTC3_REGISTER_OFFSET); + ret |= RADEON_SCANOUTPOS_VALID; + } + if (crtc == 4) { + vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END + + EVERGREEN_CRTC4_REGISTER_OFFSET); + position = RREG32(EVERGREEN_CRTC_STATUS_POSITION + + EVERGREEN_CRTC4_REGISTER_OFFSET); + ret |= RADEON_SCANOUTPOS_VALID; + } + if (crtc == 5) { + vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END + + EVERGREEN_CRTC5_REGISTER_OFFSET); + position = RREG32(EVERGREEN_CRTC_STATUS_POSITION + + EVERGREEN_CRTC5_REGISTER_OFFSET); + ret |= RADEON_SCANOUTPOS_VALID; + } + } else if (ASIC_IS_AVIVO(rdev)) { + if (crtc == 0) { + vbl = RREG32(AVIVO_D1CRTC_V_BLANK_START_END); + position = RREG32(AVIVO_D1CRTC_STATUS_POSITION); + ret |= RADEON_SCANOUTPOS_VALID; + } + if (crtc == 1) { + vbl = RREG32(AVIVO_D2CRTC_V_BLANK_START_END); + position = RREG32(AVIVO_D2CRTC_STATUS_POSITION); + ret |= RADEON_SCANOUTPOS_VALID; + } + } else { + /* Pre-AVIVO: Different encoding of scanout pos and vblank interval. */ + if (crtc == 0) { + /* Assume vbl_end == 0, get vbl_start from + * upper 16 bits. + */ + vbl = (RREG32(RADEON_CRTC_V_TOTAL_DISP) & + RADEON_CRTC_V_DISP) >> RADEON_CRTC_V_DISP_SHIFT; + /* Only retrieve vpos from upper 16 bits, set hpos == 0. */ + position = (RREG32(RADEON_CRTC_VLINE_CRNT_VLINE) >> 16) & RADEON_CRTC_V_TOTAL; + stat_crtc = RREG32(RADEON_CRTC_STATUS); + if (!(stat_crtc & 1)) + in_vbl = false; + + ret |= RADEON_SCANOUTPOS_VALID; + } + if (crtc == 1) { + vbl = (RREG32(RADEON_CRTC2_V_TOTAL_DISP) & + RADEON_CRTC_V_DISP) >> RADEON_CRTC_V_DISP_SHIFT; + position = (RREG32(RADEON_CRTC2_VLINE_CRNT_VLINE) >> 16) & RADEON_CRTC_V_TOTAL; + stat_crtc = RREG32(RADEON_CRTC2_STATUS); + if (!(stat_crtc & 1)) + in_vbl = false; + + ret |= RADEON_SCANOUTPOS_VALID; + } + } + + /* Decode into vertical and horizontal scanout position. */ + *vpos = position & 0x1fff; + *hpos = (position >> 16) & 0x1fff; + + /* Valid vblank area boundaries from gpu retrieved? */ + if (vbl > 0) { + /* Yes: Decode. */ + ret |= RADEON_SCANOUTPOS_ACCURATE; + vbl_start = vbl & 0x1fff; + vbl_end = (vbl >> 16) & 0x1fff; + } + else { + /* No: Fake something reasonable which gives at least ok results. */ + vbl_start = rdev->mode_info.crtcs[crtc]->base.mode.crtc_vdisplay; + vbl_end = 0; + } + + /* Test scanout position against vblank region. */ + if ((*vpos < vbl_start) && (*vpos >= vbl_end)) + in_vbl = false; + + /* Check if inside vblank area and apply corrective offsets: + * vpos will then be >=0 in video scanout area, but negative + * within vblank area, counting down the number of lines until + * start of scanout. + */ + + /* Inside "upper part" of vblank area? Apply corrective offset if so: */ + if (in_vbl && (*vpos >= vbl_start)) { + vtotal = rdev->mode_info.crtcs[crtc]->base.mode.crtc_vtotal; + *vpos = *vpos - vtotal; + } + + /* Correct for shifted end of vbl at vbl_end. */ + *vpos = *vpos - vbl_end; + + /* In vblank? */ + if (in_vbl) + ret |= RADEON_SCANOUTPOS_INVBL; + + return ret; +} diff --git a/drivers/gpu/drm/radeon/radeon_mode.h b/drivers/gpu/drm/radeon/radeon_mode.h index a13a5c7..79a57a7 100644 --- a/drivers/gpu/drm/radeon/radeon_mode.h +++ b/drivers/gpu/drm/radeon/radeon_mode.h @@ -424,6 +424,11 @@ struct radeon_framebuffer { struct drm_gem_object *obj; }; +/* radeon_get_crtc_scanoutpos() return flags */ +#define RADEON_SCANOUTPOS_VALID (1 << 0) +#define RADEON_SCANOUTPOS_INVBL (1 << 1) +#define RADEON_SCANOUTPOS_ACCURATE (1 << 2) + extern enum radeon_tv_std radeon_combios_get_tv_info(struct radeon_device *rdev); extern enum radeon_tv_std @@ -527,6 +532,8 @@ extern int radeon_crtc_cursor_set(struct drm_crtc *crtc, extern int radeon_crtc_cursor_move(struct drm_crtc *crtc, int x, int y); +extern int radeon_get_crtc_scanoutpos(struct radeon_device *rdev, int crtc, int *vpos, int *hpos); + extern bool radeon_combios_check_hardcoded_edid(struct radeon_device *rdev); extern struct edid * radeon_combios_get_hardcoded_edid(struct radeon_device *rdev); -- 1.7.1.1

1 1

[Bug 30626] New: bisected nexuiz issue since r600g: don't double count dirty block
by bugzilla-daemon＠freedesktop.org 05 Oct '10

05 Oct '10

https://bugs.freedesktop.org/show_bug.cgi?id=30626 Summary: bisected nexuiz issue since r600g: don't double count dirty block Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: lists(a)andyfurniss.entadsl.com rv790, d-r-t, git ddx, mesa,libdrm and xserver 1.9. wait vline and dri2 vsync off. Test is nexuiz 2.5.2, timedemo demos/demo1, effects normal, fullscreen 1920x1080. The nexuiz sdl client isn't affected as badly as the glx client and will run to completion the demo. It may sometimes show the libc error on exit. The glx client will bail out during the demo with either a segfault or the libc trace below. Both since the commit - commit dde1391cc95478f4dedccdf920ba0a6607472937 Author: John Doe <glisse(a)barney.(none)> Date: Thu Sep 30 17:30:25 2010 -0400 r600g: don't double count dirty block This avoid to overcount the number of dwords we need and thus avoid maximazation of cs buffer use. Will give an error in dmesg. [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16390 [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser ! The libc trace - *** glibc detected *** ./nexuiz-linux-686-glx: double free or corruption (!prev): 0x0ba5e510 *** ======= Backtrace: ========= /lib/libc.so.6[0xb73d4d9a] /lib/libc.so.6(cfree+0x6e)[0xb73d697e] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so[0xb6179950] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so[0xb61580aa] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so[0xb62a9169] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so[0xb623184d] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so[0xb6174b70] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so[0xb6154737] /home/andy/Src/Xorg-git/modular/lib/libGL.so.1[0xb64edc40] /home/andy/Src/Xorg-git/modular/lib/libGL.so.1[0xb64c8457] /home/andy/Src/Xorg-git/modular/lib/libGL.so.1[0xb64c8bb6] /home/andy/Src/Xorg-git/modular/lib/libX11.so.6(XCloseDisplay+0xb6)[0xb76a19c6] ./nexuiz-linux-686-glx[0x804d82d] ./nexuiz-linux-686-glx[0x80dec52] ./nexuiz-linux-686-glx[0x8198b15] [0xffffe400] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so[0xb616a7a0] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so[0xb62de8c8] /home/andy/Src/Mesa-git/mesa/lib/gallium/r600_dri.so[0xb619f8ca] ./nexuiz-linux-686-glx[0x80ae84c] ./nexuiz-linux-686-glx[0x8082b51] ./nexuiz-linux-686-glx[0x8087e9c] ./nexuiz-linux-686-glx[0x80dfb5f] ./nexuiz-linux-686-glx[0x804b0fd] /lib/libc.so.6(__libc_start_main+0xd0)[0xb7387380] ./nexuiz-linux-686-glx[0x804aff1] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[PATCH 0/2] vmwgfx updates for drm-next
by Thomas Hellstrom 05 Oct '10

05 Oct '10

This patch series contains a number of bugfixes and brings the vmwgfx driver up-to-date with the standalone repo. Note that the patches are against drm-fixes as of 2010-10-05, since that branch contain vmwgfx fixes that these patches depend upon. Patch 04/11 contains a modesetting driver API change needed for 05/11, and may as such not be suitable for kernel RCs but rather for the next merge window. Note that the suspend / hibernate refusal in patch 2/11 remains, see previous mail thread. Please let me know if this is still a problem.

1 11

[BUG][PATCH] 2.6.36-rc showstopper (at least for me) in vmwgfx
by Nigel Cunningham 05 Oct '10

05 Oct '10

Running a kernel based on the Rafael's -next tree, under VMware, I get the following oops while booting: Entering kdb (current=0xd73e2f70, pid 1024) on processor 0 Oops: (null) due to oops @ 0xc108bc94 <d>Modules linked in: ext4 jbd2 crc16 mptspi mptscsih mptbase <c> <d>Pid: 1024, comm: plymouthd Not tainted 2.6.36-rc4+ #60 440BX Desktop Reference Platform/VMware Virtual Platform <d>EIP: 0060:[<c108bc94>] EFLAGS: 00010246 CPU: 0 EIP is at kfree+0x36/0x88 <d>EAX: c146ccbd EBX: dc46e980 ECX: 40000400 EDX: c182cd80 <d>ESI: dfabf800 EDI: dfabf8c0 EBP: dfa7befc ESP: dfa7beec <d> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 <0>Process plymouthd (pid: 1024, ti=dfa7a000 task=d73e2f70 task.ti=dfa7a000) <0>Stack: dfabf800 dc46e980 dfabf800 dfabf8c0 dfa7bf18 c11c4ea0 c11d237c dfabf8c0 <0> dc46e980 c11c4e13 c11d5bd9 dfa7bf28 c113d3d1 dc437468 dc46e780 dfa7bf34 <0> c11c4d9d dc437468 dfa7bf40 c11d5f35 dfabf800 dfa7bf68 c11c1e3e dfabf800 <0>Call Trace: <0> [<c11c4ea0>] ? drm_master_destroy+0x8d/0xf0 <0> [<c11d237c>] ? ttm_object_file_destroy+0x0/0xd <0> [<c11c4e13>] ? drm_master_destroy+0x0/0xf0 <0> [<c11d5bd9>] ? vmw_master_drop+0x0/0x76 <0> [<c113d3d1>] ? kref_put+0x39/0x42 <0> [<c11c4d9d>] ? drm_master_put+0x12/0x1b [0]more> Only 'q' or 'Q' are processed at more prompt, input ignored <0> [<c11d5f35>] ? vmw_postclose+0x1b/0x25 <0> [<c11c1e3e>] ? drm_release+0x459/0x4cb <0> [<c1091274>] ? fput+0xcc/0x1b1 <0> [<c108ec5b>] ? filp_close+0x51/0x5b <0> [<c108ecbf>] ? sys_close+0x5a/0x88 <0> [<c1002690>] ? sysenter_do_call+0x12/0x26 <0>Code: 10 76 72 8d 90 00 00 00 40 c1 ea 0c c1 e2 05 03 15 00 1b 7e c1 66 83 3a 00 79 03 8b 52 0c 8b 0a 84 c9 78 14 66 f7 c1 00 c0 75 04 <0f> 0b eb fe 89 d0 e8 0a 3a fe ff eb 3d 8b 75 04 8b 5a 0c 9c 8f Call Trace: [<c11c4ea0>] drm_master_destroy+0x8d/0xf0 [<c11d237c>] ? ttm_object_file_destroy+0x0/0xd [<c11c4e13>] ? drm_master_destroy+0x0/0xf0 [<c11d5bd9>] ? vmw_master_drop+0x0/0x76 [<c113d3d1>] kref_put+0x39/0x42 [<c11c4d9d>] drm_master_put+0x12/0x1b [<c11d5f35>] vmw_postclose+0x1b/0x25 [<c11c1e3e>] drm_release+0x459/0x4cb [<c1091274>] fput+0xcc/0x1b1 [<c108ec5b>] filp_close+0x51/0x5b [<c108ecbf>] sys_close+0x5a/0x88 [<c1002690>] sysenter_do_call+0x12/0x26 This oops is caused by vmwgfx setting it's dev->devicename to a static char * instead of kmallocing memory. The kfree that's done in drm_master_destroy then explodes :) Signed-off-by: Nigel Cunningham <nigel(a)tuxonice.net> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 72ec2e2..1ca0ebc 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -343,8 +343,16 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) dev->dev_private = dev_priv; - if (!dev->devname) - dev->devname = vmw_devname; + if (!dev->devname) { + dev->devname = kmalloc(strlen(vmw_devname) + 1, GFP_KERNEL); + if (!dev->devname) { + DRM_ERROR("Unable to allocate memory for device " + "name.\n"); + ret = -ENOMEM; + goto out_err4; + } + strcpy(dev->devname, vmw_devname); + } if (dev_priv->capabilities & SVGA_CAP_IRQMASK) { ret = drm_irq_install(dev);

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2010