[Bug 25799] New: (EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI. with xf86-video-ati-6.12.4
http://bugs.freedesktop.org/show_bug.cgi?id=25799 Summary: (EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI. with xf86-video-ati-6.12.4 Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: leoci...@gmx.de Everytime I start X, drm gets disabled, here is a snippet from /var/log/Xorg.0.log: (II) RADEON(0): [drm] installed DRM signal handler (WW) RADEON(0): [agp] AGP not available (EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI. (II) RADEON(0): [agp] You may want to make sure the agpgart kernel module is loaded before the radeon kernel module. (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xf802e000 at 0xb7183000 (II) RADEON(0): [drm] Closed DRM master. (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xe7ffe000 0x1fff (II) RADEON(0): MC_AGP_LOCATION : 0xffc0 (==) RADEON(0): Backing store disabled (WW) RADEON(0): Direct rendering disabled I am on gentoo-sources 2.6.31-r6 with xf86-video-ati-6.12.4 and xorg-server-1.6.5-r1. I have entered the appropriate kernel modules in a correct order in /etc/modules.autoload.d/kernel-2.6, to no avail. Manually removing and reloading modules does not work either. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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: drm/radeon/kms: pm: single frame corruptions on reclocking
W dniu 26 grudnia 2009 02:46 użytkownik Rafał Miłecki zaj...@gmail.com napisał: There are some my experiments with engine. Reclocking between: 1) 110MHz and 680MHz - 1 corrupted frame on every reclock 2) 200MHz and 680MHz - 1 corrupted frame on almost every reclock 3) 250MHz and 680MHz - no corruptions 4) 340MHz and 680MHz - no corruptions 5) 630MHz and 680MHz - no corruptions Done more testing. Reclocking between: 1) 110MHz and 250MHz - 1 corrupted frame on every reclock 2) 110MHz and 130MHz - 1 corrupted frame on every reclock I don't have more ideas :| -- Rafał -- 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
[Bug 25799] (EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI. with xf86-video-ati-6.12.4
http://bugs.freedesktop.org/show_bug.cgi?id=25799 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Comment #1 from Michel Dänzer mic...@daenzer.net 2009-12-26 03:11:22 PST --- It's a kernel issue, the X driver can't do anything about it. If it's a newer card with a PCIe based GPU, Option BusType PCIE may be a feasible workaround. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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: drm/radeon/kms: pm: single frame corruptions on reclocking
On Sat, Dec 26, 2009 at 02:46:29AM +0100, Rafał Miłecki wrote: W dniu 24 grudnia 2009 08:19 użytkownik Michel Dänzer mic...@daenzer.net napisał: I suspect the delay is more likely due to the workqueue than the interrupt itself. Way back when I implemented DRI1 tear-free buffer swaps for i945, I had to use a tasklet to reliably do work within the vertical blank period. I can not use tasklet as I need to sleep in setting engine function (AtomBIOS command does it). First of all I converted Alex's code to take requested mode before handling IRQ. Unfortunately that didn't help. Then I've converted VBLANK sync from work queue to wait_event_interruptible_timeout and wake_up_interruptible (btw. code seems much cleaner). This also didn't help. There are some my experiments with engine. Reclocking between: 1) 110MHz and 680MHz - 1 corrupted frame on every reclock 2) 200MHz and 680MHz - 1 corrupted frame on almost every reclock 3) 250MHz and 680MHz - no corruptions 4) 340MHz and 680MHz - no corruptions 5) 630MHz and 680MHz - no corruptions Maybe it's just downclocking to very low 110MHz that shouldn't happen? My GPU works fine on this engine clock (no corruptions) but still maybe reclocking to so low value can not be performed without corruption? I don't think anymore it's timing related issue. -- Rafał What is the screen resolution ? Cheers, Jerome -- 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: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/26 Jerome Glisse gli...@freedesktop.org: What is the screen resolution ? It's 1600x900 panel driven by INTERNAL_KLDSCP_LVTMA. I guess you think about minimum clocks needed to drive my display, am I right? It could make sense if I would see general corruptions and not only at reclocking time. -- Rafał -- 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] drm/radeon/kms: add dynamic engine reclocking (V9)
2009/12/25 Rafał Miłecki zaj...@gmail.com: W dniu 24 grudnia 2009 23:19 użytkownik Luca Tettamanti kronos...@gmail.com napisał: 2009/12/24 Rafał Miłecki zaj...@gmail.com: W dniu 24 grudnia 2009 17:32 użytkownik Luca Tettamanti kronos...@gmail.com napisał: I think it would be safer to execute that code in the IH (or in a tasklet, which is guaranteed to run after the handler); the only problem I see is that atom_execute_table allocates some memory (ws? workspace?), but the GFP flag can be easily adjusted; the rest of the ops seem safe. What do you think? Thank you for commenting. Indeed we have problems with engine reclocking not happening right after VBLANK. The conversion to bh is pretty simple, and it blows up in a spectacular way :-) Aside from the locking (mutex) which has to be reworked, the show stopper is atom_op_delay, which wants to schedule. In my BIOS the biggest delays in SetEngineClock are 200us, so it would be possible to use udelay; not sure if the msec path could use the same treatment. I've read LDD3 ch07.pdf again and I can see why I've chosen workqueue. AFAIU tasklets are similar to timers but without execution time as param. It seems to be something like execute it really soon. Not really, they're part of other half of the interrupt processing; pending tasklets run in softirq, and they are guaranteed to be executed after processing the hw interrupt. That's fine but the problem is we can not sleep in tasklet handler (handlers has to be atomic). As you noticed we need to sleep in reclocking (AtomBIOS command does). Well, I've converted atom_op_delay to busy loop and the tasket does work. Locking with CP is missing though. I think solution may be sleeping in radeon_pm_idle_work_handler in place where we currently set: rdev-pm.vblank_callback = true;. We would sleep and ask IRQ code to wake us on VBLANK. Maybe this would be fast enough solution? Or do you have other, better idea? Just keep in mind that we do sleep in radeon_set_engine_clock. I don't think it would change much in term of latency. I'll follow the other thread ;-) Luca -- 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
[Bug 25490] kernel crash with 2.6.32, drm and kms enabled.
http://bugs.freedesktop.org/show_bug.cgi?id=25490 che...@kalri.org changed: What|Removed |Added CC||che...@kalri.org --- Comment #7 from che...@kalri.org 2009-12-26 07:13:18 PST --- I can confirm as well. I have had this happen with kernel 2.6.32 stable, and kernel 2.6.33-rc1 and 2.6.33-git unstable. Latest X, kms, and libdrm will lock up randomly. R600 chipset here, Radeon HD 3200 video. It doesn't matter what you are doing, it will happen in minutes to hours or within the day at the most. (In reply to comment #3) (In reply to comment #2) Your GPU just locks up but we don't have idea from logs what causes that. Did you do something specific when this has happened? Like some specific application usage, or starting video, or sth? I experience lock up on my 34xx (Sony VAIO) greatly reproducible by using JDownloader. Will debug that after our HDMI and PM issues will calm down. Maybe this will same fix for your case. By the way, could you try running JDownloader for some minutes? With having this on top, maximized. You just download it, unpack and use java -jar JDownloader.jar to start it. it happens on random times, usually, I use firefox and kdevelop 4. compositing is disabled, but the problem still persists. I haven't used jdownloader for quite a while, will try and report back. is there any way to produce a better log? will enabling kernel debug will help? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25490] kernel crash with 2.6.32, drm and kms enabled.
http://bugs.freedesktop.org/show_bug.cgi?id=25490 --- Comment #8 from dagg stompdagg...@yahoo.com 2009-12-26 09:50:35 PST --- if you disable kms, your system will probably not freeze. since I've disabled it (kernel wise) the system didn't froze even once. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25776] [regression] crash on loading radeon module on 2.6.33-rc1 vanilla
http://bugs.freedesktop.org/show_bug.cgi?id=25776 --- Comment #3 from Alex Deucher ag...@yahoo.com 2009-12-26 10:55:19 PST --- (In reply to comment #2) OK that's nice but from 2.6.32.2 after init gfx i have black screen and on 2.6.32-rc8 not. 2.6.32.2 is another issue. that's fixed with this patch: http://marc.info/?l=dri-develm=126137027403059w=2 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/26 Rafał Miłecki zaj...@gmail.com: W dniu 26 grudnia 2009 02:46 użytkownik Rafał Miłecki zaj...@gmail.com napisał: There are some my experiments with engine. Reclocking between: 1) 110MHz and 680MHz - 1 corrupted frame on every reclock 2) 200MHz and 680MHz - 1 corrupted frame on almost every reclock 3) 250MHz and 680MHz - no corruptions 4) 340MHz and 680MHz - no corruptions 5) 630MHz and 680MHz - no corruptions Done more testing. Reclocking between: 1) 110MHz and 250MHz - 1 corrupted frame on every reclock 2) 110MHz and 130MHz - 1 corrupted frame on every reclock I don't have more ideas :| It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Alex -- 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: drm/radeon/kms: pm: single frame corruptions on reclocking
W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher
alexdeuc...@gmail.com napisał:
It may be that the engine doesn't like to be reclocked while it's
running. Perhaps we should use the GUI idle interrupt rather than
vblanks to reclock the engine.
Could you say something more about GUI idle interrupt, please? What is
this, do we already have code for that?
I've tried following:
if (reclock_decision) {
mutex_lock(rdev-cp.mutex);
radeon_fence_wait_last(rdev);
wait_event_interruptible_timeout(...)
radeon_set_power_state(rdev);
mutex_unlock(rdev-cp.mutex);
}
but this didn't help. And of course it wouldn't be perfect solution
because we make engine stop receiving new tasks, not sure if this is
nice way.
--
Rafał
--
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
