dri-devel October 2010

dri-devel@lists.freedesktop.org

76 participants
345 discussions

[Bug 30406] New: moving windows really slow when using gallium + xorg state tracker in KDE
by bugzilla-daemon＠freedesktop.org 12 Oct '10

12 Oct '10

https://bugs.freedesktop.org/show_bug.cgi?id=30406 Summary: moving windows really slow when using gallium + xorg state tracker in KDE Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: martinstolpe(a)gmail.com Created an attachment (id=38989) --> (https://bugs.freedesktop.org/attachment.cgi?id=38989) oprofile when moving windows When using gallium with the xorg state tracker moving windows becomes really slow. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 18

[git pull] drm fixes
by Dave Airlie 12 Oct '10

12 Oct '10

I was going to leave these for stable, but really they should go in now. The unmappable VRAM fixes a problem on evergreen cards in 2.6.36, we end up giving out memory past what the CPU can see and we get SIGBUS in userspace, this is because we don't have support for GPU to move memory around on evergreen until patches queued for 2.6.37. This patch just limits the VRAM when we don't have any in-kernel gpu copy code. There are two other minor evergreen fixes, and two not so useful output removed patches. Dave. The following changes since commit 85a331881dd52a93e7d4c57bcaf5486cc8718465: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 (2010-10-09 12:06:26 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Alex Deucher (3): drm/radeon/kms: leave certain CP int bits enabled drm/radeon/kms: make TV/DFP table info less verbose drm/radeon/kms: fix bad cast/shift in evergreen.c Jean Delvare (1): drm/radeon/kms: Silent spurious error message Jerome Glisse (1): drm/radeon/kms: avoid corner case issue with unmappable vram V2 drivers/gpu/drm/radeon/evergreen.c | 5 +++-- drivers/gpu/drm/radeon/r100.c | 3 +++ drivers/gpu/drm/radeon/r600.c | 4 +++- drivers/gpu/drm/radeon/r600_blit_kms.c | 2 ++ drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_atombios.c | 18 +++++++++--------- drivers/gpu/drm/radeon/radeon_combios.c | 26 +++++++++++++------------- drivers/gpu/drm/radeon/radeon_object.c | 2 +- drivers/gpu/drm/radeon/radeon_object.h | 5 +---- drivers/gpu/drm/radeon/rs600.c | 1 + drivers/gpu/drm/radeon/rs690.c | 1 + drivers/gpu/drm/radeon/rv770.c | 2 ++ 12 files changed, 40 insertions(+), 30 deletions(-)

1 0

[PATCH] r600g: fix relative addressing when splitting constant accesses
by Stephan Schmid 12 Oct '10

12 Oct '10

Hello, currently r600g ignores relative constant addressing when splitting constant accesses into multiple instructions which is fixed by the attached patch. I noticed it when messing with vp-tris arl.txt of git://anongit.freedesktop.org/mesa/demos (I modified "arr[addr.x-2]" into "arr[addr.x]" in arl.txt to get rid of the negative register indices) Cheers Stephan Schmid

1 0

[PATCH 0/5] V3 - atomic kernel mode setting for radeon, nouveau, plus fixes
by Jason Wessel 12 Oct '10

12 Oct '10

What is new in patch set v3 * Patch 3 - Per comment from Jesse Barnes change enter arg for mode_set_base_atomic() to be an enum * Patch 4 - Fixed a defect in the LUT save/restore where it should have used ctrc->gamma_size instead of the local size variable * Patch 5 - Context changes from the prior versions --- What is new in patch set v2 * patch 4 which was previously radeon specific was replaced with a generic patch to save and restore the LUT data for all drivers * minor white space cleanup vs checkpatch.pl in patches --- The goal of this patch set is to add atomic kernel mode setting hooks for the radeon and nouveau cards for the purpose of using kdb (the kernel debug shell). David Airlie had asked for more research into the gamma data corruption after initially reviewing the patch that attempts to solve the visible palette corruption after an atomic mode set operation. The final conclusion was that other types of pallet corruption are possible with the gamma data when using atomic mode setting so the problem should be solved generically. The mode_set_base_atomic() now receives and additional parameter to note of the atomic mode set operation is an enter or exit such that a driver can appropriately enable or disable hardware that will not work in the polling context. These patches have now passed the kgdb/kdb regression tests and are deemed stable and ready for further integration and comment with the hope of integrating the patches upstream. Many thanks to Chris Ball for the contribution of the radeon and nouveau hooks, as well as the time he spent helping debug the initial LUT save and restore. Thanks, Jason. --- The following changes since commit 29979aa8bd69becd94cbad59093807a417ce2a9e: Linus Torvalds (1): Merge branch 'rc-fixes' of git://git.kernel.org/.../mmarek/kbuild-2.6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git for_dri Chris Ball (3): drm/radeon/kms: Implement KDB debug hooks for radeon KMS. drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS. drm/nouveau/kms: Avoid a hang entering KDB with VT accel on. Jason Wessel (2): drm,kdb,kms: Add an enter argument to mode_set_base_atomic() API kdb,kms: Save and restore the LUT on atomic KMS enter/exit drivers/gpu/drm/drm_fb_helper.c | 36 ++++++++- drivers/gpu/drm/i915/intel_display.c | 5 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 6 ++ drivers/gpu/drm/nouveau/nv04_crtc.c | 54 +++++++++++-- drivers/gpu/drm/nouveau/nv50_crtc.c | 48 ++++++++--- drivers/gpu/drm/radeon/atombios_crtc.c | 117 +++++++++++++++++++-------- drivers/gpu/drm/radeon/radeon_fb.c | 2 + drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 44 ++++++++--- drivers/gpu/drm/radeon/radeon_mode.h | 13 +++- include/drm/drm_crtc_helper.h | 8 ++- 10 files changed, 260 insertions(+), 73 deletions(-)

1 5

[PATCH] drm/radeon/kms: avoid corner case issue with unmappable vram V3
by Alex Deucher 12 Oct '10

12 Oct '10

From: Jerome Glisse <jglisse at redhat.com> We should not allocate any object into unmappable vram if we have no means to access them which on all GPU means having the CP running and on newer GPU having the blit utility working. This patch limit the vram allocation to visible vram until we have acceleration up and running. Note that it's more than unlikely that we run into any issue related to that as when acceleration is not working userspace should allocate any object in vram beside front buffer which should fit in visible vram. V2 use real_vram_size as mc_vram_size could be bigger than the actual amount of vram V3: - Fix up r700_cp_stop (agd5f) - Handle evergreen blit (agd5f) Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/evergreen.c | 1 + drivers/gpu/drm/radeon/evergreen_blit_kms.c | 2 ++ drivers/gpu/drm/radeon/r100.c | 3 +++ drivers/gpu/drm/radeon/r600.c | 2 ++ drivers/gpu/drm/radeon/r600_blit_kms.c | 2 ++ drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_object.c | 2 +- drivers/gpu/drm/radeon/rs600.c | 1 + drivers/gpu/drm/radeon/rs690.c | 1 + drivers/gpu/drm/radeon/rv770.c | 2 ++ 10 files changed, 16 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index 2117cf5..ac12012 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -1480,6 +1480,7 @@ int evergreen_mc_init(struct radeon_device *rdev) rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024; rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024; rdev->mc.visible_vram_size = rdev->mc.aper_size; + rdev->mc.active_vram_size = rdev->mc.visible_vram_size; r600_vram_gtt_location(rdev, &rdev->mc); radeon_update_bandwidth_info(rdev); diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c b/drivers/gpu/drm/radeon/evergreen_blit_kms.c index 086b9b0..ac3b6dd 100644 --- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c +++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c @@ -495,6 +495,7 @@ done: dev_err(rdev->dev, "(%d) pin blit object failed\n", r); return r; } + rdev->mc.active_vram_size = rdev->mc.real_vram_size; return 0; } @@ -502,6 +503,7 @@ void evergreen_blit_fini(struct radeon_device *rdev) { int r; + rdev->mc.active_vram_size = rdev->mc.visible_vram_size; if (rdev->r600_blit.shader_obj == NULL) return; /* If we can't reserve the bo, unref should be enough to destroy diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 782fd6d..caaebc5 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -981,6 +981,7 @@ int r100_cp_init(struct radeon_device *rdev, unsigned ring_size) return r; } rdev->cp.ready = true; + rdev->mc.active_vram_size = rdev->mc.real_vram_size; return 0; } @@ -998,6 +999,7 @@ void r100_cp_fini(struct radeon_device *rdev) void r100_cp_disable(struct radeon_device *rdev) { /* Disable ring */ + rdev->mc.active_vram_size = rdev->mc.visible_vram_size; rdev->cp.ready = false; WREG32(RADEON_CP_CSQ_MODE, 0); WREG32(RADEON_CP_CSQ_CNTL, 0); @@ -2258,6 +2260,7 @@ void r100_vram_init_sizes(struct radeon_device *rdev) /* FIXME we don't use the second aperture yet when we could use it */ if (rdev->mc.visible_vram_size > rdev->mc.aper_size) rdev->mc.visible_vram_size = rdev->mc.aper_size; + rdev->mc.active_vram_size = rdev->mc.visible_vram_size; config_aper_size = RREG32(RADEON_CONFIG_APER_SIZE); if (rdev->flags & RADEON_IS_IGP) { uint32_t tom; diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index b5508d0..42e0c50 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -1253,6 +1253,7 @@ int r600_mc_init(struct radeon_device *rdev) rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE); rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE); rdev->mc.visible_vram_size = rdev->mc.aper_size; + rdev->mc.active_vram_size = rdev->mc.visible_vram_size; r600_vram_gtt_location(rdev, &rdev->mc); if (rdev->flags & RADEON_IS_IGP) { @@ -1922,6 +1923,7 @@ void r600_pciep_wreg(struct radeon_device *rdev, u32 reg, u32 v) */ void r600_cp_stop(struct radeon_device *rdev) { + rdev->mc.active_vram_size = rdev->mc.visible_vram_size; WREG32(R_0086D8_CP_ME_CNTL, S_0086D8_CP_ME_HALT(1)); WREG32(SCRATCH_UMSK, 0); } diff --git a/drivers/gpu/drm/radeon/r600_blit_kms.c b/drivers/gpu/drm/radeon/r600_blit_kms.c index 39d566d..8362974 100644 --- a/drivers/gpu/drm/radeon/r600_blit_kms.c +++ b/drivers/gpu/drm/radeon/r600_blit_kms.c @@ -545,6 +545,7 @@ done: dev_err(rdev->dev, "(%d) pin blit object failed\n", r); return r; } + rdev->mc.active_vram_size = rdev->mc.real_vram_size; return 0; } @@ -552,6 +553,7 @@ void r600_blit_fini(struct radeon_device *rdev) { int r; + rdev->mc.active_vram_size = rdev->mc.visible_vram_size; if (rdev->r600_blit.shader_obj == NULL) return; /* If we can't reserve the bo, unref should be enough to destroy diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 36c6881..2fc898a 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -343,6 +343,7 @@ struct radeon_mc { * about vram size near mc fb location */ u64 mc_vram_size; u64 visible_vram_size; + u64 active_vram_size; u64 gtt_size; u64 gtt_start; u64 gtt_end; diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 0afd1e6..b3b5306 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -69,7 +69,7 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain) u32 c = 0; rbo->placement.fpfn = 0; - rbo->placement.lpfn = 0; + rbo->placement.lpfn = rbo->rdev->mc.active_vram_size >> PAGE_SHIFT; rbo->placement.placement = rbo->placements; rbo->placement.busy_placement = rbo->placements; if (domain & RADEON_GEM_DOMAIN_VRAM) diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c index b24ed50..56e8bca 100644 --- a/drivers/gpu/drm/radeon/rs600.c +++ b/drivers/gpu/drm/radeon/rs600.c @@ -693,6 +693,7 @@ void rs600_mc_init(struct radeon_device *rdev) rdev->mc.real_vram_size = RREG32(RADEON_CONFIG_MEMSIZE); rdev->mc.mc_vram_size = rdev->mc.real_vram_size; rdev->mc.visible_vram_size = rdev->mc.aper_size; + rdev->mc.active_vram_size = rdev->mc.visible_vram_size; rdev->mc.igp_sideport_enabled = radeon_atombios_sideport_present(rdev); base = RREG32_MC(R_000004_MC_FB_LOCATION); base = G_000004_MC_FB_START(base) << 16; diff --git a/drivers/gpu/drm/radeon/rs690.c b/drivers/gpu/drm/radeon/rs690.c index f020e90..b4d9b2d 100644 --- a/drivers/gpu/drm/radeon/rs690.c +++ b/drivers/gpu/drm/radeon/rs690.c @@ -157,6 +157,7 @@ void rs690_mc_init(struct radeon_device *rdev) rdev->mc.aper_base = pci_resource_start(rdev->pdev, 0); rdev->mc.aper_size = pci_resource_len(rdev->pdev, 0); rdev->mc.visible_vram_size = rdev->mc.aper_size; + rdev->mc.active_vram_size = rdev->mc.visible_vram_size; base = RREG32_MC(R_000100_MCCFG_FB_LOCATION); base = G_000100_MC_FB_START(base) << 16; rdev->mc.igp_sideport_enabled = radeon_atombios_sideport_present(rdev); diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c index 57c7c0a..768e775 100644 --- a/drivers/gpu/drm/radeon/rv770.c +++ b/drivers/gpu/drm/radeon/rv770.c @@ -267,6 +267,7 @@ static void rv770_mc_program(struct radeon_device *rdev) */ void r700_cp_stop(struct radeon_device *rdev) { + rdev->mc.active_vram_size = rdev->mc.visible_vram_size; WREG32(CP_ME_CNTL, (CP_ME_HALT | CP_PFP_HALT)); WREG32(SCRATCH_UMSK, 0); } @@ -1038,6 +1039,7 @@ int rv770_mc_init(struct radeon_device *rdev) rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE); rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE); rdev->mc.visible_vram_size = rdev->mc.aper_size; + rdev->mc.active_vram_size = rdev->mc.visible_vram_size; r600_vram_gtt_location(rdev, &rdev->mc); radeon_update_bandwidth_info(rdev); -- 1.7.1.1

1 0

[PATCH 0/5] V2 - atomic kernel mode setting for radeon, nouveau, plus fixes
by Jason Wessel 12 Oct '10

12 Oct '10

What is new in patch set v2 * patch 4 which was previously radeon specific was replaced with a generic patch to save and restore the LUT data for all drivers * minor white space cleanup vs checkpatch.pl in patches --- The goal of this patch set is to add atomic kernel mode setting hooks for the radeon and nouveau cards for the purpose of using kdb (the kernel debug shell). David Airlie had asked for more research into the gamma data corruption after initially reviewing the patch that attempts to solve the visible palette corruption after an atomic mode set operation. The final conclusion was that other types of pallet corruption are possible with the gamma data when using atomic mode setting so the problem should be solved generically. The mode_set_base_atomic() now receives and additional parameter to note of the atomic mode set operation is an enter or exit such that a driver can appropriately enable or disable hardware that will not work in the polling context. These patches have now passed the kgdb/kdb regression tests and are deemed stable and ready for further integration and comment with the hope of integrating the patches upstream. Many thanks to Chris Ball for the contribution of the radeon and nouveau hooks, as well as the time he spent helping debug the initial LUT save and restore. Thanks, Jason. --- The following changes since commit 29979aa8bd69becd94cbad59093807a417ce2a9e: Linus Torvalds (1): Merge branch 'rc-fixes' of git://git.kernel.org/.../mmarek/kbuild-2.6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git for_dri Chris Ball (3): drm/radeon/kms: Implement KDB debug hooks for radeon KMS. drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS. drm/nouveau/kms: Avoid a hang entering KDB with VT accel on. Jason Wessel (2): drm,kdb,kms: Add an enter argument to mode_set_base_atomic() API kdb,kms: Save and restore the LUT on atomic KMS enter/exit drivers/gpu/drm/drm_fb_helper.c | 37 ++++++++- drivers/gpu/drm/i915/intel_display.c | 4 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 6 ++ drivers/gpu/drm/nouveau/nv04_crtc.c | 54 +++++++++++-- drivers/gpu/drm/nouveau/nv50_crtc.c | 48 ++++++++--- drivers/gpu/drm/radeon/atombios_crtc.c | 117 +++++++++++++++++++-------- drivers/gpu/drm/radeon/radeon_fb.c | 2 + drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 44 ++++++++--- drivers/gpu/drm/radeon/radeon_mode.h | 10 ++- include/drm/drm_crtc_helper.h | 3 +- 10 files changed, 251 insertions(+), 74 deletions(-)

2 8

[Bug 30771] New: vert-tex glsl demo
by bugzilla-daemon＠freedesktop.org 12 Oct '10

12 Oct '10

https://bugs.freedesktop.org/show_bug.cgi?id=30771 Summary: vert-tex glsl demo Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: kdekorte(a)yahoo.com Created an attachment (id=39344) --> (https://bugs.freedesktop.org/attachment.cgi?id=39344) vert-tex demo running on r600g using git head of 986cb9d5cf60bc11c7facc19017b5432b17240f7 In the git version of mesa there was a patch made that was supposed to make the vert-text demo work. ea1d818b58d6ff9e4cd0c40eb865beabde8f268c I tested mesa with this code installed using the r600g driver on a 3650 card. Attached is the screen shots showing the problems. The part of the structure that is not flat actually moves up and down as the image rotates around. LIBGL_ALWAYS_SOFTWARE=1 ./vert-tex looks great. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

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

12 Oct '10

https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #78 from Da Fox <da_fox(a)mad.scientist.com> 2010-10-12 05:17:12 PDT --- (In reply to comment #77) > I also set radeon.agpmode=4 on the kernel commandline in grub.conf. I don't > know what the default is, I could test it if it's important. But agpmode=4 has > works with the older kernels, so I don't think that is the issue So I've tested with radeon.agpmode=-1 yesterday and today. I've performed three tests, and each time the freeze happened. The first time the freeze happened soon after booting, while starting firefox (although I was also running the 'antspotlight' screensaver in a window. The other two times the freeze took a bit longer to manifest (45minutes to an hour). The third freeze occured while rebuilding my kernel to re-include the 'vram at zero' patch. So the freezing issue exists even in PCI mode. Tested with kernel 26bf62e47261142d528a6109fdd671a2e280b4ea - Merge branch 'drm-radeon-next' of ../drm-radeon-next into drm-core-next , with additional patch to print vram and gtt locations. dmesg | grep -iE 'radeon|agp' contains the following (lines starting with 'RADEON:' mine): ---8<--------- ... gpgart-intel 0000:00:00.0: Intel 855PM Chipset agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon 0000:01:00.0: power state changed by ACPI to D0 radeon 0000:01:00.0: power state changed by ACPI to D0 radeon 0000:01:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11 [drm] Forcing AGP to PCI mode RADEON: base at e0000000, rdev->gtt_start at 0, base would have been at e0000000 RADEON: vram sizes: rdev->mc.mc_vram_size=4000000, rdev->mc.real_vram_size=4000000 rdev->mc.visible_vram_size=8000000 radeon 0000:01:00.0: VRAM: 64M 0xE0000000 - 0xE3FFFFFF (64M used) radeon 0000:01:00.0: GTT: 512M 0xC0000000 - 0xDFFFFFFF [drm] radeon: irq initialized. [drm] radeon: 64M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] radeon: 1 quad pipes, 1 Z pipes initialized. radeon 0000:01:00.0: WB enabled [drm] radeon: ring at 0x00000000C0001000 ... --->8--------- This shows that VRAM is placed directly after GTT even in PCI mode. Can anyone please confirm these results? -- 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 22576] [KMS] mesa demo spectex broken on rv280
by bugzilla-daemon＠freedesktop.org 12 Oct '10

12 Oct '10

https://bugs.freedesktop.org/show_bug.cgi?id=22576 --- Comment #14 from Fabio Pedretti <fabio.ped(a)libero.it> 2010-10-12 01:20:45 PDT --- This could be fixed in mesa master and 7.9 branch: http://lists.freedesktop.org/archives/mesa-dev/2010-October/003492.html -- 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

Re: linux-next: Tree for October 11 (nouveau)
by Randy Dunlap 12 Oct '10

12 Oct '10

On Mon, 11 Oct 2010 16:29:59 +1100 Stephen Rothwell wrote: > Hi all, > > Changes since 20101008: When CONFIG_HWMON is not enabled: drivers/built-in.o: In function `nouveau_pm_fini': (.text+0x1c680f): undefined reference to `hwmon_device_unregister' drivers/built-in.o: In function `nouveau_hwmon_init': nouveau_pm.c:(.text+0x1c6f93): undefined reference to `hwmon_device_register' nouveau_pm.c:(.text+0x1c7094): undefined reference to `hwmon_device_unregister' --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***

2 1

← Newer
1
...
25
26
27
28
29
30
31
...
35
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2010