Re: mmotm 2010-07-01-12-19 uploaded
On Fri, 2 Jul 2010 17:26:11 +0800 Xiaotian Feng xtf...@gmail.com wrote: On Fri, Jul 2, 2010 at 3:19 AM, a...@linux-foundation.org wrote: The mm-of-the-moment snapshot 2010-07-01-12-19 has been uploaded to __ http://userweb.kernel.org/~akpm/mmotm/ and will soon be available at __ git://zen-kernel.org/kernel/mmotm.git It contains the following patches against 2.6.35-rc3: I'm running into an oops with -mmotm. It might be drm related, I don't have a camera on my hand. Cellphone cameras work. So I type the oops manually. My config is attached. Any ideas on the oops? Thanks bad_area+0x42/0x49 do_page_fault+0x206/ page_fault+0x25/0x38 ? __list_add+0x3f/0x81 ? might_fault+0x1c/0x1e __mutex_lock_common+0xc6/ ? drm_version+0x0/0x9c __mutex_lock_slowpath mutex_lock+0x31/0x4b drm_fb_release+0x28/0x75 drm_release+0x36d/0x5e4 fput+0x120/0x1cd filp_close+0x63/0x6d sys_close+0x98/0xcd system_call_fastpath Yup, that looks DRm-related. cc added. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vt/console: try harder to print output when panicing
On Wed, 23 Jun 2010 13:12:59 +1000 Dave Airlie airl...@gmail.com wrote: Jesse's initial patch commit said: At panic time (i.e. when oops_in_progress is set) we should try a bit harder to update the screen and make sure output gets to the VT, since some drivers are capable of flipping back to it. So make sure we try to unblank and update the display if called from a panic context. I've enhanced this to add a flag to the vc that console layer can set to indicate they want this behaviour to occur. This also adds support to fbcon for that flag and adds an fb flag for drivers to indicate they want to use the support. It enables this for KMS drivers. Interesting. Getting real oops traces from machines running X will make Rusty happy, and that's what we're all here for. How well does this all work? How reliable is it? What's the success rate? What's the downside here? After all, not all oopses are catastrophic - sometimes the machine will go blurt and keep running so the user can take a look in the logs then perform an orderly reboot, etc. As I understand it, those non-catastrophic oopses will now flip the machine from X and into the vt display, yes? Can the user get it back to X mode? Worse, there's also a risk that doing all this new work within the oopsing context will screw the machine up, so the user will be _deprived_ of an oops report which he otherwise would have been able to get from the logs. This is particularly the case when it's the DRI stuff which oopsed, which is not exactly an uncommon occurrence lately ;) Oh well, the best way to tell is to ship-it-and-see. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vt/console: try harder to print output when panicing
On Wed, 23 Jun 2010 13:05:47 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 23 Jun 2010 12:56:05 -0700 Andrew Morton a...@linux-foundation.org wrote: On Wed, 23 Jun 2010 13:12:59 +1000 Dave Airlie airl...@gmail.com wrote: Jesse's initial patch commit said: At panic time (i.e. when oops_in_progress is set) we should try a bit harder to update the screen and make sure output gets to the VT, since some drivers are capable of flipping back to it. So make sure we try to unblank and update the display if called from a panic context. I've enhanced this to add a flag to the vc that console layer can set to indicate they want this behaviour to occur. This also adds support to fbcon for that flag and adds an fb flag for drivers to indicate they want to use the support. It enables this for KMS drivers. Interesting. Getting real oops traces from machines running X will make Rusty happy, and that's what we're all here for. How well does this all work? How reliable is it? What's the success rate? What's the downside here? After all, not all oopses are catastrophic - sometimes the machine will go blurt and keep running so the user can take a look in the logs then perform an orderly reboot, etc. As I understand it, those non-catastrophic oopses will now flip the machine from X and into the vt display, yes? Can the user get it back to X mode? No, we'll only flip from the panic notifier chain. So we still don't get to see the output from BUGs and random oopses? I don't think panics are all that common. So am I correct in believing that if a user is getting invisible-oopses then he can set /proc/sys/kernel/panic_on_oops, and then the oops should be visible? (Shouldn't all this stuff be explained in the changlog?) -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
On Wed, 9 Jun 2010 11:22:35 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday 09 June 2010, Sedat Dilek wrote:
The patch from [1] is still missing.
cpufreq-call-nr_iowait_cpu-with-disabled-preemption.patch from
Dmitry Monakhoc
Tested-by: Sedat Dilek sedat.di...@gmail.com
Tested-by Maciej Rutecki maciej.rute...@gmail.com
I have already reported this issue on LKML [2] and cpufreq ML [3].
- Sedat -
[1] http://www.spinics.net/lists/cpufreq/msg01631.html
[2] http://lkml.org/lkml/2010/5/31/77
[3] http://www.spinics.net/lists/cpufreq/msg01637.html
Thanks, added.
I just merged a different patch whcih should address this:
From: Sergey Senozhatsky sergey.senozhat...@gmail.com
Fix
BUG: using smp_processor_id() in preemptible [] code: s2disk/3392
caller is nr_iowait_cpu+0xe/0x1e
Pid: 3392, comm: s2disk Not tainted 2.6.35-rc3-dbg-00106-ga75e02b #2
Call Trace:
[c1184c55] debug_smp_processor_id+0xa5/0xbc
[c10282a5] nr_iowait_cpu+0xe/0x1e
[c104ab7c] update_ts_time_stats+0x32/0x6c
[c104ac73] get_cpu_idle_time_us+0x36/0x58
[c124229b] get_cpu_idle_time+0x12/0x74
[c1242963] cpufreq_governor_dbs+0xc3/0x2dc
[c1240437] __cpufreq_governor+0x51/0x85
[c1241190] __cpufreq_set_policy+0x10c/0x13d
[c12413d3] cpufreq_add_dev_interface+0x212/0x233
[c1241b1e] ? handle_update+0x0/0xd
[c1241a18] cpufreq_add_dev+0x34b/0x35a
[c103c973] ? schedule_delayed_work_on+0x11/0x13
[c12c14db] cpufreq_cpu_callback+0x59/0x63
[c1042f39] notifier_call_chain+0x26/0x48
[c1042f7d] __raw_notifier_call_chain+0xe/0x10
[c102efb9] __cpu_notify+0x15/0x29
[c102efda] cpu_notify+0xd/0xf
[c12bfb30] _cpu_up+0xaf/0xd2
[c12b3ad4] enable_nonboot_cpus+0x3d/0x94
[c1055eef] hibernation_snapshot+0x104/0x1a2
[c1058b49] snapshot_ioctl+0x24b/0x53e
[c1028ad1] ? sub_preempt_count+0x7c/0x89
[c10ab91d] vfs_ioctl+0x2e/0x8c
[c10588fe] ? snapshot_ioctl+0x0/0x53e
[c10ac2c7] do_vfs_ioctl+0x42f/0x45a
[c10a0ba5] ? fsnotify_modify+0x4f/0x5a
[c11e9dc3] ? tty_write+0x0/0x1d0
[c10a12d6] ? vfs_write+0xa2/0xda
[c10ac333] sys_ioctl+0x41/0x62
[c10027d3] sysenter_do_call+0x12/0x2d
The initial fix was to use get_cpu/put_cpu in nr_iowait_cpu. However,
Arjan stated that the bug is that it needs to be nr_iowait_cpu(int cpu).
This patch introduces nr_iowait_cpu(int cpu) and changes to it callers.
akpm: addresses about 30,000,000 different bug reports.
Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
Cc: Arjan van de Ven ar...@infradead.org
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Maxim Levitsky maximlevit...@gmail.com
Cc: Len Brown len.br...@intel.com
Cc: Pavel Machek pa...@ucw.cz
Cc: Jiri Slaby jsl...@suse.cz
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/cpuidle/governors/menu.c | 10 --
include/linux/sched.h|2 +-
kernel/sched.c |4 ++--
kernel/time/tick-sched.c |4 +++-
4 files changed, 14 insertions(+), 6 deletions(-)
diff -puN
drivers/cpuidle/governors/menu.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
drivers/cpuidle/governors/menu.c
---
a/drivers/cpuidle/governors/menu.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
+++ a/drivers/cpuidle/governors/menu.c
@@ -137,15 +137,18 @@ static inline int which_bucket(unsigned
{
int bucket = 0;
+ int cpu = get_cpu();
/*
* We keep two groups of stats; one with no
* IO pending, one without.
* This allows us to calculate
* E(duration)|iowait
*/
- if (nr_iowait_cpu())
+ if (nr_iowait_cpu(cpu))
bucket = BUCKETS/2;
+ put_cpu();
+
if (duration 10)
return bucket;
if (duration 100)
@@ -169,13 +172,16 @@ static inline int which_bucket(unsigned
static inline int performance_multiplier(void)
{
int mult = 1;
+ int cpu = get_cpu();
/* for higher loadavg, we are more reluctant */
mult += 2 * get_loadavg();
/* for IO wait tasks (per cpu!) we add 5x each */
- mult += 10 * nr_iowait_cpu();
+ mult += 10 * nr_iowait_cpu(cpu);
+
+ put_cpu();
return mult;
}
diff -puN
include/linux/sched.h~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
include/linux/sched.h
---
a/include/linux/sched.h~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
+++ a/include/linux/sched.h
@@ -139,7 +139,7 @@ extern int nr_processes(void);
extern unsigned long nr_running(void);
extern unsigned long nr_uninterruptible(void);
extern unsigned long nr_iowait(void);
-extern unsigned long nr_iowait_cpu(void);
+extern unsigned long nr_iowait_cpu(int cpu);
extern unsigned long this_cpu_load(void);
diff -puN
kernel/sched.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
kernel/sched.c
---
a/kernel/sched.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34
On Wed, 16 Jun 2010 23:00:37 +0200 Sedat Dilek sedat.di...@googlemail.com wrote: On Wed, Jun 16, 2010 at 10:42 PM, Andrew Morton a...@linux-foundation.org wrote: On Wed, 9 Jun 2010 11:22:35 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday 09 June 2010, Sedat Dilek wrote: The patch from [1] is still missing. __ __cpufreq-call-nr_iowait_cpu-with-disabled-preemption.patch from Dmitry Monakhoc Tested-by: Sedat Dilek sedat.di...@gmail.com Tested-by Maciej Rutecki maciej.rute...@gmail.com I have already reported this issue on LKML [2] and cpufreq ML [3]. - Sedat - [1] http://www.spinics.net/lists/cpufreq/msg01631.html [2] http://lkml.org/lkml/2010/5/31/77 [3] http://www.spinics.net/lists/cpufreq/msg01637.html Thanks, added. I just merged a different patch whcih should address this: How do cpu-freq related stuff find its way into mainline? Is there a GIT repository/branch on git.kernel.org where you can pull from? (top-posting repaired. Please don't) Usually via the cpufreq git tree, mailing list and maintainer, as described in ./MAINTAINERS. But for a patch like this one, I'll just scoot it into mainline unless Dave happens to grab it before I do that. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.34-rc5: Reported regressions from 2.6.33
On Tue, 20 Apr 2010 05:15:57 +0200 (CEST) Rafael J. Wysocki r...@sisk.pl wrote: Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15812 Subject : utsname.domainname not set in x86_32 processes (causing YPBINDPROC_DOMAIN: domain not bound errors) Submitter : a...@hexapodia.org Date : 2010-04-19 21:28 (1 days old) I merged hch's fix for this twelve seconds ago. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.34-rc2: ima_dec_counts: open/free imbalance?
On Sun, 28 Mar 2010 13:31:49 +0200 Thomas Meyer tho...@m3y3r.de wrote: This warning/error/notice is new in 2.6.34-rc2+: Let's add some cc's. It might be a DRM bug. I'll ask Rafael and Maciej to track this as a post-2.6.33 regression, thanks. [ 1878.810147] PM: Syncing filesystems ... done. [ 1878.903316] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 1878.916589] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 1878.929866] Suspending console(s) (use no_console_suspend to debug) [ 1878.930229] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 1878.930370] sd 0:0:0:0: [sda] Stopping disk [ 1878.981086] atl1c :01:00.0: PCI INT A disabled [ 1878.981369] uhci_hcd :00:1d.2: PCI INT D disabled [ 1878.981379] uhci_hcd :00:1d.1: PCI INT B disabled [ 1878.981389] uhci_hcd :00:1d.0: PCI INT A disabled [ 1878.981454] HDA Intel :00:1b.0: PCI INT A disabled [ 1878.981500] ACPI handle has no context! [ 1878.981529] ehci_hcd :00:1a.7: PCI INT D disabled [ 1878.981540] uhci_hcd :00:1a.0: PCI INT A disabled [ 1878.981602] IMA: unmeasured files on fsmagic: 1021994 [ 1878.981605] ima_dec_counts: open/free imbalance (r:0 w:-1 o:-1) [ 1878.981609] Pid: 4888, comm: async/10 Tainted: GW 2.6.34-rc2 #88 [ 1878.981612] Call Trace: [ 1878.981620] [c0886ac2] ? printk+0x1d/0x23 [ 1878.981627] [c05f966f] ima_file_free+0x16f/0x210 [ 1878.981632] [c04d7132] __fput+0xf2/0x1f0 [ 1878.981636] [c04d724d] fput+0x1d/0x30 [ 1878.981641] [c06cbd2f] drm_gem_object_free_common+0x1f/0x40 [ 1878.981645] [c06cbdd0] ? drm_gem_object_free+0x0/0x40 [ 1878.981649] [c06cbe01] drm_gem_object_free+0x31/0x40 [ 1878.981653] [c061d20c] kref_put+0x2c/0x60 [ 1878.981658] [c06e8078] i915_gem_cleanup_ringbuffer+0x48/0x70 [ 1878.981662] [c06e97ec] i915_gem_idle+0x9c/0x120 [ 1878.981666] [c06dcefd] i915_drm_freeze+0x3d/0xa0 [ 1878.981670] [c06dd01e] i915_pm_suspend+0x2e/0x80 [ 1878.981674] [c08871ca] ? wait_for_common+0x1a/0x100 [ 1878.981679] [c0636269] pci_pm_suspend+0x49/0x110 [ 1878.981682] [c0636220] ? pci_pm_suspend+0x0/0x110 [ 1878.981687] [c07194f1] pm_op+0x181/0x1d0 [ 1878.981691] [c07126f4] ? device_for_each_child+0x54/0x60 [ 1878.981695] [c0719eaf] __device_suspend+0xbf/0x110 [ 1878.981699] [c071a2f3] async_suspend+0x23/0x60 [ 1878.981703] [c044ff25] async_thread+0xc5/0x210 [ 1878.981707] [c0886e31] ? schedule+0x1e1/0x450 [ 1878.981713] [c042c030] ? default_wake_function+0x0/0x20 [ 1878.981716] [c044fe60] ? async_thread+0x0/0x210 [ 1878.981720] [c0449254] kthread+0x74/0x80 [ 1878.981724] [c04491e0] ? kthread+0x0/0x80 [ 1878.981728] [c04034be] kernel_thread_helper+0x6/0x10 [ 1878.986489] iint_free: writecount: -1 [ 1878.986492] iint_free: opencount: -1 [ 1878.986494] iint_free: writecount: -1 [ 1878.986496] iint_free: opencount: -1 [ 1878.993205] ehci_hcd :00:1d.7: PCI INT A disabled [ 1879.649836] PM: suspend of devices complete after 719.812 msecs [ 1879.676555] PM: late suspend of devices complete after 26.714 msecs [ 1879.677144] ACPI: Preparing to enter system sleep state S3 [ 1879.677144] Back to C! Does anybody care? mfg thomas -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up
On Fri, 26 Feb 2010 11:38:59 +0100 Rafa Miecki zaj...@gmail.com wrote:
+#define wait_interruptible_timeout(wq, timeout)
\
+({ \
+long ret = timeout; \
+\
+DEFINE_WAIT(wait); \
+prepare_to_wait(wq, wait, TASK_INTERRUPTIBLE); \
+if (!signal_pending(current)) \
+ret = schedule_timeout(ret);\
+finish_wait(wq, wait); \
+\
+ret; \
+})
It's often a mistake to use signals in-kernel. Signals are more a
userspace thing and it's better to use the lower-level kernel-specific
messaging tools in-kernel. Bear in mind that userspace can
independently and asynchronously send, accept and block signals.
Can KMS use wait_event_interruptible_timeout()?
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Thu, 4 Feb 2010 22:05:59 +0100 Ingo Molnar mi...@elte.hu wrote: * Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, Feb 04, 2010 at 09:22:54PM +0100, Ingo Molnar wrote: Hey, -rc7 just hung on me after enabling this new .config option it offered for the radeon driver i am using, please add this to the list of regressions. If the same configuration options hang on both an old kernel and a new kernel, how is that in any plausible way a regression? What's regressed? Regressions are not limited to 'same config' kernels, last i checked. If that has changed (or if i'm misunderstanding it) then it would be nice to hear a clarification about that from Linus. The way i understand it is that there are narrow exceptions from the regression rules, such as completely new drivers for which there can be no prior expectation of stability by users. (but for even them we are generally on the safer side to list bugs in them as regressions as well - especially if we expect many users to enable it.) AFAIK there's no exception for new sub-features of existing facilities or drivers, even if it's default-disabled. This issue materially affects quite a few bugs i'm handling as a maintainer. Many of them are under default-off config options - most new aspects to existing code are introduced in such a way. It would remove quite a bit of urgent-workload from my workflow if i could strike them from Rafael's list and could deprioritize them as plain bugs, to be fixed as time permits. IMHO it would be rather counter-productive to kernel quality if we did that kind of regression-lawyering though. Yes, it's mainly semantics. From the user's point of view kernel N: boots, works, plays nethack kernel N+1: goes splat That kernel regressed for that user. He'll shrug and will go back to kernel N and we lost an N+1 tester. And the distros who ship N+1 get a lot of hack work to do. If the feature is this buggy, it was wrong to make it accessible in Kconfig. Anyway. The number of DRI regressions which have come in over the past few weeks is really quite extraordinary. We're now showing 31 open DRI regressions in bugzilla, but a lot of those are presumably defunct. It's been bad ever since the KMS stuff went in. That's understandable given the magnitude of the change, I guess, but the wheels really seem to have falled off in 2.6.32 and 2.6.33. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915: gpu wedged [was: mmotm 2010-01-15-15-34 uploaded]
On Sat, 23 Jan 2010 13:56:05 +0100 Jiri Slaby jirisl...@gmail.com wrote: On 01/16/2010 12:34 AM, a...@linux-foundation.org wrote: The mm-of-the-moment snapshot 2010-01-15-15-34 has been uploaded to So I've decided to switch to KMS on this kernel with 00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express Integrated Graphics Controller [8086:29c2] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation 82G33/G31 Express Integrated Graphics Controller [8086:29c2] Flags: bus master, fast devsel, latency 0, IRQ 26 Memory at ffa8 (32-bit, non-prefetchable) [size=512K] I/O ports at ec00 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at ff90 (32-bit, non-prefetchable) [size=1M] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Kernel driver in use: i915 with this X driver: (II) Module intel: vendor=X.Org Foundation compiled for 1.7.4, module version = 2.10.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 on X.Org X Server 1.7.4 and after some time I get: (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output er ror. (WW) intel(0): i830_uxa_pixmap_swap_bo_with_image: bo map failed (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output er ror. (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output er and kernel says: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung render error detected, EIR: 0x [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 153151 at 153150) [drm:i915_gem_execbuffer] *ERROR* i915_gem_do_execbuffer returns -5 From debugfs/dri/0/i915_wedged, the GPU is wedged. umph. There isn't much I can do about that, really. Apart from fervently hoping that this known regression doesn't turn up in 2.6.34-rc1. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bugme-new] [Bug 14997] New: Closing and re-opening the lid does not reactivate the backlight
On Wed, 6 Jan 2010 15:38:46 GMT bugzilla-dae...@bugzilla.kernel.org wrote: http://bugzilla.kernel.org/show_bug.cgi?id=14997 Seems to be a 2.6.31 - 2.6.32 regression. I don't know if the assignment to DRI was appropriate? -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch for 2.6.32? 1/3] drivers/gpu/drm/i915/i915_dma.c: fix unused var
This bugfix appears to have been ignored, so it missed 2.6.32.
I've tagged my 2.6.33 copy as needing a 2.6.32.x backport.
On Tue, 17 Nov 2009 14:08:52 -0800
a...@linux-foundation.org wrote:
From: Andrew Morton a...@linux-foundation.org
drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used
uninitialized in this function
Partly this is because gcc isn't smart enough. But `ll_base' does get used
uninitialised in the DRM_DEBUG() call.
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Eric Anholt e...@anholt.net
Cc: Dave Airlie airl...@linux.ie
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/gpu/drm/i915/i915_dma.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN
drivers/gpu/drm/i915/i915_dma.c~drivers-gpu-drm-i915-i915_dmac-fix-unused-var
drivers/gpu/drm/i915/i915_dma.c
---
a/drivers/gpu/drm/i915/i915_dma.c~drivers-gpu-drm-i915-i915_dmac-fix-unused-var
+++ a/drivers/gpu/drm/i915/i915_dma.c
@@ -,7 +,8 @@ static void i915_setup_compression(struc
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_mm_node *compressed_fb, *compressed_llb;
- unsigned long cfb_base, ll_base;
+ unsigned long cfb_base;
+ unsigned long ll_base = 0;
/* Leave 1M for line length buffer misc. */
compressed_fb = drm_mm_search_free(dev_priv-vram, size, 4096, 0);
_
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Fw: [Bugme-new] [Bug 14811] New: case NOUVEAU_GART_AGP: not used if not set CONFIG_AGP
Begin forwarded message:
Date: Mon, 14 Dec 2009 20:18:18 GMT
From: bugzilla-dae...@bugzilla.kernel.org
To: bugme-...@lists.osdl.org
Subject: [Bugme-new] [Bug 14811] New: case NOUVEAU_GART_AGP: not used if not
set CONFIG_AGP
http://bugzilla.kernel.org/show_bug.cgi?id=14811
Summary: case NOUVEAU_GART_AGP: not used if not set CONFIG_AGP
Product: Drivers
Version: 2.5
Kernel Version: 2.6.32-git10
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(Other)
AssignedTo: drivers_video-ot...@kernel-bugs.osdl.org
ReportedBy: pa...@pavlinux.ru
Regression: No
static struct ttm_backend *
nouveau_bo_create_ttm_backend_entry(struct ttm_bo_device *bdev)
{
struct drm_nouveau_private *dev_priv = nouveau_bdev(bdev);
struct drm_device *dev = dev_priv-dev;
switch (dev_priv-gart_info.type) {
case NOUVEAU_GART_AGP:
return ttm_agp_backend_init(bdev, dev-agp-bridge);
error: implicit declaration of function 'ttm_agp_backend_init'
warning: return makes pointer from integer without a cast
CONFIG_AGP is not set in my config
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.32-rc8 opps leaving X
On Mon, 23 Nov 2009 07:04:51 -0500 Ed Tomlinson e...@aei.ca wrote: Hi, I got the following opps when leaving X with rc8: [ 183.846716] Unpin not necessary for 88016bba2200 ! Jerome, Ed's kernel is talking to you! [ 183.860064] BUG: unable to handle kernel NULL pointer dereference at (null) [ 183.860069] IP: [8107bd39] prepare_to_wait+0x19/0x80 [ 183.860078] PGD 155125067 PUD 155126067 PMD 0 [ 183.860082] Oops: 0002 [#1] PREEMPT SMP [ 183.860085] last sysfs file: /sys/devices/pci:00/:00:18.3/temp1_input [ 183.860089] CPU 0 [ 183.860091] Modules linked in: kvm_amd kvm tun sit tunnel4 ipv6 bridge stp llc bnep sco rfcomm l2cap snd_seq_dummy snd_seq_oss snx [ 183.860140] Pid: 2720, comm: console-kit-dae Not tainted 2.6.32-rc8-crc #42 System Product Name [ 183.860142] RIP: 0010:[8107bd39] [8107bd39] prepare_to_wait+0x19/0x80 [ 183.860147] RSP: 0018:88015586dc58 EFLAGS: 00010282 [ 183.860149] RAX: 88015586dfd8 RBX: 5586dce8 RCX: [ 183.860151] RDX: 0001 RSI: RDI: 8175ee40 [ 183.860154] RBP: 88015586dc78 R08: R09: 0001 [ 183.860156] R10: R11: 0001 R12: [ 183.860157] R13: R14: 8801 R15: 0001 [ 183.860160] FS: 7f6270fd1710() GS:88002820() knlGS: [ 183.860161] CS: 0010 DS: ES: CR0: 80050033 [ 183.860163] CR2: CR3: 000155a62000 CR4: 06f0 [ 183.860165] DR0: DR1: DR2: [ 183.860166] DR3: DR6: 0ff0 DR7: 0400 [ 183.860168] Process console-kit-dae (pid: 2720, threadinfo 88015586c000, task 880155158000) [ 183.860169] Stack: [ 183.860170] 5586dce8 [ 183.860173] 0 88015586dcd8 812dc45f 880155158000 [ 183.860175] 0 8107bae0 88015586dca0 88015586dca0 0046 [ 183.860178] Call Trace: [ 183.860183] [812dc45f] vt_event_wait+0xaf/0x140 [ 183.860186] [8107bae0] ? autoremove_wake_function+0x0/0x40 [ 183.860188] [812dc523] vt_waitactive+0x33/0x60 [ 183.860191] [812dda35] vt_ioctl+0x1115/0x1cb0 [ 183.860194] [814a6f22] ? _spin_unlock_irq+0x62/0x80 [ 183.860198] [81090cca] ? __lock_acquire+0x38a/0x1550 [ 183.860202] [81142b02] ? vfs_ioctl+0x22/0xa0 [ 183.860204] [81131025] ? fget_light+0x95/0x170 [ 183.860207] [810b4179] ? __rcu_read_unlock+0x79/0x2b0 [ 183.860210] [81130c66] ? rcu_read_unlock+0x26/0x30 [ 183.860212] [811310e7] ? fget_light+0x157/0x170 [ 183.860214] [81131025] ? fget_light+0x95/0x170 [ 183.860216] [811432c9] ? sys_ioctl+0xb9/0xc0 [ 183.860220] [8100b99b] ? system_call_fastpath+0x16/0x1b [ 183.860221] Code: 74 24 18 49 89 4c 24 20 48 89 11 eb bb 0f 1f 44 00 00 55 48 89 e5 48 83 ec 20 48 89 5d e8 4c 89 65 f0 4c 89 6d [ 183.860241] RIP [8107bd39] prepare_to_wait+0x19/0x80 [ 183.860243] RSP 88015586dc58 [ 183.860244] CR2: [ 183.860247] ---[ end trace 3acb9156b0436989 ]--- However the remainder points at : commit 8b92e87d39bfd046e7581e1fe0f40eac40f88608 : Author: Alan Cox a...@linux.intel.com : AuthorDate: Sat Sep 19 13:13:24 2009 -0700 : Commit: Live-CD User li...@linux.site : CommitDate: Sat Sep 19 13:13:24 2009 -0700 : : vt: add an event interface (who is Live-CD User?) I'm a bit surprised that the X server is already using VT_WAITEVENT? It looks like vt_event_waitqueue got scribbled on. I can't see how. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Fri, 20 Nov 2009 18:53:37 + (GMT) James Simmons jsimm...@infradead.org wrote: Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? y:/usr/src/git26 perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c David Airlie airl...@linux.ie Dave Airlie airl...@redhat.com Jesse Barnes jbar...@virtuousgeek.org Mikael Pettersson mi...@it.uu.se dri-devel@lists.sourceforge.net linux-ker...@vger.kernel.org That's accurate enough. Generally, if nothing has happened in a week, the chances that it's lost are very high. Resend. If you like, cc me and I'll maintain the patches and resend them for you. cheers, lkml resendbot. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Fix oops when set_base is call with no FB
On Thu, 12 Nov 2009 12:02:58 +0100 Jerome Glisse jgli...@redhat.com wrote: On Tue, 2009-11-10 at 14:30 -0800, Andrew Morton wrote: On Wed, 4 Nov 2009 20:03:19 +0100 Jerome Glisse jgli...@redhat.com wrote: Just do nothings crct_set_base i call with no FB. hmpf. It's obvious that you spent hours carefully describing this patch for us. Sorry, truth is i don't understand why crtc set_base call back can be call with a null fb, i did just replicate what intel kms and other part of radeon kms was doing in front of such situation. It should go down to 2.6.31, useless before as there is no KMS for radeon in earlier version. The oops will happen when user switch btw X vt or in some case when changing mode. Will clearly state my ignorance in future patch. I added a bit more waffle to the changelog. Is a copy of this oops available anywhere? Seeing the backtrace would help people work out what the bug is. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Fix oops when set_base is call with no FB
On Wed, 4 Nov 2009 20:03:19 +0100
Jerome Glisse jgli...@redhat.com wrote:
Just do nothings crct_set_base i call with no FB.
hmpf. It's obvious that you spent hours carefully describing this
patch for us.
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index c15287a..f5987af 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -578,8 +578,11 @@ int atombios_crtc_set_base(struct drm_crtc *crtc, int x,
int y,
uint64_t fb_location;
uint32_t fb_format, fb_pitch_pixels, tiling_flags;
- if (!crtc-fb)
- return -EINVAL;
+ /* no fb bound */
+ if (!crtc-fb) {
+ DRM_DEBUG(No FB bound\n);
+ return 0;
+ }
radeon_fb = to_radeon_framebuffer(crtc-fb);
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 8d0b7aa..5794364 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -408,6 +408,11 @@ int radeon_crtc_set_base(struct drm_crtc *crtc, int x,
int y,
uint32_t gen_cntl_reg, gen_cntl_val;
DRM_DEBUG(\n);
+ /* no fb bound */
+ if (!crtc-fb) {
+ DRM_DEBUG(No FB bound\n);
+ return 0;
+ }
radeon_fb = to_radeon_framebuffer(crtc-fb);
Under which circumstances does this oops occur? What userspace actions?
See, curious minds want to know whether this patch is needed in 2.6.33,
2.6.32, 2.6.31.x, 2.6.30,x, etc, etc. Often we rely upon the
originator to provide us with enough information to make that decision.
You didn't do this. Please always do so.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: kill more unused DRM macros
On Mon, 19 Oct 2009 01:37:08 -0400 Andres Salomon dilin...@collabora.co.uk wrote: There are a few more macros in drmP.h that are unused; DRM_GET_PRIV_SAREA, DRM_ARRAY_SIZE, and DRM_WAITCOUNT can go away completely. Unfortunately, DRM_COPY is still used in one place, but we can at least move it to where it's used. It's an awful looking macro.. It would have been nice to fix the (valid) checkpatch warnings while you were there. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: make sure page protections are updated after changing vm_flags.
On Wed, 30 Sep 2009 15:55:39 -0700 Jeremy Fitzhardinge jer...@goop.org wrote: Some architectures compute -vm_page_prot depending on -vm_flags, so we need to update the protections after adjusting the flags. Reported-by: Jan Beulich jbeul...@novell.com Signed-off-by: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 8104eca..9d3e39f 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -537,7 +537,7 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma) vma-vm_ops = obj-dev-driver-gem_vm_ops; vma-vm_private_data = map-handle; /* FIXME: use pgprot_writecombine when available */ - vma-vm_page_prot = pgprot_writecombine(vma-vm_page_prot); + vma-vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma-vm_flags)); /* Take a ref for this mapping of the object, so that the fault * handler can dereference the mmap offset's pointer to the object. u fail changelogology. What were the consequences of the bug which you just fixed? -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: R3XX/R4XX AGP asic use PCI GART not PCIE GART
On Thu, 10 Sep 2009 13:47:09 +0200
Jerome Glisse jgli...@redhat.com wrote:
R3XX/R4XX AGP asic use the old PCI GART block, not the new PCIE GART.
Make sure we pick the right GART when disabling AGP.
This patch doesn't apply to 2.6.31. It's not completely trivial to fix
either - these declarations
+ void r100_pci_gart_tlb_flush(struct radeon_device *rdev);
+ int r100_pci_gart_enable(struct radeon_device *rdev);
+ void r100_pci_gart_disable(struct radeon_device *rdev);
+ int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
would naturally lie in radeon_asic.h but we can't do that because some
stupidhead went and put this:
static struct radeon_asic r100_asic = {
into a .h file, making that header file unusable for the things which
header files are used for.
So please have another go.
If you believe that the the patch is suitable for backporting into 2.6.31.x
then please
- cc sta...@kernel.org on the patch
- add a `Cc: sta...@kernel.org' to the changelog
- ensure that the changelog text explains to the -stable maintainers why
this patch should be backported.
Thanks.
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.31-rc7-git2: Reported regressions 2.6.29 - 2.6.30
On Wed, 26 Aug 2009 10:47:13 +0200 Rafa__ Mi__ecki zaj...@gmail.com wrote: 2009/8/25 Rafael J. Wysocki r...@sisk.pl: Bug-Entry __ __ __ : http://bugzilla.kernel.org/show_bug.cgi?id=13514 Subject __ __ __ __ : acer_wmi causes stack corruption Submitter __ __ __ : Rus harb...@sfinx.od.ua Date __ __ __ __ __ __: 2009-06-12 08:13 (75 days old) It has patch, just Len doesn't seem to... don't know, read the topic? http://patchwork.kernel.org/patch/29082/ Can we ping Len somehow to push this patch directly to Linus's tree? I'm not seeing any linux-acpi emails from Len since August 14. So I merged this patch and shall send it along with thermal_sys-check-get_temp-return-value.patch acpi-dont-call-acpi_processor_init-if-acpi-is-disabled.patch in to Linus today. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bugme-new] [Bug 13869] New: Radeon framebuffer (w/o KMS) corruption at boot.
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). (lots of cc's added) On Wed, 29 Jul 2009 16:45:00 GMT bugzilla-dae...@bugzilla.kernel.org wrote: http://bugzilla.kernel.org/show_bug.cgi?id=13869 Summary: Radeon framebuffer (w/o KMS) corruption at boot. Product: Drivers Version: 2.5 Kernel Version: 2.6.31-rc4-198-g7d3e91b Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Bluetooth AssignedTo: drivers_blueto...@kernel-bugs.osdl.org ReportedBy: 1i5t5.dun...@cox.net Regression: No I have an older rv280 Radeon 9200 SE AGP, dual CRTC, DVI + VGA (plus unconnected TV-Out). To it I have connected dual 1920x1200 monitors, one each to the DVI and VGA out ports. I run the radeon framebuffer in native 1920x1200 mode at the text console, and haven't yet enabled KMS. I've noted that for most of the 2.6.31 cycle, thru rc4-198-g7d3e91b pulled just this morning, at boot, sometimes both monitors come up fine, sometimes the VGA connected monitor comes up fine in framebuffer, while the DVI connected monitor has the characteristic larger print stair-step scramble of unmatched hardware and software resolution. Normally, they come up as clones of each other. I strongly suspect that the changes introducing Radeon KMS (even tho I don't have it enabled) disrupted the hardware mode reset of the DVI CRTC, such that it stays in whatever mode grub or early-boot uses, before the framebuffer mode switch. The VGA CRTC switches just fine, thus allowing me to actually see what I'm doing on it, login, do whatever, startx, etc. I'm guessing the code now only checks for and resets one of the CRTCs instead of both of them, as it did before. It's only when I startx and its mode switches kick in that the DVI connected monitor gets reset to normal, after which I can VT-switch back to a text VT, and they both come up fine. However, before starting X, simply switching between text/framebuffer mode VTs doesn't unscramble the DVI connected one. However, sometimes it works just fine. I /think/ it has something to do with whether it's a cold startup, or a warm C-A-D based reboot, possibly with whever mode it was in before the reboot as a triggering factor. Whatever. I've not been able to pin that angle down specifically. But that, combined with other factors including the post-hibernate load bug (bug 13750, see there for much more detail on my system, hardware, kernel config, compiler, etc) that was just fixed prior to rc4, meant that every time I was about ready to file a bug, it seemed to go away, only to return a bit later. I can git bisect this if necessary, but hopefully the above is sufficient to nail it, as I have my hands full with a problematic kde4 upgrade ATM. I don't actually see any post-2.6.31 commit to drivers/video/aty/ which could be attributed to KMS-related things. Perhaps the change lay elsewhere in the tree? Yes, I suspect that a bisect would be useful, thanks. I'll tentatively reassign this bugzilla report to DRI (how'd it get assigned to bluetooth??). I shall mark it as a regression and shall ask Rafael to add it to his (large) list. I assume that it's a post-2.6.30 regression. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [linux-pm] [PATH] i915: Read outside array bounds
(cc jbarnes)
On Sun, 26 Jul 2009 00:50:38 +0200
Roel Kluin roel.kl...@gmail.com wrote:
dev_priv-saveSWF1 is a 16 element array, but this reads up to index 22
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
save_state does not do this addition, can it be removed? please review.
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 9e1d16e..1d04e19 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -598,7 +598,7 @@ int i915_restore_state(struct drm_device *dev)
for (i = 0; i 16; i++) {
I915_WRITE(SWF00 + (i 2), dev_priv-saveSWF0[i]);
- I915_WRITE(SWF10 + (i 2), dev_priv-saveSWF1[i+7]);
+ I915_WRITE(SWF10 + (i 2), dev_priv-saveSWF1[i]);
}
for (i = 0; i 3; i++)
I915_WRITE(SWF30 + (i 2), dev_priv-saveSWF2[i]);
This looks rather correct and the original code looked rather wrong.
Someone please tell me that this might fix one of our splendid number
of i915 bugs :(
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
On Tue, 7 Jul 2009 02:00:46 +0200 (CEST) Rafael J. Wysocki r...@sisk.pl wrote: This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput wol...@onsneteindhoven.nl Date : 2009-06-17 06:28 (20 days old) Nico reported a black-screen regression too. Subject: 2.6.31-r2: Xorg: Black screen Compared to the other normal brightness problems, with 2.6.31-r2 xorg starts, but there is no image displayed (neither on internal nor external monitor). Switching back to console does not change the status, though hitting ctrlaltdel reboots the system (i.e. still up and running fine). It works with 2.6.30-rc7 (besides sometimes the brightness is broken there). This looks like it might be a post-2.6.30 regression, in which case it might have a separate cause. We're having a lot of problems in this area. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X server hung, kernel said task blocked for 120 secs (2.6.30)
(cc dri-devel) On Sun, 14 Jun 2009 21:46:05 -0400 Sanjoy Mahajan san...@mit.edu wrote: I'm running vanilla 2.6.30 on an otherwise Debian 'unstable' system -- a TP T60 with Intel graphics and wireless (no tainting). The X server [xorg 1.6.1.901 (1.6.2 RC 1), intel driver 2.7.1] hung in a way that it often has with other versions: The mouse cursor moves around as normal, but the keyboard or mouse buttons don't do anything. I used sysrq half competently to send TERM and KILL signals and then reboot. The log message below was in the /var/log/messages from when the problem happened. Should I report this information to freedesktop.org or is it a kernel issue belonging on the bugzilla? [228600.676053] INFO: task events/0:9 blocked for more than 120 seconds. [228600.676058] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [228600.676061] events/0 D 31efa204 0 9 2 [228600.676066] c1bfc040 0046 f7121a60 31efa204 c0439040 c0436134 c0101f70 f708f0c0 [228600.676075] f708f274 f7121a8c c1bfc040 c011d842 c1bfc580 [228600.676083] f708f0c0 f708f274 0366353a f626cac0 c0439040 c02f19c2 c03a8300 [228600.676090] Call Trace: [228600.676099] [c0101f70] ? __switch_to+0xbf/0x140 [228600.676105] [c011d842] ? pick_next_task_fair+0x80/0x87 [228600.676111] [c02f19c2] ? __schedule+0x6f2/0x74d [228600.676115] [c02f1fc4] ? __mutex_lock_common+0xe1/0x136 [228600.676120] [c02f2028] ? __mutex_lock_slowpath+0xf/0x11 [228600.676123] [c02f1e78] ? mutex_lock+0x10/0x1e [228600.676127] [c02f1e78] ? mutex_lock+0x10/0x1e [228600.676133] [c0133e97] ? queue_delayed_work_on+0x9c/0xa8 [228600.676150] [f8ff74f3] ? i915_gem_retire_work_handler+0x1c/0x4e [i915] [228600.676155] [c0133701] ? worker_thread+0x13d/0x1bf [228600.676168] [f8ff74d7] ? i915_gem_retire_work_handler+0x0/0x4e [i915] [228600.676174] [c01365a6] ? autoremove_wake_function+0x0/0x2d [228600.676178] [c01335c4] ? worker_thread+0x0/0x1bf [228600.676182] [c01362b6] ? kthread+0x42/0x67 [228600.676186] [c0136274] ? kthread+0x0/0x67 [228600.676190] [c0103ab7] ? kernel_thread_helper+0x7/0x10 [228611.402991] SysRq : Keyboard mode set to system default I assume this is a regression? Since 2.6.29? Thanks. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
On Sat, 30 May 2009 13:58:33 +0200 Krzysztof Helt krzysztof...@poczta.fm wrote: The intelfb driver sets color map depending on currently active pipe. However, if an LVDS display is attached (like in laptop) the active pipe variable is never set. The default value is PIPE_A and can be wrong. Set up the pipe variable during driver initialization after hardware state was read. Also, the detection of the active display (and hence the pipe) is wrong. The pipes are assigned to so called planes. Both pipes are always enabled on my laptop but only one plane is enabled (the plane A for the CRT or the plane B for the LVDS). Change active pipe detection code to take into account a status of the plane assigned to each pipe. The problem is visible in the 8 bpp mode if colors above 15 are used. The first 16 color entries are displayed correctly. The graphics chip description is here (G45 vol. 3): http://intellinuxgraphics.org/documentation.html Signed-off-by: Krzysztof Helt krzysztof...@wp.pl --- The second version of the fix to this problem. Now, it is much more sophisticated based on the knowledge gained from documentation available at http://intellinuxgraphics.org/. It does not change a default behaviour (assumed pipe A) for all cases except the case that only the plane assigned to the pipe B is active. It is enough to fix the issue for me. I queued this. Please test it. But it would great be Dean and/or Michal were to be able to test it, please. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bugme-new] [Bug 13364] New: BUG: unable to handle kernel paging request at 429a4c40
On Fri, 22 May 2009 17:59:49 GMT bugzilla-dae...@bugzilla.kernel.org wrote: http://bugzilla.kernel.org/show_bug.cgi?id=13364 The wheels seem to have fallen off the DRM code lately :( This one might be related to Alex's r6xx/r7xx changes, dunno. -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
On Sun, 17 May 2009 08:17:43 +0200 Krzysztof Helt krzysztof...@poczta.fm wrote: From: Krzysztof Helt krzysztof...@wp.pl The intelfb driver sets color map depending on currently active pipe. However, if an LVDS display is attached (like in laptop) the active pipe variable is never set. The default value is PIPE_A and can be wrong. Set up the pipe variable during driver initialization after hardware state was read. I also found by experiment that if both pipes were enabled, the PIPE_B is used (active). The problem is visible in the 8 bpp mode if colors above 15 are used. The first 16 color entries are displayed correctly. Signed-off-by: Krzysztof Helt krzysztof...@wp.pl --- This is not a regression. I have reproduced it in the 2.6.28 easily. hm, Dean's original report had This does not occur in kernel 2.6.29 -- I can see the Tasmanian devil in a penguin mask (Tuz) just fine and can view images, etc on the framebuffer. Dean, please test the patch. Yes please. diff --git a/drivers/video/intelfb/intelfbdrv.c b/drivers/video/intelfb/intelfbdrv.c index ace14fe..b47f6dd 100644 --- a/drivers/video/intelfb/intelfbdrv.c +++ b/drivers/video/intelfb/intelfbdrv.c @@ -871,6 +871,12 @@ static int __devinit intelfb_pci_register(struct pci_dev *pdev, intelfbhw_print_hw_state(dinfo, dinfo-save_state); + /* Check whether pipe A or pipe B is enabled. */ + if (dinfo-save_state.pipe_a_conf PIPECONF_ENABLE) + dinfo-pipe = PIPE_A; + if (dinfo-save_state.pipe_b_conf PIPECONF_ENABLE) + dinfo-pipe = PIPE_B; + if (bailearly == 18) bailout(dinfo); -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM: 2.6.29.2 - AGP doesn't work anymore on my nforce2
On Mon, 04 May 2009 18:40:52 +0200 Michel D__nzer mic...@daenzer.net wrote:
On Mon, 2009-05-04 at 18:23 +0200, Karsten Mehrhoff wrote:
On Mon, 04 May 2009 17:07:40 +0200, Michel D__nzer wrote:
On Mon, 2009-05-04 at 08:31 +0200, Karsten Mehrhoff wrote:
On Mon, 04 May 2009 03:41:51 +0200, Shaohua Li wrote:
On Fri, May 01, 2009 at 09:22:19PM +0800, kaw...@gmx.de wrote:
On Thu, 2009-04-30 at 17:59 -0700, Andrew Morton wrote:
On Thu, 30 Apr 2009 10:51:47 +0200
Karsten Mehrhoff wrote:
[1.]
PROBLEM: No more agp card functionality with the patch 2.6.29.2 of
'a/drivers/char/agp/generic.c'
[2.]
I compiled the kernel 2.6.29.2 with my .config of 2.6.29.1 and run
into problems with the speed of my ATI RADEON 9600 (rv350)
Is your problem speed issue ? ie just a slowdown ? Or does AGP stop
working with this patch ? Slowdown is expected from this patch but
it should hurt too much.
2.6.29.1 | 2.6.29.2
|
glxgears ~ 2900 FPS | ~ 75 FPS
glxgears -fullscreen ~ 500 FPS | ~ 11 FPS
Does this patch alone give so huge slowdown? From my little knowledge,
xserver
does agp pages allocation only at startup.
I only reverted this patch in the source file
(/drivers/char/agp/generic.c) and got back my old speed on 2.6.29.2.
Is the DRI enabled in both cases? Compare the Xorg.0.log file and the
output of
dmesg|grep -e agp -e drm
*
2.6.29.2 (original)
*
$ dmesg|grep -e agp -e drm
$ dmesg|grep agp
[0.861997] Linux agpgart interface v0.103
[ 10.893793] agpgart: Detected NVIDIA nForce2 chipset
[ 10.939070] agpgart-nvidia :00:00.0: AGP aperture is 64M @ 0xe000
No drm lines?
$ glxinfo | grep direct
direct rendering: Yes
This is not a sufficient test anymore since swrast_dri.so is direct
rendering but not hardware accelerated. Something like
glxinfo|grep render
can be used to verify both direct rendering and hardware acceleration
(the latter but not the former is also possible with AIGLX).
(EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI.
[...]
For me it seems that agp failed to initialize because of the patch.
Indeed.
Guys, can we rev this up again please?
AFAICT we have two problems and at least one of them is in 2.6.29.x and
is presumably headed into 2.6.30 as well.
a) 59de2bebabc5027f93df999d59cc65df591c3e6e made Karsten's AGP stop
working. This is very mysterious.
b) Someone, apparently karsten who has a mysterious gap in this
thread (did someone go off-list) is apparently seeing a massive
glxgears slowdown. I don't know if that slowdown was attributed to
the same commit. Or is that the same bug?
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 12 May 2009 01:40:48 GMT bugzilla-dae...@bugzilla.kernel.org wrote: http://bugzilla.kernel.org/show_bug.cgi?id=13285 Summary: INTELFB: Colors display incorrectly Product: Drivers Version: 2.5 Kernel Version: 2.6.30-rc5 This is a post-2.6.29 regression. Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Console/Framebuffers AssignedTo: jsimm...@infradead.org ReportedBy: samanddea...@yahoo.com Regression: Yes On my system, the colors are displaying incorrectly when using the Intel framebuffer. For example the Tux penguin logo has a blue background, and when I start X11 with the fbdev drivers, the xterm also has a blue background, when it is set up to have a white background. This does not occur in kernel 2.6.29 -- I can see the Tasmanian devil in a penguin mask (Tuz) just fine and can view images, etc on the framebuffer. The only change to drivers/video/intelfb/ since 2.6.29 was 347486bb108fa6e0fd2753c1be3519d6be2516ed (intelfb: support i854) which added a device ID. Do we think that this regression is due to fbdev changes, or to DRI changes? Thanks. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/2]: the patch set to weaken the dependency between ACPI video driver and i915 driver
(cc dri-devel) On Thu, 23 Apr 2009 15:56:24 -0400 (EDT) Len Brown l...@kernel.org wrote: applied thanks, Len Brown, Intel Open Source Technology Center On Wed, 15 Apr 2009, Matthew Garrett wrote: How about we just replace these with the following? diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3a22eb9..cf7e7c2 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -71,6 +71,7 @@ config DRM_I915 select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT select FB + select ACPI_VIDEO if ACPI tristate i915 driver help Choose this option if you have a system that has Intel 830M, 845G, You applied this a week ago, but it isn't in mainline or linux-next. We La described it as fixing a regression and David John said : Can you forward this patch to Linus? This regression breaks quite a : few configs where ACPI Video is compiled as a module and i915 is built : in. This should have been in stable, but I guess it's too late now. So... wazzup? -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM: 2.6.29.2 - AGP doesn't work anymore on my nforce2
On Thu, 30 Apr 2009 10:51:47 +0200
Karsten Mehrhoff kaw...@gmx.de wrote:
[1.]
PROBLEM: No more agp card functionality with the patch 2.6.29.2 of
'a/drivers/char/agp/generic.c'
[2.]
I compiled the kernel 2.6.29.2 with my .config of 2.6.29.1 and run into
problems with the speed of my ATI RADEON 9600 (rv350)
So we have a 2.6.29.1 - 2.6.29.2 regression.
...
Problematic patch:
//---
--- a/drivers/char/agp/generic.c
+++ b/drivers/char/agp/generic.c
@@ -1226,7 +1226,7 @@ int agp_generic_alloc_pages(struct agp_bridge_data
*bridge, struct agp_memory *m
int i, ret = -ENOMEM;
for (i = 0; i num_pages; i++) {
-page = alloc_page(GFP_KERNEL | GFP_DMA32);
+page = alloc_page(GFP_KERNEL | GFP_DMA32 | __GFP_ZERO);
/* agp_free_memory() needs gart address */
if (page == NULL)
goto out;
@@ -1257,7 +1257,7 @@ void *agp_generic_alloc_page(struct agp_bridge_data
*bridge)
{
struct page * page;
-page = alloc_page(GFP_KERNEL | GFP_DMA32);
+page = alloc_page(GFP_KERNEL | GFP_DMA32 | __GFP_ZERO);
if (page == NULL)
return NULL;
---//
I reverted the patch back to 2.6.29.1, compiled and the kernel agian and agp
works ok.
Really? So reverting
: commit 59de2bebabc5027f93df999d59cc65df591c3e6e
: Author: Shaohua Li shaohua...@intel.com
: AuthorDate: Mon Apr 20 10:08:35 2009 +1000
: Commit: Dave Airlie airl...@redhat.com
: CommitDate: Mon Apr 20 10:08:35 2009 +1000
:
:agp: zero pages before sending to userspace
makes your AGP work properly?
That's really weird.
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: KMS + fb + FBIOPUT_VSCREENINFO
(cc dri-devel)
On Tue, 28 Apr 2009 10:32:34 +0200 Peter Hanzel hanzelpe...@gmail.com wrote:
Hello.
I have tried DRM with intel KMS and it is workiing. I am using only
framebuffer console.
Fbcon initializes 1280x800 mode and it works like a charm.
But when I try to call FBIOPUT_VSCREENINFO on /dev/fb0, it always returns
EINVAL,
I have checked drivers/gpu/drm/i915/intel_fb.c
and found that
intelfb_check_varreturns -EINVAL if (var-pixclock == -1 ||
!var-pixclock)
intelfb_set_par returns -EINVALif (var-pixclock != -1) {
DRM_ERROR(PIXEL CLCOK SET\n); return
So the FBIOPUT_VSCREENINFO always fails.
So is the change of resolution not supported through FBIOPUT_VSCREENINFO
call?
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
On Tue, 21 Apr 2009 23:35:26 +0200 Niel Lambrechts niel.lambrec...@gmail.com wrote: Hi there, I get the following when I switch from runlevel 5 to 3 using the latest git kernel. I haven't noticed any other side-effects and X started up fine, but I'm assuming something is misbehaving and the trace might be meaningful to someone. I also frequently still notice this *ERROR* trying to get vblank count for disabled pipe 0 message when I exit Xorg. (BTW, I am still using EXA acceleration due to issues with UXA+KMS). The hardware is an Lenovo Thinkpad W500 with: 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) messages: Apr 21 00:44:00 linux-7vph init: Switching to runlevel: 3 Apr 21 00:44:06 linux-7vph kernel: [ cut here ] Apr 21 00:44:06 linux-7vph kernel: WARNING: at drivers/gpu/drm/i915/i915_gem.c:3823 i915_gem_idle+0x17a/0x28c [i915]() Apr 21 00:44:06 linux-7vph kernel: Hardware name: 40622XG Apr 21 00:44:06 linux-7vph kernel: Modules linked in: iwlagn rndis_wlan rndis_host cdc_ether usbnet cdc_acm mii usbhid hid cpufreq_stats tun i915 drm i2c_algo_bit af_packet ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt_limit snd_pcm_oss snd_mixer_oss snd_seq binfmt_misc ip6t_REJECT nf_conntrack_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle cpufreq_conservative cpufreq_userspace nf_conntrack_netbios_ns cpufreq_powersave nf_conntrack_ipv4 acpi_cpufreq nf_conntrack nf_defrag_ipv4 ip_tables speedstep_lib ip6table_filter ip6_tables x_tables ipv6 microcode fuse loop dm_mod snd_usb_audio snd_usb_lib snd_rawmidi snd_seq_device snd_hda_codec_conexant arc4 snd_hda_intel ecb snd_hda_codec snd_hwdep snd_pcm iwlcore snd_timer thinkpad_acpi snd mac80211 soundcore rtc_cmos video rfkill led_class intel_agp iTCO_wdt output rtc_core snd_page_alloc ohci1394 i2c_i801 button sr_mod wmi battery ac e1000e rtc_lib agpgart cfg80211 nvram joydev i2c_core cdrom iTCO_vendor_support sg ieee1394 sd_mod us Apr 21 00:44:06 linux-7vph kernel: bcore ext4 jbd2 crc16 edd ext3 mbcache jbd fan ahci libata scsi_mod thermal processor [last unloaded: iwlagn] Apr 21 00:44:06 linux-7vph kernel: Pid: 3193, comm: Xorg Not tainted 2.6.30-rc2-pae #24 Apr 21 00:44:06 linux-7vph kernel: Call Trace: Apr 21 00:44:06 linux-7vph kernel: [c0127768] warn_slowpath+0x71/0xa0 Apr 21 00:44:06 linux-7vph kernel: [c012f66f] ? del_timer_sync+0xd/0x18 Apr 21 00:44:06 linux-7vph kernel: [c030573c] ? schedule_timeout+0x154/0x16a Apr 21 00:44:06 linux-7vph kernel: [c01354f3] ? __cancel_work_timer+0x124/0x162 Apr 21 00:44:06 linux-7vph kernel: [f82df3ba] ? i915_gem_retire_requests+0x141/0x15b [i915] Apr 21 00:44:06 linux-7vph kernel: [f82e07e2] i915_gem_idle+0x17a/0x28c [i915] Apr 21 00:44:06 linux-7vph kernel: [f82e0947] i915_gem_leavevt_ioctl+0x1f/0x2e [i915] Apr 21 00:44:06 linux-7vph kernel: [f828574c] drm_ioctl+0x1f6/0x27c [drm] Apr 21 00:44:06 linux-7vph kernel: [f82e0928] ? i915_gem_leavevt_ioctl+0x0/0x2e [i915] Apr 21 00:44:06 linux-7vph kernel: [c0305dc0] ? mutex_lock+0xe/0x28 Apr 21 00:44:06 linux-7vph kernel: [f7ee5640] ? agpioc_release_wrap+0x57/0x5b [agpgart] Apr 21 00:44:06 linux-7vph kernel: [f7ee6279] ? agp_ioctl+0x3b6/0x3d9 [agpgart] Apr 21 00:44:06 linux-7vph kernel: [c013ef0f] ? getnstimeofday+0x51/0xda Apr 21 00:44:06 linux-7vph kernel: [c0196b3a] vfs_ioctl+0x50/0x69 Apr 21 00:44:06 linux-7vph kernel: [c0196fac] do_vfs_ioctl+0x459/0x492 Apr 21 00:44:06 linux-7vph kernel: [c01047fe] ? timer_interrupt+0x3a/0x41 Apr 21 00:44:06 linux-7vph kernel: [c0158a2a] ? handle_IRQ_event+0x8c/0x142 Apr 21 00:44:06 linux-7vph kernel: [c0306e6f] ? _spin_lock+0x8/0xb Apr 21 00:44:06 linux-7vph kernel: [c0159d5a] ? handle_edge_irq+0x108/0x111 Apr 21 00:44:06 linux-7vph kernel: [c012bcaa] ? __do_softirq+0x12b/0x133 Apr 21 00:44:06 linux-7vph kernel: [c0197025] sys_ioctl+0x40/0x5a Apr 21 00:44:06 linux-7vph kernel: [c01029d4] sysenter_do_call+0x12/0x28 Apr 21 00:44:06 linux-7vph kernel: ---[ end trace e40fb1797bec2bee ]--- Apr 21 00:44:06 linux-7vph kernel: [drm:gm45_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 Apr 21 00:44:10 linux-7vph bonobo-activation-server (niella-19973): That is WARN_ON(!list_empty(dev_priv-mm.flushing_list)); Does the warning persist in 2.6.30-rc3 or later? If so, we should add it to the post-2.6.29 regression list (if there's any room left). Thanks. -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list
Re: [DRM] NULL pointer oops in radeon_do_wait_for_idle
(cc added) On Thu, 05 Mar 2009 17:54:05 +0100 Olaf Titz o...@bigred.inka.de wrote: I have this problem since upgrading Xorg to 7.4 (Ubuntu Intrepid, radeon driver 6.9.0). Some minutes after starting X locks up completely, the rest of the system remains alive, the following Oops is left in the log. Known workaround: disable DRI in xorg.conf. The system is an UP Athlon XP desktop, currently running Linux 2.6.28.7 but I've had this problem for several kernel versions. No PM stuff or suspend/resume involved, no framebuffer driver, only one X server running. this is the graphics card: 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) Subsystem: PC Partner Limited Device 0260 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at d800 (32-bit, prefetchable) [size=128M] I/O ports at d800 [size=256] Memory at c700 (32-bit, non-prefetchable) [size=64K] Expansion ROM at d7fe [disabled] [size=128K] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01) Subsystem: PC Partner Limited Device 0261 Flags: bus master, 66MHz, medium devsel, latency 64 Memory at c800 (32-bit, prefetchable) [size=128M] Memory at c680 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 snip Mar 5 17:19:20 bigred kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 22 Mar 5 17:19:20 bigred kernel: BUG: unable to handle kernel NULL pointer dereference at 0330 Mar 5 17:19:20 bigred kernel: IP: [f0b12e02] radeon_do_wait_for_idle+0x12/0x160 [radeon] Mar 5 17:19:20 bigred kernel: *pde = Mar 5 17:19:20 bigred kernel: Oops: [#1] PREEMPT Mar 5 17:19:20 bigred kernel: last sysfs file: /sys/devices/pci:00/:00:10.2/pools Mar 5 17:19:20 bigred kernel: Modules linked in: nfsd auth_rpcgss exportfs fan st nfs lockd sunrpc radeon drm asb100 hwmon_vid hwmon snd_via82xx snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd soundcore sg sr_mod cdrom usb_storage 8250_pnp 8250 serial_core button Mar 5 17:19:20 bigred kernel: Mar 5 17:19:20 bigred kernel: Pid: 2175, comm: Xorg Not tainted (2.6.28.7 #1) System Name Mar 5 17:19:20 bigred kernel: EIP: 0060:[f0b12e02] EFLAGS: 00213206 CPU: 0 Mar 5 17:19:20 bigred kernel: EIP is at radeon_do_wait_for_idle+0x12/0x160 [radeon] Mar 5 17:19:20 bigred kernel: EAX: 000186a0 EBX: f0b30b30 ECX: 0003 EDX: 0003e420 Mar 5 17:19:20 bigred kernel: ESI: EDI: eed31400 EBP: ee017420 ESP: ee1f8ec8 Mar 5 17:19:20 bigred kernel: DS: 007b ES: 007b FS: GS: 0033 SS: 0068 Mar 5 17:19:20 bigred kernel: Process Xorg (pid: 2175, ti=ee1f8000 task=ef909b00 task.ti=ee1f8000) Mar 5 17:19:20 bigred kernel: Stack: Mar 5 17:19:20 bigred kernel: e65f78f0 fff4 f0b30b30 f0ad45b6 ef8ad100 c024b8dd Mar 5 17:19:20 bigred kernel: 0001 efb85080 6444 eed31424 f0b13ed0 Mar 5 17:19:20 bigred kernel: f0b2efb4 ee1fa900 6444 c017eb78 ee1fa900 ef512e00 Mar 5 17:19:20 bigred kernel: Call Trace: Mar 5 17:19:20 bigred kernel: [f0ad45b6] drm_ioctl+0xf6/0x310 [drm] Mar 5 17:19:20 bigred kernel: [c024b8dd] tty_ioctl+0xcd/0x890 Mar 5 17:19:20 bigred kernel: [f0b13ed0] radeon_cp_idle+0x0/0xc0 [radeon] Mar 5 17:19:20 bigred kernel: [c017eb78] vfs_ioctl+0x78/0x90 Mar 5 17:19:20 bigred kernel: [c017ed27] do_vfs_ioctl+0x67/0x4f0 Mar 5 17:19:20 bigred kernel: [c0172a22] vfs_write+0x102/0x140 Mar 5 17:19:20 bigred kernel: [c017f1ed] sys_ioctl+0x3d/0x70 Mar 5 17:19:20 bigred kernel: [c0103261] sysenter_do_call+0x12/0x25 Mar 5 17:19:20 bigred kernel: Code: 00 00 46 e8 01 68 6f cf 39 73 68 7f dc b8 f0 ff ff ff eb 81 90 8d 74 26 00 56 89 c6 53 83 ec 10 83 48 70 08 8b 40 68 85 c0 7e 46 8b 86 30 03 00 00 8b 40 10 05 40 0e 00 00 8b 00 83 e0 7f 31 db Mar 5 17:19:20 bigred kernel: EIP: [f0b12e02] radeon_do_wait_for_idle+0x12/0x160 [radeon] SS:ESP 0068:ee1f8ec8 Mar 5 17:19:20 bigred kernel: ---[ end trace a5c0e64d6e3ca307 ]--- Mar 5 17:19:20 bigred kernel: [drm:drm_release] *ERROR* Device busy: 1 0 Mar 5 17:19:21 bigred kernel: BUG: unable to handle kernel NULL pointer dereference at 0005 Mar 5 17:19:21 bigred kernel: IP: [ee184800] 0xee184800 Mar 5 17:19:21 bigred kernel: *pde = Mar 5 17:19:21 bigred kernel: Oops: 0002 [#2] PREEMPT Mar 5 17:19:21 bigred kernel: last sysfs file: /sys/devices/pci:00/:00:01.0/:01:00.0/enable Mar 5 17:19:21 bigred kernel: Modules linked in: nfsd auth_rpcgss exportfs fan st nfs lockd sunrpc radeon drm asb100 hwmon_vid hwmon snd_via82xx
Re: i915 X lockup
On Sat, 28 Feb 2009 09:31:28 +0100 Jiri Slaby jirisl...@gmail.com wrote: On 28.2.2009 01:20, Eric Anholt wrote: KMS support is not a feature of the server but of your 2D driver. You want 2.6.2, or things will be bad. I have 2.5.0. After turning KMS off, problem seems to be solved. Anyway, I would appreciate a version of the intel driver being in the Kconfig text, otherwise it looks like: don't use this on machines with installation from stone age. If one has latest stable release of a distro, he doesn't even think he doesn't have new enough userspace. For reference, the text is: Choose this option if you want kernel modesetting enabled by default, and you have a new enough userspace to support this. Running old userspaces with this enabled will cause pain. Hang on. The kernel deadlocked on struct_mutex, did it not? That's a kernel bug regardless of what userspace you're running. Do we know why this happened? -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 X lockup
On Fri, 27 Feb 2009 10:28:51 +0100 Jiri Slaby jirisl...@gmail.com wrote:
everytime I run X, it gets stuck. Currently running on mmotm
2009-02-26-16-58, but I think this is wider problem. I had i915 disabled
for a long time (until I noticed today).
SysRq : Show Locks Held
Showing all locks held in the system:
3 locks held by events/0/10:
#0: (events){+.+.+.}, at: [8025223d] worker_thread+0x19d/0x340
#1: ((dev_priv-mm.retire_work)-work){+.+...}, at:
[8025223d] worker_thread+0x19d/0x340
#2: (dev-struct_mutex){+.+.+.}, at: [804057ba]
i915_gem_retire_work_handler+0x3a/0x90
1 lock held by mingetty/3899:
#0: (tty-atomic_read_lock){+.+.+.}, at: [803cb5de]
n_tty_read+0x48e/0x8e0
1 lock held by mingetty/3900:
#0: (tty-atomic_read_lock){+.+.+.}, at: [803cb5de]
n_tty_read+0x48e/0x8e0
1 lock held by mingetty/3901:
#0: (tty-atomic_read_lock){+.+.+.}, at: [803cb5de]
n_tty_read+0x48e/0x8e0
1 lock held by X/4007:
#0: (dev-struct_mutex){+.+.+.}, at: [8040563c]
i915_gem_throttle_ioctl+0x2c/0x60
2 locks held by bash/4105:
#0: (sysrq_key_table_lock){..}, at: [803de366]
__handle_sysrq+0x26/0x190
#1: (tasklist_lock){.+.+..}, at: [80266c1f]
debug_show_all_locks+0x3f/0x1c0
I assume that i915_gem_throttle_ioctl-i915_gem_ring_throttle is stuck
in i915_wait_request(), holding struct_mutex. That of course makes
keventd block.
Perhaps i915_wait_request() is waiting for keventd to do something,
which is the deadlock. That something could be to simply finish its
current call to i915_gem_retire_work_handler().
But worse, it could be some completely other keventd handler which
isn't getting run, because that keventd instance is stuck over in
i915_gem_retire_work_handler().
IOW, the usual keventd problem.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings.
On Fri, 20 Feb 2009 00:54:14 -0800 (PST) David Miller da...@davemloft.net wrote: From: Andrew Morton a...@linux-foundation.org Date: Thu, 19 Feb 2009 15:27:26 -0800 eg: arch/xtensa/include/asm/shmparam.h #define SHMLBA ((PAGE_SIZE DCACHE_WAY_SIZE)? PAGE_SIZE : DCACHE_WAY_SIZE) But including linux/shm.h here seems a bit silly. We'll see.. If DRM even builds on XTENSA, let alone is usable there, I'll buy you a lollipop. heh, OK. But the risk is there. tries to test sparc32 allmodconfig scripts/mod/empty.c:1: error: -m64 is not supported by this configuration scripts/mod/empty.c:1: error: -mlong-double-64 not allowed with -m64 scripts/mod/empty.c:1: error: -mcmodel= is not supported on 32 bit systems retires hurt -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: + drivers-gpu-drm-i915-intel_lvdsc-fix-locking-snafu.patch added to -mm tree
(cc's added)
On Sat, 31 Jan 2009 16:25:08 +0100 Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jan 29, 2009 at 01:48:25PM -0800, Andrew Morton wrote:
On Thu, 29 Jan 2009 13:24:17 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thursday, January 29, 2009 12:50 pm a...@linux-foundation.org wrote:
diff -puN
drivers/gpu/drm/i915/intel_lvds.c~drivers-gpu-drm-i915-intel_lvdsc-fix-lock
ing-snafu drivers/gpu/drm/i915/intel_lvds.c ---
a/drivers/gpu/drm/i915/intel_lvds.c~drivers-gpu-drm-i915-intel_lvdsc-fix-lo
cking-snafu +++ a/drivers/gpu/drm/i915/intel_lvds.c
@@ -311,7 +311,7 @@ static int intel_lvds_get_modes(struct d
if (dev_priv-panel_fixed_mode != NULL) {
struct drm_display_mode *mode;
- mutex_unlock(dev-mode_config.mutex);
+ mutex_lock(dev-mode_config.mutex);
mode = drm_mode_duplicate(dev,
dev_priv-panel_fixed_mode);
drm_mode_probed_add(connector, mode);
mutex_unlock(dev-mode_config.mutex);
_
Patches currently in -mm which might be from a...@linux-foundation.org
are
Oops. This should go upstream asap.
yup, I'll send it later today hopefully.
Thanks for the speedy fix. Unfortunately it looks like the locking in this
area still doesn't quite work:
Enabling kms works flawlessly now, but when I fire up X, the screen blanks
(no more blinking cursors), then X hangs. vt-switchings doesn't work
anymore, otherwise the machine looked fine (ping on the network was fine,
couldn't check anything else for lack of a running sshd on the crashing
machine). Twice using SysRq-T (half a minute in between) showed that Xorg
was indeed stuck, both times with the exact same backtrace:
Xorg D 00203246 6448 6049 6048
f1c81df0 00203046 f6322720 00203246 f1c81de0 f83fb98d f6322720 f632297c
00203046 f1d88444 00203046 f2f63cc0 f8388dae f1d88444 f1d88408
00203246 f1c81e2c c02e18ba f83fb98d f6322720 f1d88430 f1d88444
Call Trace:
[f83fb98d] ? intel_lvds_get_modes+0x69/0x94 [i915]
[f8388dae] ? drm_mode_getconnector+0x54/0x31f [drm]
[c02e18ba] mutex_lock_nested+0x158/0x254
[f83fb98d] ? intel_lvds_get_modes+0x69/0x94 [i915]
[f83fb98d] intel_lvds_get_modes+0x69/0x94 [i915]
[f838a170] drm_helper_probe_single_connector_modes+0xb8/0x194 [drm]
[f8388e20] drm_mode_getconnector+0xc6/0x31f [drm]
[c02e13bc] ? mutex_unlock+0xd/0xf
[f837f71f] drm_ioctl+0x1c1/0x23d [drm]
[f8388d5a] ? drm_mode_getconnector+0x0/0x31f [drm]
[f837f55e] ? drm_ioctl+0x0/0x23d [drm]
[c0191277] vfs_ioctl+0x43/0x56
[c0191a34] do_vfs_ioctl+0x49f/0x4e0
[c0186c42] ? vfs_write+0xf5/0x131
[c0191aba] sys_ioctl+0x45/0x5f
[c0102e91] sysenter_do_call+0x12/0x31
This is on 2.6.29-rc3-00100-gf2257b7.
So I assume that it would make sense to track this as a post-2.6.28
regression?
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM: kernel BUG at drivers/gpu/drm/drm_fops.c:146!
On Fri, 30 Jan 2009 10:13:55 +0100 Thomas Hellstr__m tho...@shipmail.org wrote: Sounds right to me. The offsets are just handles, not real file objects or backing store addresses. We use them to take advantage of all the inode address mapping helpers, since they track stuff for us. That said, unmap_mapping_range may not be the best way to do this; basically we need a way to invalidate a given processes' mapping of a GTT range (which in turn is backed by real RAM). If there's some other way we should be doing this I'm all ears. Well, we'd need to call in the big guns on this one - I've already stirred Hugh ;) unmap_mapping_range() is basically a truncate thing - it shoots down all mappings of a range of a *file*. Across all processes in the machine which map that file. If that isn't what you want to do (and it sounds that way) then you'd want to use something which is mm_struct (or vma) centric, rather than file-centric. zap_page_range(), methinks. I guess I was the one starting to use this function, so some explanation: When the drm device is used to provide address space for buffers, user-space actually see it as a file with a distinct offset where buffers are laid out in a linear fashion, To access a certain buffer you need to lseek() to the correct offset and then read() write() or, the more common use, mmap / munmap. When looking through its implementation, unmap_mapping_range() seemed to do exactly the thing I wanted, namely to kill all user-space mappings of all vmas of all processes mapping a part of the device address space. That's different from what Jesse said. That _is_ a more appropriate use of unmap_mapping_range(). Although all the futzing that function does with truncate_count is now looking inappropriately-placed. And it saves us from storing a list of all vmas mapping the device within the drm device. What makes usage of unmap_mapping_range() on a device node with a well defined offset-to-data mapping different from using it on a file? umm, nothing I guess, if the driver sufficiently imitates a regular file. It's unexpected (by me). I don't think we wrote that code with this application in mind ;) -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM: kernel BUG at drivers/gpu/drm/drm_fops.c:146!
(cc's added) On Wed, 21 Jan 2009 13:27:48 +0100 Sami Kerola kerol...@iki.fi wrote: I compiled the Torvalds git kernel 2.6.29-rc2-00013 and I got an oops. The oops happens when ever X starts. Initially I was booting with run level 5 and it hung. I tried to use run level to 3 and an operating system started just fine. When I type startx the hung happen again. Please let me know if you need some more information besides oops from messages file and lspci output. Jan 21 08:53:58 lelux kernel: [ cut here ] Jan 21 08:53:58 lelux kernel: kernel BUG at drivers/gpu/drm/drm_fops.c:146! I assume that 2.6.28 didn't do this? Seems odd - nothing much has changed around there lately. Jan 21 08:53:58 lelux kernel: invalid opcode: [#1] SMP Jan 21 08:53:58 lelux kernel: last sysfs file: /sys/devices/pci:00/:00:02.0/drm/card0/dri_library_name Jan 21 08:53:58 lelux kernel: CPU 0 Jan 21 08:53:58 lelux kernel: Modules linked in: i915 drm i2c_algo_bit ipv6 fuse acpi_cpufreq dm_multipath snd_hda_codec_idt arc4 ecb snd_hda_intel snd_hda_codec iwlag n snd_hwdep snd_seq_dummy snd_seq_oss iwlcore snd_seq_midi_event snd_seq rfkill snd_seq_device lib80211 snd_pcm_oss mac80211 snd_mixer_oss snd_pcm firewire_ohci i2c_i8 01 snd_timer firewire_core ppdev snd sr_mod pcspkr joydev yenta_socket i2c_core video sg iTCO_wdt tg3 rsrc_nonstatic cdrom crc_itu_t iTCO_vendor_support parport_pc out put parport libphy soundcore cfg80211 wmi battery snd_page_alloc ac pata_acpi ata_generic ata_piix libata sd_mod scsi_mod sha256_generic cbc aes_x86_64 aes_generic dm_ crypt dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode] Jan 21 08:53:58 lelux kernel: Pid: 2902, comm: X Not tainted 2.6.29-rc2-00013-gf3b8436-dirty #1 Jan 21 08:53:58 lelux kernel: RIP: 0010:[a0486f7b] [a0486f7b] drm_open+0x4b7/0x4f0 [drm] Jan 21 08:53:58 lelux kernel: RSP: 0018:88006ec01cd8 EFLAGS: 00010293 Jan 21 08:53:58 lelux kernel: RAX: 88006f8e2100 RBX: 88006f47d060 RCX: Jan 21 08:53:58 lelux kernel: RDX: 88007a016b90 RSI: 88006ec4 RDI: 88006ec01c28 Jan 21 08:53:58 lelux kernel: RBP: 88006ec01d18 R08: 88006ec40760 R09: 02e7 Jan 21 08:53:58 lelux kernel: R10: 88006ec4 R11: 0006 R12: Jan 21 08:53:58 lelux kernel: R13: 88006f47d000 R14: 88006f47d060 R15: 88006ec33918 Jan 21 08:53:58 lelux kernel: FS: 7f4495429780() GS:8192e000() knlGS: Jan 21 08:53:58 lelux kernel: CS: 0010 DS: ES: CR0: 80050033 Jan 21 08:53:58 lelux kernel: CR2: 7f4494de01a0 CR3: 7046 CR4: 06e0 Jan 21 08:53:58 lelux kernel: DR0: DR1: DR2: Jan 21 08:53:58 lelux kernel: DR3: DR6: 0ff0 DR7: 0400 Jan 21 08:53:58 lelux kernel: Process X (pid: 2902, threadinfo 88006ec0, task 88006ec4) Jan 21 08:53:58 lelux kernel: Stack: Jan 21 08:53:58 lelux kernel: 88006d071000 88007a016b90 88006d044000 ffed Jan 21 08:53:58 lelux kernel: a04959d0 88006d071000 88007a016b90 88007a016b90 Jan 21 08:53:58 lelux kernel: 88006ec01d48 a0486a53 88007c9adc00 Jan 21 08:53:58 lelux kernel: Call Trace: Jan 21 08:53:58 lelux kernel: [a0486a53] drm_stub_open+0xd2/0x143 [drm] Jan 21 08:53:58 lelux kernel: [810df703] chrdev_open+0x149/0x168 Jan 21 08:53:58 lelux kernel: [8114e8b9] ? selinux_dentry_open+0xeb/0xf4 Jan 21 08:53:58 lelux kernel: [810df5ba] ? chrdev_open+0x0/0x168 Jan 21 08:53:58 lelux kernel: [810db03f] __dentry_open+0x151/0x270 Jan 21 08:53:58 lelux kernel: [810db235] nameidata_to_filp+0x46/0x57 Jan 21 08:53:58 lelux kernel: [810e84fb] do_filp_open+0x44f/0x8a7 Jan 21 08:53:58 lelux kernel: [81065661] ? lock_release_holdtime+0x1c/0x173 Jan 21 08:53:58 lelux kernel: [8118a136] ? _raw_spin_unlock+0x8e/0x94 Jan 21 08:53:58 lelux kernel: [810f14c5] ? alloc_fd+0x122/0x133 Jan 21 08:53:58 lelux kernel: [810dae22] do_sys_open+0x58/0xd8 Jan 21 08:53:58 lelux kernel: [810daed5] sys_open+0x20/0x22 Jan 21 08:53:58 lelux kernel: [8100c42a] system_call_fastpath+0x16/0x1b Jan 21 08:53:58 lelux kernel: Code: 48 89 df e8 55 e4 ea e0 48 8b 45 d0 83 78 04 01 75 2f 49 8b 85 00 06 00 00 48 85 c0 74 11 48 8b 55 c8 48 3b 82 30 02 00 00 74 16 0f 0b eb fe 48 8b 55 c8 48 8b 82 30 02 00 00 49 89 85 00 06 00 -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___
Re: PROBLEM: kernel BUG at drivers/gpu/drm/drm_fops.c:146!
On Fri, 30 Jan 2009 11:06:47 +1000 Dave Airlie airl...@gmail.com wrote: On Fri, Jan 30, 2009 at 10:30 AM, Andrew Morton a...@linux-foundation.org wrote: (cc's added) On Wed, 21 Jan 2009 13:27:48 +0100 Sami Kerola kerol...@iki.fi wrote: I compiled the Torvalds git kernel 2.6.29-rc2-00013 and I got an oops. The oops happens when ever X starts. Initially I was booting with run level 5 and it hung. I tried to use run level to 3 and an operating system started just fine. When I type startx the hung happen again. Please let me know if you need some more information besides oops from messages file and lspci output. Jan 21 08:53:58 lelux kernel: [ cut here ] Jan 21 08:53:58 lelux kernel: kernel BUG at drivers/gpu/drm/drm_fops.c:146! I assume that 2.6.28 didn't do this? This is a userspace race between udev and libdrm, I'm not sure we can do anything in the kernel other than BUG, maybe we should just WARN instead. Basically, libdrm creates devices nodes, the initial drm opening gets that, udev comes along when the module is loaded and re-creates the device node, when AIGLX opens the device it can't figure out wtf just happened, as the inode-i_mapping we use to store the GEM device mmap ranges is different. I think building libdrm with --enable-udev is the correct answer, and maybe switching this to a WARN so it doesn't blow up. maybe we shouldn't be storing the inode mapping like this? anyone any better idea? hm, I'm a bit surprised to see the drm code using `struct address_space' and read_mapping_page() and unmap_mapping_range() and such. I thought those only worked with regular files and pagecache :) Is it possible to briefly explain what's going on there? What instance of address_space_operations does -dev_mapping actually point at? -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM: kernel BUG at drivers/gpu/drm/drm_fops.c:146!
On Thu, 29 Jan 2009 19:50:17 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Thursday, January 29, 2009 5:43 pm Dave Airlie wrote: On Fri, Jan 30, 2009 at 11:20 AM, Andrew Morton hm, I'm a bit surprised to see the drm code using `struct address_space' and read_mapping_page() and unmap_mapping_range() and such. I thought those only worked with regular files and pagecache :) Is it possible to briefly explain what's going on there? What instance of address_space_operations does -dev_mapping actually point at? Okay a bit tired and headache coming on but I'll try, maybe jbarnes can help out, We need to provide mappings to userspace that are backed by memory that can move around behind the mappings. So userspace wants a mapping for a GEM object via the AGP/GTT aperture instead of directly to the backing pages. Now as the GEM object is backed by shmem we can't use the shmem file descriptor we have to tie the mapping to without hacking up the shmem mmap functionality which seemed like a bad plan. So GEM uses the device inode to setup the mappings on. We just use a simple linear allocator to split up the device inodes address space and assign chunks to handles for different objects. The userspace app then uses the handle via mmap to get access to the VMAs. Now when GEM wants to move that object out of the GTT or to another area of the GTT we need some way to invalidate it, so we use unmap_mapping_range which destroys all the mappings for the object in all the VMA for all the processes mapping it currently GEM's read_mapping_page is distinct from this and is to do with the shmem interfaceing. Not sure if this explains it or just make it worse. Sounds right to me. The offsets are just handles, not real file objects or backing store addresses. We use them to take advantage of all the inode address mapping helpers, since they track stuff for us. That said, unmap_mapping_range may not be the best way to do this; basically we need a way to invalidate a given processes' mapping of a GTT range (which in turn is backed by real RAM). If there's some other way we should be doing this I'm all ears. Well, we'd need to call in the big guns on this one - I've already stirred Hugh ;) unmap_mapping_range() is basically a truncate thing - it shoots down all mappings of a range of a *file*. Across all processes in the machine which map that file. If that isn't what you want to do (and it sounds that way) then you'd want to use something which is mm_struct (or vma) centric, rather than file-centric. zap_page_range(), methinks. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Fw: [Bugme-new] [Bug 12381] New: mach64_drm.h missing
Begin forwarded message: Date: Wed, 7 Jan 2009 10:30:07 -0800 (PST) From: bugme-dae...@bugzilla.kernel.org To: bugme-...@lists.osdl.org Subject: [Bugme-new] [Bug 12381] New: mach64_drm.h missing http://bugzilla.kernel.org/show_bug.cgi?id=12381 Summary: mach64_drm.h missing Product: Other Version: 2.5 KernelVersion: 2.6.18 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: other_ot...@kernel-bugs.osdl.org ReportedBy: l.bigonvi...@edpnet.be Hi, It seems that the mach64_drm.h header is missing from the include/drm directory, could you please add it. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bugme-new] [Bug 12078] New: DRI hangs for kernels above 2.6.24 on system wiht two graphics cards.
fyi.. On Sat, 22 Nov 2008 08:26:47 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=12078 Summary: DRI hangs for kernels above 2.6.24 on system wiht two graphics cards. Product: Platform Specific/Hardware Version: 2.5 KernelVersion: 2.6.25 and up Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: i386 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Latest working kernel version: 2.6.24 Earliest failing kernel version: 2.6.25 Distribution: gentoo Hardware Environment: Dell PE2850 (2x XEON, 4GB RAM) with 2 PCI radeons 9250 Software Environment: Xorg server 1.5.2 Problem Description: For any kernel above 2.6.24 (I tested with gentoo distribution kernels and official kernels up to 2.6.27) starting Xorg with dri enabled causes a system to hang. The problem can be reproduced with a few Xorg versions below 1.5.2 and with in kernel dri modules as well as with gentoo x11-drm modules. Looking in Xorg logs I see that int10 module fails for second graphics card (Log created with X -probeonly). I also can see that video ram of second graphics card is not detected correctly. With kernel below 2.6.25 it is OK. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes for 2.6.27-rc5
On Tue, 11 Nov 2008 08:15:26 + (GMT) Dave Airlie [EMAIL PROTECTED] wrote:
commit 78538bf14995a136c2d9a22159ada49937359119
Author: Dave Airlie [EMAIL PROTECTED]
Date: Tue Nov 11 17:56:16 2008 +1000
drm/radeon: map registers at load time
Now that the radeon driver has suspend/resume functions, it needs to map
its
registers at load time or it will likely crash if a suspend operation
occurs
before the driver has been initialized.
This patch moves the register mapping code from firstopen to load and
makes
the mapping into a _DRM_DRIVER one so that the core won't remove it at
lastclose time.
Does this make the below patch obsolete?
Fixes (at least partially) kernel bz #11891.
A little thing: there are (or used to be) people who troll commits for
bugzilla reports to close off. I've adopted the convention of
indicating bugzilla reports via their full URL to make those efforts
easier and to increase their accuracy.
From: Jiri Slaby [EMAIL PROTECTED]
When the driver is bound to a device and nobody opens the device node, it
will oops on suspend and resume, since it's not mapped and dev_priv-mmio
is NULL.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
Cc: David Airlie [EMAIL PROTECTED]
Cc: Rafael J. Wysocki [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/gpu/drm/radeon/radeon_drv.c |6 ++
1 file changed, 6 insertions(+)
diff -puN
drivers/gpu/drm/radeon/radeon_drv.c~drm-fix-radeon-suspend-resume-oops
drivers/gpu/drm/radeon/radeon_drv.c
--- a/drivers/gpu/drm/radeon/radeon_drv.c~drm-fix-radeon-suspend-resume-oops
+++ a/drivers/gpu/drm/radeon/radeon_drv.c
@@ -56,6 +56,9 @@ static int radeon_suspend(struct drm_dev
{
drm_radeon_private_t *dev_priv = dev-dev_private;
+ if (!dev_priv-mmio)
+ return 0;
+
/* Disable *all* interrupts */
if ((dev_priv-flags RADEON_FAMILY_MASK) = CHIP_RS690)
RADEON_WRITE(R500_DxMODE_INT_MASK, 0);
@@ -67,6 +70,9 @@ static int radeon_resume(struct drm_devi
{
drm_radeon_private_t *dev_priv = dev-dev_private;
+ if (!dev_priv-mmio)
+ return 0;
+
/* Restore interrupt registers */
if ((dev_priv-flags RADEON_FAMILY_MASK) = CHIP_RS690)
RADEON_WRITE(R500_DxMODE_INT_MASK, dev_priv-r500_disp_irq_reg);
_
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
On Thu, 23 Oct 2008 13:22:12 -0700
Keith Packard [EMAIL PROTECTED] wrote:
We just ran some numbers on a box with PAT enabled and broken MTRRs.
Finally we have a test platform for the difference between kmap_atomic
and kmap_atomic_prot. Using regular kmap_atomic on this platform, we get
UC access to the graphics device; sending data from the CPU is a bit
slow. Adding kmap_atomic_prot_pfn and specifying WC access raises that
by a fairly significant factor, taking our CPU utilization for
copy_from_user from 40% to 2%.
Here's a patch which adds kmap_atomic_prot_pfn to the kernel for this
usage. When we add native io-mapping support instead of sitting on top
of kmap, we can remove this function.
I've reworked the io_mapping patches to use this function as well, along
with cleaning up the i915 code along the lines of Linus' current
version. I'll post those if this patch looks acceptable.
From e3f633dcb36889fa85ea06cca339072df3c44ae0 Mon Sep 17 00:00:00 2001
From: Keith Packard [EMAIL PROTECTED]
Date: Thu, 23 Oct 2008 11:53:45 -0700
Subject: [PATCH] Add kmap_atomic_prot_pfn
kmap_atomic_prot_pfn is a mixture of kmap_atomic_prot and kmap_atomic_pfn,
accepting both a pfn instead of a page and an explicit protection value.
Signed-off-by: Keith Packard [EMAIL PROTECTED]
---
arch/x86/mm/highmem_32.c | 19 +++
include/asm-x86/highmem.h |1 +
include/linux/highmem.h |1 +
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c
index bcc079c..91ae5e8 100644
--- a/arch/x86/mm/highmem_32.c
+++ b/arch/x86/mm/highmem_32.c
@@ -139,6 +139,25 @@ void *kmap_atomic_pfn(unsigned long pfn, enum km_type
type)
}
EXPORT_SYMBOL_GPL(kmap_atomic_pfn); /* temporarily in use by i915 GEM until
vmap */
+/* This is the same as kmap_atomic_prot() but can map memory that doesn't
+ * have a struct page associated with it.
+ */
+void *kmap_atomic_prot_pfn(unsigned long pfn, enum km_type type, pgprot_t
prot)
+{
+ enum fixed_addresses idx;
+ unsigned long vaddr;
+
+ pagefault_disable();
+
+ idx = type + KM_TYPE_NR*smp_processor_id();
+ vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
+ set_pte(kmap_pte-idx, pfn_pte(pfn, prot));
+ arch_flush_lazy_mmu_mode();
+
+ return (void*) vaddr;
+}
+EXPORT_SYMBOL_GPL(kmap_atomic_prot_pfn); /* temporarily in use by i915 GEM
until vmap */
I guess one could reimplemenet kmap_atomic_pfn() to call this. Sometime.
struct page *kmap_atomic_to_page(void *ptr)
{
unsigned long idx, vaddr = (unsigned long)ptr;
diff --git a/include/asm-x86/highmem.h b/include/asm-x86/highmem.h
index bc3f6a2..a1f8f8c 100644
--- a/include/asm-x86/highmem.h
+++ b/include/asm-x86/highmem.h
@@ -66,6 +66,7 @@ void *kmap_atomic_prot(struct page *page, enum km_type
type, pgprot_t prot);
void *kmap_atomic(struct page *page, enum km_type type);
void kunmap_atomic(void *kvaddr, enum km_type type);
void *kmap_atomic_pfn(unsigned long pfn, enum km_type type);
+void *kmap_atomic_prot_pfn(unsigned long pfn, enum km_type type, pgprot_t
prot);
Given that all highmem-implementing archtiectures must use the same
declaration here, we might as well put it into include/linux/highmem.h.
Although that goes against current mistakes^Wcode.
Does powerpc32 still implement highmem? It seems that way. You broke
it, no?
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] rate limit drm:radeon_cp_idle/reset errors
On Sat, 6 Sep 2008 11:19:19 +0200 Roberto Oppedisano [EMAIL PROTECTED] wrote: When switching from kwin composite wm (KDE 4.1) to compiz I often hit the following error: Sep 6 10:24:31 poppero1 kernel: [ 186.138203] [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.138568] [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner f726bc80 f68f6840 probably due to broken X drivers/apps; after hitting this the error my laptop (hp nx7010) is totally unresponsitive to keyboard/mouse, also if it can be shut down via the power button: Sep 6 10:24:59 poppero1 powersave-wm_shutdown[4843]: DIAG: Process script for event button.power ID 10 Sep 6 10:24:59 poppero1 powersave-wm_shutdown[4843]: INFO: Event: BUTTON_POWER occured. Sep 6 10:24:59 poppero1 powersave-wm_shutdown[4843]: INFO: Parameters: Event - button.power; Current Active Scheme: scheme_performance - ACPI event line: button/power PWRF 0080 0001 Sep 6 10:25:00 poppero1 shutdown[4852]: shutting down for system halt ... Without the attached patch, which rate limits DRM_ERROR, the syslog is flooded by thuosands of messages; here's the output with the patch applied. Sep 6 10:24:31 poppero1 kernel: [ 186.138774] [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.138968] [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.139214] [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.139408] [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.139601] [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.139866] [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.140072] [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.140467] [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:36 poppero1 kernel: [ 191.139019] __ratelimit: 253431 callbacks suppressed Sep 6 10:24:36 poppero1 kernel: [ 191.139030] [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:36 poppero1 kernel: [ 191.139314] [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held 0 owner f726bc80 f68f6840 Also if it doesn't solve a bug I think it may still be worth applying it. Patch is against current git. Signed-off-by: Roberto Oppedisano [EMAIL PROTECTED] diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 1c1b13e..1107361 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -162,7 +162,8 @@ struct drm_device; * \param arg arguments */ #define DRM_ERROR(fmt, arg...) \ - printk(KERN_ERR [ DRM_NAME :%s] *ERROR* fmt , __func__ , ##arg) + if (printk_ratelimit()) \ + printk(KERN_ERR [ DRM_NAME :%s] *ERROR* fmt , __func__ , ##arg) /** * Memory error output. Which kernel version(s)? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] rate limit drm:radeon_cp_idle/reset errors
On Tue, 9 Sep 2008 09:37:32 +0200 Roberto Oppedisano [EMAIL PROTECTED] wrote: On Mon, Sep 08, 2008 at 09:08:36PM -0700, Andrew Morton wrote: On Sat, 6 Sep 2008 11:19:19 +0200 Roberto Oppedisano [EMAIL PROTECTED] wrote: When switching from kwin composite wm (KDE 4.1) to compiz I often hit the following error: Sep 6 10:24:31 poppero1 kernel: [ 186.138203] [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.138568] [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner f726bc80 f68f6840 probably due to broken X drivers/apps; after hitting this the error my laptop (hp nx7010) is totally unresponsitive to keyboard/mouse, also if it can be shut down via the power button: Sep 6 10:24:59 poppero1 powersave-wm_shutdown[4843]: DIAG: Process script for event button.power ID 10 Sep 6 10:24:59 poppero1 powersave-wm_shutdown[4843]: INFO: Event: BUTTON_POWER occured. Sep 6 10:24:59 poppero1 powersave-wm_shutdown[4843]: INFO: Parameters: Event - button.power; Current Active Scheme: scheme_performance - ACPI event line: button/power PWRF 0080 0001 Sep 6 10:25:00 poppero1 shutdown[4852]: shutting down for system halt ... Without the attached patch, which rate limits DRM_ERROR, the syslog is flooded by thuosands of messages; here's the output with the patch applied. Sep 6 10:24:31 poppero1 kernel: [ 186.138774] [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.138968] [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.139214] [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.139408] [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.139601] [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.139866] [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.140072] [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.140467] [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:36 poppero1 kernel: [ 191.139019] __ratelimit: 253431 callbacks suppressed Sep 6 10:24:36 poppero1 kernel: [ 191.139030] [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:36 poppero1 kernel: [ 191.139314] [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held 0 owner f726bc80 f68f6840 Also if it doesn't solve a bug I think it may still be worth applying it. Patch is against current git. Signed-off-by: Roberto Oppedisano [EMAIL PROTECTED] diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 1c1b13e..1107361 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -162,7 +162,8 @@ struct drm_device; * \param arg arguments */ #define DRM_ERROR(fmt, arg...) \ - printk(KERN_ERR [ DRM_NAME :%s] *ERROR* fmt , __func__ , ##arg) + if (printk_ratelimit()) \ + printk(KERN_ERR [ DRM_NAME :%s] *ERROR* fmt , __func__ , ##arg) /** * Memory error output. Which kernel version(s)? This is against vanilla current git. Linux poppero1 2.6.27-rc5-0-g7686ad5-dirty #1 PREEMPT Sun Sep 7 08:47:08 CEST 2008 i686 GNU/Linux Thanks. I should have asked earlier: was 2.6.26 OK? Any other kernels tested? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/1 repost #1] DRM: don't enable irqs in locking
On Mon, 28 Jul 2008 22:32:45 +0200 Thomas Hellstr__m [EMAIL PROTECTED] wrote: Dave Airlie wrote: On Fri, Jul 25, 2008 at 6:42 PM, Jiri Slaby [EMAIL PROTECTED] wrote: drm_lock_take(); and drm_lock_free(); are called from drm_locked_tasklet_func(); which disables interrupts when grabbing its spinlock. Don't allow these locking functions to re-enable interrupts when the tasklet expects them disabled. I.e. use spin_lock_irqsave instead of spin_lock_bh (with their unlock opposites). Hmm this has bounced through 2-3 variations.. Thomas any ideas what the final correct answer is? Dave. Hmm, Yes, this bug could occur, but the remedy is not to use spin_lock_irqsave() for lock_data::spinlock but to avoid calling drm_lock_take with the drm_device::tasklet_lock held with irqs disabled. I'll see if I can come up with a patch. The code in drivers/gpu/drm/drm_lock.c needs some serious help in the kerneldoc department. /** * Take the heavyweight lock. * * \param lock lock pointer. * \param context locking context. * \return one if the lock is held, or zero otherwise. * * Attempt to mark the lock as held by the given context, via the \p cmpxchg instruction. */ The /** leadin specifically introduces a kerneldoc-formatted comment. Yet that comment uses some strange home-made way of denoting function arguments. The comments could quite easily be converted to kerneldoc form, which would be the best thing to do here. While you're there, please reformat the comments (drm_idlelock_take(), mainly) to fit in 80-cols. The code carefully does this, but the block comments then go and ruin it all. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bugme-new] [Bug 10592] New: [old regression] performance drop for glx after vblank patch
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Fri, 2 May 2008 10:36:33 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=10592 Summary: [old regression] performance drop for glx after vblank patch Product: Drivers Version: 2.5 KernelVersion: 2.6.20-2.6.25 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Latest working kernel version:2.6.19 Earliest failing kernel version:2.6.20 Distribution:ubuntu 8.04 Hardware Environment:ASUS P5LD2-VM ( video i945g , Pentium D ) Software Environment: Problem Description: This is old regression. Tested with glxgears i get this results: v2.6.19 _1413.112_FPS_ v2.6.20 1280.060 FPS v2.6.22 1300.116 FPS v2.6.24 1205.895 FPS v2.6.25-git* 1226.967 FPS Thirst regression was pasebly introduced by vblank patch in i915: commit ee2fae03d68e702866a8661fbee7ff2f2f3754d7 Merge: e4ddc9c... f9841a8... Author: Linus Torvalds [EMAIL PROTECTED] Date: Wed Dec 20 23:59:07 2006 -0800 Merge branch 'drm-patches' of master.kernel.org:/pub/scm/linux/kernel/git/ai * 'drm-patches' of master.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2 drm: Stop defining pci_pretty_name drm: r128: comment aligment with drm git drm: make kernel context switch same as for drm git tree. drm: fixup comment header style drm: savage: compat fix from drm git. drm: Unify radeon offset checking. i915_vblank_tasklet: Try harder to avoid tearing. DRM: handle pci_enable_device failure drm: fix return value check I didn't get correct bisecting. Seems git-bisect can't correctly working with 2.9.19 tree or i did some thin really wrong, so i get this resoult: commit e1036502e5263851259d147771226161e5ccc85a Author: Nicolas Pitre [EMAIL PROTECTED] Date: Tue Dec 12 13:32:29 2006 -0500 [PATCH] remove config ordering/dependency between ucb1400-ts and sound subsy Commit 2d4ba4a3b9aef95d328d74a17ae84f8d658059e2 introduced a dependency that was never meant to exist when the ac97_bus.c module was created. Move ac97_bus.c up the directory hierarchy to make sure it is built when selected even if sound is configured out so things work as originally intended. Signed-off-by: Nicolas Pitre [EMAIL PROTECTED] Acked-by: Randy Dunlap [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] I assume that we're referring to commit 3188a24c256bae0ed93d81d82db1f1bb6060d727 Author: =?utf-8?q?Michel_D=C3=A4nzer?= [EMAIL PROTECTED] Date: Mon Dec 11 18:32:27 2006 +1100 i915_vblank_tasklet: Try harder to avoid tearing. Previously, if there were several buffer swaps scheduled for the same vertical blank, all but the first blit emitted stood a chance of exhibiting tearing. In order to avoid this, split the blits along slices of each output top to bottom. Signed-off-by: Dave Airlie [EMAIL PROTECTED] (and yup, that's how the Author: is recorded in git) Unfrortunately that patch doesn't trivially revert, so I can't send you a patch to test. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Prospects of DRM TTM making it into 2.6.24?
On Mon, 19 Nov 2007 21:53:05 + (GMT) Dave Airlie [EMAIL PROTECTED] wrote: What are the prospects of the DRM TTM changes making it into 2.6.24? I noticed that Andrew has them [1] in his mm tree... any chance of that getting pushed into Linus' tree for 2.6.24? No the merge window for 2.6.24 closed a few weeks ago. TTM wasn't in -mm for the 2.6.23 cycle as we hadn't finished the API stabilisation work in time. So I don't expect we'll see it before 2.6.25. I also have a few AGP changes I need to line up to support the chipset flushing work I've done to support TTM properly.. Did anything happen with that null-pointer deref I was hitting? From: Andrew Morton [EMAIL PROTECTED] [ 140.659360] BUG: unable to handle kernel NULL pointer dereference at virtual address 000c [ 140.659379] printing eip: f8c511b6 *pde = [ 140.659395] Oops: [#1] PREEMPT [ 140.659411] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed [ 140.659419] Modules linked in: i915 drm ipw2200 sonypi ipv6 autofs4 hidp l2cap bluetooth sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables acpi_cpufreq nvram ohci1394 ehci_hcd ieee1394 uhci_hcd joydev sg snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device sr_mod snd_pcm_oss cdrom snd_mixer_oss snd_pcm snd_timer i2c_i801 piix pcspkr generic snd ieee80211 soundcore ieee80211_crypt i2c_core snd_page_alloc button ext3 jbd ide_disk ide_core [ 140.659677] [ 140.659685] Pid: 3525, comm: glxgears Not tainted (2.6.24-rc2-mm1 #2) [ 140.659693] EIP: 0060:[f8c511b6] EFLAGS: 00010046 CPU: 0 [ 140.659725] EIP is at drm_fence_flush_old+0x3d/0xf4 [drm] [ 140.659731] EAX: EBX: f6240468 ECX: 0282 EDX: [ 140.659738] ESI: 0002 EDI: 0002 EBP: e8c33ec8 ESP: e8c33ea8 [ 140.659745] DS: 007b ES: 007b FS: GS: 0033 SS: 0068 [ 140.659752] Process glxgears (pid: 3525, ti=E8C32000 task=F113E170 task.ti=E8C32000) [ 140.659758] Stack: f624 f624044c f13919a0 f62690b8 f737b200 08be829c 000176b8 [ 140.659803]e8c33f1c f8dbdc76 0013 f1391cc0 f624 f737b200 f8c6d898 0001 [ 140.659850]0001 f737b200 f8e4 0001 0013 f737b200 08be8250 [ 140.659896] Call Trace: [ 140.659906] [c0104cec] show_trace_log_lvl+0x12/0x25 [ 140.659921] [c0104d8b] show_stack_log_lvl+0x8c/0x9e [ 140.659932] [c0104e27] show_registers+0x8a/0x1c0 [ 140.659944] [c010504b] die+0xee/0x1c4 [ 140.659954] [c0116a2c] do_page_fault+0x405/0x4e1 [ 140.659966] [c031fa22] error_code+0x6a/0x70 [ 140.659979] [f8dbdc76] i915_cmdbuffer+0x3a4/0x3e8 [i915] [ 140.659997] [f8c4a73c] drm_ioctl+0x1ac/0x228 [drm] [ 140.660028] [c0179bca] vfs_ioctl+0x4e/0x67 [ 140.660041] [c0179e45] do_vfs_ioctl+0x262/0x279 [ 140.660053] [c0179e9c] sys_ioctl+0x40/0x5c [ 140.660064] [c0103da2] syscall_call+0x7/0xb [ 140.660165] === [ 140.660170] INFO: lockdep is turned off. Cc: Dave Airlie [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/char/drm/drm_fence.c |3 +++ 1 file changed, 3 insertions(+) diff -puN drivers/char/drm/drm_fence.c~git-drm-oops-fix drivers/char/drm/drm_fence.c --- a/drivers/char/drm/drm_fence.c~git-drm-oops-fix +++ a/drivers/char/drm/drm_fence.c @@ -305,6 +305,9 @@ void drm_fence_flush_old(struct drm_devi struct drm_fence_object *fence; uint32_t diff; + if (!driver) + return; + write_lock_irqsave(fm-lock, flags); old_sequence = (sequence - driver-flush_diff) driver-sequence_mask; diff = (old_sequence - fc-last_exe_flush) driver-sequence_mask; _ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH series] DRM memory manager core
On Mon, 5 Nov 2007 06:29:26 + (GMT) Dave Airlie [EMAIL PROTECTED] wrote: These patches are the first set of patches containing the core components of the DRI memory manger from Tungsten Graphics. Something in your tree makes my i915-based Vaio oops when running glxgears: [ 140.659360] BUG: unable to handle kernel NULL pointer dereference at virtual address 000c [ 140.659379] printing eip: f8c511b6 *pde = [ 140.659395] Oops: [#1] PREEMPT [ 140.659411] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed [ 140.659419] Modules linked in: i915 drm ipw2200 sonypi ipv6 autofs4 hidp l2cap bluetooth sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables acpi_cpufreq nvram ohci1394 ehci_hcd ieee1394 uhci_hcd joydev sg snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device sr_mod snd_pcm_oss cdrom snd_mixer_oss snd_pcm snd_timer i2c_i801 piix pcspkr generic snd ieee80211 soundcore ieee80211_crypt i2c_core snd_page_alloc button ext3 jbd ide_disk ide_core [ 140.659677] [ 140.659685] Pid: 3525, comm: glxgears Not tainted (2.6.24-rc2-mm1 #2) [ 140.659693] EIP: 0060:[f8c511b6] EFLAGS: 00010046 CPU: 0 [ 140.659725] EIP is at drm_fence_flush_old+0x3d/0xf4 [drm] [ 140.659731] EAX: EBX: f6240468 ECX: 0282 EDX: [ 140.659738] ESI: 0002 EDI: 0002 EBP: e8c33ec8 ESP: e8c33ea8 [ 140.659745] DS: 007b ES: 007b FS: GS: 0033 SS: 0068 [ 140.659752] Process glxgears (pid: 3525, ti=E8C32000 task=F113E170 task.ti=E8C32000) [ 140.659758] Stack: f624 f624044c f13919a0 f62690b8 f737b200 08be829c 000176b8 [ 140.659803]e8c33f1c f8dbdc76 0013 f1391cc0 f624 f737b200 f8c6d898 0001 [ 140.659850]0001 f737b200 f8e4 0001 0013 f737b200 08be8250 [ 140.659896] Call Trace: [ 140.659906] [c0104cec] show_trace_log_lvl+0x12/0x25 [ 140.659921] [c0104d8b] show_stack_log_lvl+0x8c/0x9e [ 140.659932] [c0104e27] show_registers+0x8a/0x1c0 [ 140.659944] [c010504b] die+0xee/0x1c4 [ 140.659954] [c0116a2c] do_page_fault+0x405/0x4e1 [ 140.659966] [c031fa22] error_code+0x6a/0x70 [ 140.659979] [f8dbdc76] i915_cmdbuffer+0x3a4/0x3e8 [i915] [ 140.659997] [f8c4a73c] drm_ioctl+0x1ac/0x228 [drm] [ 140.660028] [c0179bca] vfs_ioctl+0x4e/0x67 [ 140.660041] [c0179e45] do_vfs_ioctl+0x262/0x279 [ 140.660053] [c0179e9c] sys_ioctl+0x40/0x5c [ 140.660064] [c0103da2] syscall_call+0x7/0xb [ 140.660165] === [ 140.660170] INFO: lockdep is turned off. Pulled yesterday, head is GIT 1d9e76b53ce8ff0b15b43b679801226add747d4e git+ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git#drm-mm commit Author: Dave Airlie [EMAIL PROTECTED] Date: Mon Nov 5 16:59:20 2007 +1000 drm/ttm: fix build with AGP disabled This: --- a/drivers/char/drm/drm_fence.c~a +++ a/drivers/char/drm/drm_fence.c @@ -305,6 +305,9 @@ void drm_fence_flush_old(struct drm_devi struct drm_fence_object *fence; uint32_t diff; + if (!driver) + return; + write_lock_irqsave(fm-lock, flags); old_sequence = (sequence - driver-flush_diff) driver-sequence_mask; diff = (old_sequence - fc-last_exe_flush) driver-sequence_mask; _ stops the oops and gets glxgears working OK, so I'll be able to include git-drm.patch in rc2-mm1, hopefully in a couple of hours from now. Hopefully this bug won't affect other drivers.. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
On Sun, 09 Sep 2007 13:44:56 +0200 Jiri Slaby [EMAIL PROTECTED] wrote: On 08/28/2007 01:41 PM, Jiri Slaby wrote: Does this went through to your boxes? Any progress, clue, idea? Jiri Slaby napsal(a): Andrew Morton napsal(a): ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/ Hi, I've found a regression against 2.6.23-rc2-mm2. X server shutdown freezes (untainted) kernel hardly. Nothing on netconsole, X output follows: X Window System Version 1.3.0 Release Date: 19 April 2007 X Protocol Version 11, Revision 0, Release 1.3 Build Operating System: Fedora Core 7 Red Hat, Inc. Current Operating System: Linux bellona 2.6.23-rc3-mm1 #315 SMP Wed Aug 22 21:43:06 CEST 2007 i686 Build Date: 11 June 2007 Build ID: xorg-x11-server 1.3.0.0-9.fc7 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun Aug 26 14:22:43 2007 (==) Using config file: /etc/X11/xorg.conf (WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found (**) RADEON(0): RADEONPreInit (II) Module already built-in (II) Module already built-in (II) Module already built-in (**) RADEON(0): RADEONScreenInit f000 0 (**) RADEON(0): Map: 0xf000, 0x0400 (**) RADEON(0): RADEONSave (**) RADEON(0): RADEONSaveMode(0x8240870) (**) RADEON(0): Read: 0x000c 0x00030065 0x (**) RADEON(0): Read: rd=12, fd=101, pd=3 (**) RADEON(0): RADEONSaveMode returns 0x8240870 (**) RADEON(0): DRI New memory map param (**) RADEON(0): RADEONInitMemoryMap() : (**) RADEON(0): mem_size : 0x0400 (**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffc0 (**) RADEON(0): RADEONModeInit() 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V (**) RADEON(0): Pitch = 10485920 bytes (virtualX = 1280, displayWidth = 1280) (**) RADEON(0): dc=10800, of=21600, fd=96, pd=2 (**) RADEON(0): RADEONInit returns 0x8241220 (**) RADEON(0): RADEONRestoreMode() (**) RADEON(0): RADEONRestoreMode(0x8241220) (**) RADEON(0): RADEONRestoreMemMapRegisters() : (**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffc0 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. (**) RADEON(0): Programming CRTC1, offset: 0x (**) RADEON(0): Wrote: 0x000c 0x00010060 0x (0xa400) (**) RADEON(0): Wrote: rd=12, fd=96, pd=1 (**) RADEON(0): GRPH_BUFFER_CNTL from 20205c5c to 20125c5c (**) RADEON(0): RADEONSaveScreen(0) (**) RADEON(0): Setting up initial surfaces (**) RADEON(0): Initializing fb layer (**) RADEON(0): Setting up accel memmap (**) RADEON(0): Initializing backing store (**) RADEON(0): DRI Finishing init ! (**) RADEON(0): EngineRestore (32/32) (**) RADEON(0): GRPH_BUFFER_CNTL from 20205c5c to 20125c5c (**) RADEON(0): Setting up final surfaces (**) RADEON(0): Initializing Acceleration (**) RADEON(0): EngineInit (32/32) (**) RADEON(0): Pitch for acceleration = 160 (**) RADEON(0): EngineRestore (32/32) (**) RADEON(0): Initializing DPMS (**) RADEON(0): Initializing Cursor (**) RADEON(0): Initializing color map (**) RADEON(0): Initializing DGA (**) RADEON(0): Initializing Xv (**) RADEON(0): RADEONScreenInit finished (**) RADEON(0): RADEONSaveScreen(2) (**) RADEON(0): RADEONCloseScreen (**) RADEON(0): RADEONDRIStop (**) RADEON(0): EngineRestore (32/32) (**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0) (**) RADEON(0): RADEONRestore (**) RADEON(0): RADEONRestoreMode() (**) RADEON(0): RADEONRestoreMode(0x8240870) (**) RADEON(0): RADEONRestoreMemMapRegisters() : (**) RADEON(0): MC_FB_LOCATION : 0x1fff (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. (**) RADEON(0): Programming CRTC1, offset: 0x (**) RADEON(0): Wrote: 0x000c 0x00030065 0x (0xa400) (**) RADEON(0): Wrote: rd=12, fd=101, pd=3 (**) RADEON(0): Disposing accel... (**) RADEON(0): Disposing cusor info (**) RADEON(0): Disposing DGA (**) RADEON(0): Unmapping memory (**) RADEON(0): RADEONDRICloseScreen the only difference is, that 2.6.23-rc2-mm2 writes further FreeFontPath: FPE /usr/share/X11
Re: [patch 2/2] Updates to VIA DRI
On Sat, 27 Jan 2007 09:01:36 +0100 Thomas Hellström [EMAIL PROTECTED] wrote: This patch clearly breaks the via drm since the video headers are removed, and might also brake Mesa / DDX since the HC_REG_TRANS_SPACE define is removed. Why? (The header is used in userspace as well). Has anybody compiled DRM / Mesa / DDX with the resulting header? The VIDEO headers are used in via_verifier.c. Apart from that, most changes seem cosmetic so I have nothing against them going in. In particular the license change should definitely go in. I had a few build errors and didn't have time to fix them, so I ended up dropping the patches. As I said, I'd appreciate it if someone could take ownership of them and finish them off please. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] use printk_ratelimit() inside DRM_DEBUG
On Wed, 1 Nov 2006 10:50:51 -0300
Glauber de Oliveira Costa [EMAIL PROTECTED] wrote:
the DRM_DEBUG macro can be called within functions very oftenly
triggered, thus generating lots of message load and potentially
compromising system
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
--
Glauber de Oliveira Costa
Red Hat Inc.
Free as in Freedom
[drm_debug.patch text/plain (444B)]
--- linux-2.6.18.x86_64/drivers/char/drm/drmP.h.orig 2006-11-01
08:00:18.0 -0500
+++ linux-2.6.18.x86_64/drivers/char/drm/drmP.h 2006-11-01
08:06:27.0 -0500
@@ -185,7 +185,7 @@
#if DRM_DEBUG_CODE
#define DRM_DEBUG(fmt, arg...)
\
do {\
- if ( drm_debug )\
+ if ( drm_debug printk_ratelimit() ) \
printk(KERN_DEBUG \
[ DRM_NAME :%s] fmt , \
__FUNCTION__ , ##arg); \
DRM_DEBUG() should be disabled in production code, and enabled only when
developers are developing stuff. In the latter case, the developer wants
to see all the messages.
IOW, don't load the drm module with the `debug' parameter.
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm bugs hopefully fixed but there might still be one..
Dave Airlie [EMAIL PROTECTED] wrote: I've put a couple of patches into my drm-2.6 tree that hopefully fix up the multi-bridge on i915 and the XFree86 4.3 issue.. Andrew can you drop the two patches in your tree.. the one from Brice and the one I attached to the bug? you'll get conflicts anyway I'm sure. I had to modify Brices one as it didn't look safe to me in all cases.. I think their might be one left, but I think it only seems to be on non-intel AGP system, as in my system works fine for a combination of cards and X releases ... anyone with a VIA chipset and Radeon graphics card or r128 card.. testing the next -mm would help me a lot.. argh, I just uploaded -mm2, but haven't announced it yet. I'll resync with your -bk. --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm bugs hopefully fixed but there might still be one..
cliff white [EMAIL PROTECTED] wrote: Okay, i have a iBook G4, with radeon, with 2.6.12-rc1-mm2, i'm getting the following OOPS on boot. Please try reverting agp-make-some-code-static.patch (Dunno why that would fix an oops, but apparently it does). --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm bugs hopefully fixed but there might still be one..
cliff white [EMAIL PROTECTED] wrote: -extern struct agp_bridge_data *(*agp_find_bridge)(struct pci_dev *); - Oh crap, so the compiler decided that agp_find_bridge() was a function and decided to jump to it, rather than reading from it and doing an indirect jump. Yup, that'll crash it. Sorry about that. This is another reason why doing the old-style (*agp_find_bridge)(...); is better than doing the new-style agp_find_bridge(...); The former case won't even compile, and is more readable. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm lockups since 2.6.11-bk2
Jesse Barnes [EMAIL PROTECTED] wrote:
I'd be happy to test and fix things, but the page table walker patches broke
ia64... Once that's cleared up I can go digging.
We're hoping that davem's fix (committed yesterday) fixed that.
ChangeSet 1.2181.1.2, 2005/03/14 21:16:17-08:00, [EMAIL PROTECTED]
[MM]: Restore pgd_index() iteration to clear_page_range().
Otherwise ia64 and sparc64 explode with the new ptwalk
iterators. The pgd level stuff does not handle virtual
address space holes (sparc64) and region based PGD indexing
(ia64) properly. It only matters in functions like
clear_page_range() which potentially walk over more than
a single VMA worth of address space.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
memory.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff -Nru a/mm/memory.c b/mm/memory.c
--- a/mm/memory.c 2005-03-15 00:06:50 -08:00
+++ b/mm/memory.c 2005-03-15 00:06:50 -08:00
@@ -182,15 +182,19 @@
unsigned long addr, unsigned long end)
{
pgd_t *pgd;
- unsigned long next;
+ unsigned long i, next;
pgd = pgd_offset(tlb-mm, addr);
- do {
+ for (i = pgd_index(addr); i = pgd_index(end-1); i++) {
next = pgd_addr_end(addr, end);
if (pgd_none_or_clear_bad(pgd))
continue;
clear_pud_range(tlb, pgd, addr, next);
- } while (pgd++, addr = next, addr != end);
+ pgd++;
+ addr = next;
+ if (addr == end)
+ break;
+ }
}
pte_t fastcall * pte_alloc_map(struct mm_struct *mm, pmd_t *pmd, unsigned long
address)
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm lockups since 2.6.11-bk2
Jesse Barnes [EMAIL PROTECTED] wrote: We're hoping that davem's fix (committed yesterday) fixed that. ChangeSet 1.2181.1.2, 2005/03/14 21:16:17-08:00, [EMAIL PROTECTED] [MM]: Restore pgd_index() iteration to clear_page_range(). Yep, seems to have worked (at least my system boots). It causes ppc64 to oops unpleasantly so we're not quite there yet. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [patch] Trying to get DRM up to date in 2.6
Dave Airlie [EMAIL PROTECTED] wrote: In a first attempt to bring the DRM in 2.6 in line with the latest developments in DRM CVS, I'm going to try and split the latest DRM stuff up into patches and submit them, Thanks. I've setup a temporary BK repo at http://freedesktop.org:1234/drm-2.6/ Yes, that works. Anything which you put into that bk tree will automagically appear in my test kernels. When we're happy with it you can ask Linus to merge it into the top-level tree. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRM reorganization
Ian Romanick [EMAIL PROTECTED] wrote: We're looking at reorganizing the way DRM drivers are maintained. Currently, the DRM kernel code lives deep in a subdirectory of the DRI tree (which is a partial copy of the XFree86 tree). We plan to move it up to its own module at the top level. That should make it *much* easier for people that want to do things with the DRM but don't want all the rest of X (i.e., DRI w/DirectFB, etc.). When we do this move, we're open to the possibility of reorganizing the file structure. What can we do to make it easier for kernel release maintainers to merge changes into their trees? - Make sure that the files in the main kernel distribution are up to date. - Prepare a shell script which does all the relevant file moves, send to Linus, along with a diff which fixes up Kconfig and Makefiles. - Start patching the files in their new locations. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRM reorganization
Ian Romanick [EMAIL PROTECTED] wrote: When we do this move, we're open to the possibility of reorganizing the file structure. What can we do to make it easier for kernel release maintainers to merge changes into their trees? - Make sure that the files in the main kernel distribution are up to date. - Prepare a shell script which does all the relevant file moves, send to Linus, along with a diff which fixes up Kconfig and Makefiles. - Start patching the files in their new locations. I'm not 100% sure what you mean. Right now the files in our CVS are split between two directories. There's a common directory, which is used on both Linux BSD, and a Linux-specific directory. Our intention is to shift around where some of the files are in our CVS. I don't think we intend to move where things are in the Linux source tree. That's part of why I'm asking. From talking to Linus in the past, I know that merging in changes is a PITA due to our funky directory structure. I'd like to make that easier. :) Oh. So what was the question again? As far as I know, there's nobody in DRI-land who actually prepares and sends patches. Fixing that would be a good first step ;) I've had a 130k DRM patch in -mm since February 8th. Presumably it's out of date. As far as I know nobody is pushing more recent patches upstream. What's the process here, and who should I be dealing with? Thanks. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fw: [Bugme-new] [Bug 1940] New: System hang on resume if DRI is enabled
Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2004-01-23 at 00:49, Andrew Morton wrote: Are any of the DRI developers watching the drivers_video-dri account on kernel bugzilla? It'd probably be a good idea to direct those bugs to this list. I guess I need to create an account for that? Yes please. There are very few of them. bugme.kernel.org. You mean bugzilla.kernel.org, right? yup. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fw: [Bugme-new] [Bug 1940] New: System hang on resume if DRI is enabled
Ian Romanick [EMAIL PROTECTED] wrote: ATI's fglrx driver is closed-source. There's nothing we can do about it. Ah. Thanks. Wish they were all that easy ;) --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Fw: [Bugme-new] [Bug 1940] New: System hang on resume if DRI is enabled
Are any of the DRI developers watching the drivers_video-dri account on kernel bugzilla? bugme.kernel.org. Begin forwarded message: Date: Thu, 22 Jan 2004 13:28:22 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 1940] New: System hang on resume if DRI is enabled http://bugme.osdl.org/show_bug.cgi?id=1940 Summary: System hang on resume if DRI is enabled Kernel Version: 2.6.1 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Distribution: SuSE 9.0 Hardware Environment: IBM Thinkpad R50P Software Environment: Using fglrx driver by ATI Problem Description: If no_dri = no in XF86Config-4, and fglrx driver is loaded - system hangs on resume. If fglrx driver is loaded, and DRI disabled, resume works fine. Steps to reproduce: 1. Use DRI option in XF86config-4 2. Load fglrx driver from ATI 3. startx 4. apm --suspend 5. resume --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Bugme-new] [Bug 1811] New: Error during compile 2.6.1-rc2-mm1
Andi Kleen [EMAIL PROTECTED] wrote: I know what happened. 2.6.1-rc2-mm1 added the `-msoft-float' compiler option. So what used to be inline 387 instructions became fp library calls. So it's not an _urgent_ problem, and I can probably just drop the -msoft-float patch from my tree. But it should be addressed. Here's the matching patch from the SuSE 2.4 tree which also compiles with soft-float. No i haven't even checked if it applies to 2.6. But maybe it will help somebody fix the 2.6 driver. It does apply. I'll merge it for testing but would prefer that the upstream developers review it, integrate it and send it back to us please. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: 2.6.1-rc2-mm1: drm/sis_mm.c compile error
Adrian Bunk [EMAIL PROTECTED] wrote: drivers/char/drm/sis_mm.c:37:25: linux/sisfb.h: No such file or directory drivers/char/drm/sis_mm.c: In function `sis_fb_alloc': drivers/char/drm/sis_mm.c:92: error: storage size of `req' isn't known drivers/char/drm/sis_mm.c:98: warning: implicit declaration of function `sis_malloc' drivers/char/drm/sis_mm.c:105: warning: implicit declaration of function `sis_free' drivers/char/drm/sis_mm.c:92: warning: unused variable `req' Yes. The video header files were moved. I assume this code is also designed to build under 2.4. If so, something like this is the way to go: --- drivers/char/drm/sis_mm.c |4 1 files changed, 4 insertions(+) diff -puN drivers/char/drm/sis_mm.c~drm-include-fix drivers/char/drm/sis_mm.c --- 25/drivers/char/drm/sis_mm.c~drm-include-fix2004-01-08 10:14:41.0 -0800 +++ 25-akpm/drivers/char/drm/sis_mm.c 2004-01-08 10:16:49.0 -0800 @@ -34,8 +34,12 @@ #include sis_drv.h #include sis_ds.h #if defined(__linux__) defined(CONFIG_FB_SIS) +#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0) +#include video/sisfb.h +#else #include linux/sisfb.h #endif +#endif #define MAX_CONTEXT 100 #define VIDEO_TYPE 0 _ --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Bugme-new] [Bug 1811] New: Error during compile 2.6.1-rc2-mm1
Leandro Piccilli [EMAIL PROTECTED] wrote: CC drivers/video/sis/sis_main.o drivers/video/sis/sis_main.c: In function `sisfb_do_set_var': drivers/video/sis/sis_main.c:622: warning: unused variable `reg' CC drivers/video/sis/sis_accel.o . finishing with this errors: LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o(.text+0x9ae71): In function `sisfb_do_set_var': : undefined reference to `__floatsidf' Well sisfb_do_set_var() is using floating point. I guess it has been changed in the recent update so the compiler now has to actually emit FP library function calls. It would be best if that code could be reworked to use integer math. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Problems with the radeon 1.9.0 driver in 2.6.0-test9-mm2
Bradley Chapman [EMAIL PROTECTED] wrote: -extern const drm_agp_t agp_drm; +extern const drm_agp_t *drm_agp_p; #endif /* __KERNEL__ */ #endif /* _AGP_BACKEND_H */ This patch has fixed the bug introduced by the original module dependency fix in 2.6.0-test9-mm2. Sweet, thanks.. Has anyone actually tested the functionality which this patch is supposed to provide? That loading the DRM module magically triggers a load of AGP? Or is it the other way around? --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48
Dieter Nützel wrote:
Am Mittwoch, 20. November 2002 19:44 schrieb Alan Cox:
On Wed, 2002-11-20 at 17:30, Dieter Nützel wrote:
System lookup immediately when I try to start ipers, isosurf or
switch the screen. Sadly even when I try the Mesa-4-1-branch with
2.5.47-mm1 or 2.4.19-ck5 (radeon.o 1.6.0).
Are you using scsi - any measuable amount of scsi I/O also hangs 2.5.48
8(
Here's James's fix:
drivers/scsi/scsi_lib.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
--- 25/drivers/scsi/scsi_lib.c~jejb-scsi-fixWed Nov 20 09:45:08 2002
+++ 25-akpm/drivers/scsi/scsi_lib.c Wed Nov 20 09:45:08 2002
@@ -1021,10 +1021,11 @@ void scsi_request_fn(request_queue_t * q
break;
if(!req) {
- /* can happen if the prep fails
-* FIXME: elv_next_request() should be plugging the
-* queue */
- blk_plug_device(q);
+ /* If the device is busy, a returning I/O
+* will restart the queue. Otherwise, we have
+* to plug the queue */
+ if(SDpnt-device_busy == 0)
+ blk_plug_device(q);
break;
}
Yes, didn't have ATA at all.
Only if some friends have problems with bad Win disks (bad sectors etc. =
dd_rescue)...;-)
No hangs but slower.
I'll have a second look at it.
2.5.48-mm1 have additional IO scheduler hacks.
It has a different fix to the scsi thing.
Some progress with KDE (3.1 beta/rc) and shared pagetables.
Normal startup hangs but I had some luck with running the KDE progs by hand.
More about it in another post.
So that we can take DRI-Devel out.
(wonders what this email is really about. oh well)
---
This sf.net email is sponsored by:
Battle your brains against the best in the Thawte Crypto
Challenge. Be the first to crack the code - register now:
http://www.gothawte.com/rd521.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
