[PULL] topic/core-stuff
> Usual pile of random drm patches all over. One i915 one in here for the > hdmi doubleclock stuff since I've put both of Clint's patches into this > branch. > > Rebased just now only to check what you've merged already, otherwise this > has been hanging out in -nightly for quite a while. I already merged the division fix and ww-mutex help change in -fixes so can you drop those. Dave.
[Bug 82588] X fails to start with linus-tip or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=82588 --- Comment #11 from jospezial --- (In reply to comment #10) > Please have a look, here: > > https://bugs.freedesktop.org/show_bug.cgi?id=83616 For me patch https://bugs.freedesktop.org/attachment.cgi?id=105904 does not help. But I think r600.c is not used for my chip. It is r100_ring_test that fails. I'm a bit confused, which files are related to my RS740 [Radeon 2100] (onboard graphic from 740G chipset) I have to find out, how I can debug that failing ring test and to see, why it fails. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/274e1422/attachment.html>
[Bug 73088] [HyperZ] Juniper (6770): Gone Home / Unigine Heaven 4.0 lock up system after several minutes of use
https://bugs.freedesktop.org/show_bug.cgi?id=73088 --- Comment #10 from appletorch at hotmail.com --- Unigine Heaven ran without issue. Gone home was giving me segfaults when trying to start it on my new installation so I wasn't able to test that. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/cb6f795d/attachment.html>
[Bug 83810] New: Blender Weight paint mode doesn't work with enabled VBOs.
https://bugs.freedesktop.org/show_bug.cgi?id=83810 Priority: medium Bug ID: 83810 Assignee: dri-devel at lists.freedesktop.org Summary: Blender Weight paint mode doesn't work with enabled VBOs. Severity: normal Classification: Unclassified OS: Linux (All) Reporter: sunweb at hotmail.ru Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/r600 Product: Mesa HD 5770, OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.3 Download and unpack Blender from here http://www.blender.org/download/ or install from your distrution repository. Exact steps to reproduce the error: 1) Open Blender and go to File -> User Preferences -> System OR press Ctrl+Alt+U and enable VBOs 2) Go to Edit mode(press Tab) on a default cube and for clear look for both problems(unable to paint and slowdowns) subdivide it atleast a few times(press W -> F6 -> Number of cuts 50*). 3) Go to Weight Paint mode(press Tab -> Ctrl+Tab) and make a stroke, you won't see anything painting and experience slowdowns. 4) Disable VBOs and repeat 2 and 3 steps and everything works and really fast then switch on VBOs again and your paint will disappear but turning off VBOs again will show the one you draw before. * depending on your GPU the number might be higher. For example on my GPU 20 cuts on a cube won't show any performance decrease with VBOs on thus i am using 50 for more clear look at performance problem. As described by many users VBOs should make everything faster not slower. And i've checked proprietary drivers VBOs work there but i have different troubles with them thus i am using the OSS one that has a very few non crucial broken features. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/0fe78016/attachment.html>
[Bug 83810] Blender Weight paint mode doesn't work with enabled VBOs.
https://bugs.freedesktop.org/show_bug.cgi?id=83810 --- Comment #1 from sunweb at hotmail.ru --- Sorry corection for step 4: 4) Disable VBOs(as shown in step 1) and and make a stroke everything works and really fast then switch on VBOs again and your paint will disappear but turning off VBOs again will show the one you draw before. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/e2abf70d/attachment.html>
[Bug 42960] Display does not work when resuming from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=42960 --- Comment #47 from reverber <1806whiteguard at gmail.com> --- With kernel 3.15 and later I got "diplay not working after suspend" again. But I find out how to work around. I had scrip on shortcut for KDE and this script made display to work. Command of script is "sleep 1; xset dpms force standby". -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/40d1432e/attachment.html>
3.7+ kernels and Radeon HD 4250 backlight
Hi!
drivers/gpu/drm/radeon/radeon_kns.c: static int radeon_info_ioctl(...)
...
value_ptr = (uint32_t *)((unsigned long)info->value);
// value_ptr = (uint32_t __user *)(info->value); // looks like more
correct for x86_64
...
if (copy_to_user(value_ptr, (char*)value, value_size)) {...
Why value_ptr is assumed to be lower 4 Gb?
Question on UAPI for fences
> Doing such combining and cleaning up fds as soon as they have been > passed on should keep each application's fd usage fairly small. Yeah, but this is exactly what we wanted to avoid internally because of the IOCTL overhead. And thinking more about it for our driver internal use we will definitely hit some limitations with the number of FDs in use and the overhead for creating and closing them. With the execution model we target for the long term we will need something like 10k fences per second or more. How about this: We use an identifier per client for the fence internally and when we need to somehow expose it to somebody else export it as sync point fd. Very similar to how we currently have GEM handles internally and when we need to expose them export a DMA_buf fd. Regards, Christian. Am 12.09.2014 um 18:38 schrieb John Harrison: > On Fri, Sep 12, 2014 at 05:58:09PM +0200, Christian K?nig wrote: > > pass in a list of fences to wait for before beginning a command > submission. > > The Android implementation has a mechanism for combining multiple sync > points into a brand new single sync pt. Thus APIs only ever need to > take in a single fd not a list of them. If the user wants an operation > to wait for multiple events to occur then it is up to them to request > the combined version first. They can then happily close the individual > fds that have been combined and only keep the one big one around. > Indeed, even that fd can be closed once it has been passed on to some > other API. > > Doing such combining and cleaning up fds as soon as they have been > passed on should keep each application's fd usage fairly small. > > > On 12/09/2014 17:08, Christian K?nig wrote: >>> As Daniel said using fd is most likely the way we want to do it but >>> this >>> remains vague. >> Separating the discussion if it should be an fd or not. Using an fd >> sounds fine to me in general, but I have some concerns as well. >> >> For example what was the maximum number of opened FDs per process >> again? Could that become a problem? etc... >> >> Please comment, >> Christian. >> >> Am 12.09.2014 um 18:03 schrieb Jerome Glisse: >>> On Fri, Sep 12, 2014 at 05:58:09PM +0200, Christian K?nig wrote: Am 12.09.2014 um 17:48 schrieb Jerome Glisse: > On Fri, Sep 12, 2014 at 05:42:57PM +0200, Christian K?nig wrote: >> Am 12.09.2014 um 17:33 schrieb Jerome Glisse: >>> On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote: On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse wrote: > On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote: >> On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter >> wrote: >>> On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian K?nig >>> wrote: Hello everyone, to allow concurrent buffer access by different engines beyond the multiple readers/single writer model that we currently use in radeon and other drivers we need some kind of synchonization object exposed to userspace. My initial patch set for this used (or rather abused) zero sized GEM buffers as fence handles. This is obviously isn't the best way of doing this (to much overhead, rather ugly etc...), Jerome commented on this accordingly. So what should a driver expose instead? Android sync points? Something else? >>> I think actually exposing the struct fence objects as a fd, >>> using android >>> syncpts (or at least something compatible to it) is the way >>> to go. Problem >>> is that it's super-hard to get the android guys out of >>> hiding for this :( >>> >>> Adding a bunch of people in the hopes that something sticks. >> More people. > Just to re-iterate, exposing such thing while still using > command stream > ioctl that use implicit synchronization is a waste and you can > only get > the lowest common denominator which is implicit > synchronization. So i do > not see the point of such api if you are not also adding a new > cs ioctl > with explicit contract that it does not do any kind of > synchronization > (it could be almost the exact same code modulo the do not wait > for > previous cmd to complete). Our thinking was to allow explicit sync from a single process, but implicitly sync between processes. >>> This is a BIG NAK if you are using the same ioctl as it would >>> mean you are >>> changing userspace API, well at least userspace expectation. >>> Adding a new >>> cs flag might do the trick but it should not be about >>> inter-process, or any >>> thing special, it's ju
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #101 from Maciej --- (In reply to comment #98) > > If you want complete usability on your hardware, you should just go windows > then, FWIW. This here is where Linux desktop issues start - You people drive new users away from this platform, so only devs are here who do not make software for human beings, so it's harder for new users to come here, which results in low market share, which results in lack of proper hardware support which results in even lower market share, good job. If not for Canonical or Valve there would be no Linux desktop at all, all You would be running Open Quake on top of fuckin' Gentoo or Arch with some useless (for average joe, not developer) tiling window manager. I'm using Linu.. wait, let me correct - I'm using Ubuntu because I like open source for various reasons, hacking the code is not one of them (I'm repeating myself I think, obviously You people can't read any form of human language - "it's not C, I don't understand!"). Also my card is from 2012, it's not even remotely new hardware, get your facts straight. Emil Velikov Not sure what difference would it make to file a bug at launchpad from where they will point me right here. Aren't all Mesa devs right here anyway? I'm seeking assistance from Mesa developers, which I heard are paid by AMD (those on AMD team) - which makes me their customer. I suppose this is wrong place to be a normal person, not a dev, so I'll stay away in the future and meanwhile jump ship to Nvidia camp, fuck You very much (Mesa is great, but Your attitude towards non-developers is terrible). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/d562a6b7/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #102 from Emil Velikov --- (In reply to comment #101) > Emil Velikov > > Not sure what difference would it make to file a bug at launchpad from where > they will point me right here. Aren't all Mesa devs right here anyway? I'm > seeking assistance from Mesa developers, which I heard are paid by AMD > (those on AMD team) - which makes me their customer. > Please try to settle for a moment and read the whole "development" vs "distribution" note. > I suppose this is wrong place to be a normal person, not a dev, so I'll stay > away in the future and meanwhile jump ship to Nvidia camp, fuck You very > much (Mesa is great, but Your attitude towards non-developers is terrible). > I never said nor hinted that this is the "wrong place for normal people". I feel that once you realise what I meant with "development vs distribution" you will understand that "our attitude" is not terrible. All developers ask is some clear steps in order to understand and fix the issue. Thanks -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/bf691df0/attachment.html>
[Bug 82588] X fails to start with linus-tip or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=82588 --- Comment #12 from Mike Lothian --- Created attachment 106218 --> https://bugs.freedesktop.org/attachment.cgi?id=106218&action=edit Dmesg Linus's Tip -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/c11193ae/attachment.html>
[Bug 82588] X fails to start with linus-tip or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=82588 --- Comment #13 from Mike Lothian --- Linus's tree still fails to start X - I've attached the latest output that shows some drm errors I can't get the drm-next tree to boot at all now -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/24c9e805/attachment-0001.html>
[PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change
The current drm-next misses Ville's original Patch 14/19, the one i
first objected, then objected to my objection. It is needed to avoid
actual regressions. Attached a trivially rebased (v2) of Ville's patch
to go on top of drm-next, also as tgz in case my e-mail client mangles
the patch again, because it's one of those "email hates me" weeks.
-mario
On 08/06/2014 01:49 PM, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> If we already have a timestamp for the current vblank counter, don't
> update it with a new timestmap. Small errors can creep in between two
> timestamp queries for the same vblank count, which could be confusing to
> userspace when it queries the timestamp for the same vblank sequence
> number twice.
>
> This problem gets exposed when the vblank disable timer is not used
> (or is set to expire quickly) and thus we can get multiple vblank
> disable<->enable transition during the same frame which would all
> attempt to update the timestamp with the latest estimate.
>
> Testcase: igt/kms_flip/flip-vs-expired-vblank
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/drm_irq.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index af33df1..0523f5b 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -106,6 +106,9 @@ static void drm_update_vblank_count(struct drm_device
> *dev, int crtc)
> DRM_DEBUG("enabling vblank interrupts on crtc %d, missed %d\n",
> crtc, diff);
>
> + if (diff == 0)
> + return;
> +
> /* Reinitialize corresponding vblank timestamp if high-precision query
>* available. Skip this step if query unsupported or failed. Will
>* reinitialize delayed at next vblank interrupt in that case.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-Don-t-update-vblank-timestamp-when-the-counter-d.patch
Type: text/x-patch
Size: 1862 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/154f5858/attachment.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-Don-t-update-vblank-timestamp-when-the-counter-d.patch.tar.gz
Type: application/gzip
Size: 1171 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/154f5858/attachment-0001.bin>
[Bug 42960] Display does not work when resuming from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=42960 --- Comment #48 from Alex Deucher --- (In reply to comment #47) > With kernel 3.15 and later I got "diplay not working after suspend" again. > But I find out how to work around. I had scrip on shortcut for KDE and this > script made display to work. Command of script is "sleep 1; xset dpms force > standby". Can you bisect? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/71bedc12/attachment.html>
[Bug 82588] X fails to start with linus-tip or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=82588 --- Comment #14 from Alex Deucher --- (In reply to comment #11) > (In reply to comment #10) > > Please have a look, here: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=83616 > > For me patch https://bugs.freedesktop.org/attachment.cgi?id=105904 does not > help. > But I think r600.c is not used for my chip. > It is r100_ring_test that fails. > I'm a bit confused, which files are related to my > RS740 [Radeon 2100] (onboard graphic from 740G chipset) As I said before in comment 8, I don't think your issue is the same as Mike's since your chips are very different generations. It could be nice if one of you could bisect. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/c5b90dea/attachment.html>
[Bug 82588] X fails to start with linus-tip or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=82588 --- Comment #15 from Mike Lothian --- I'm bisecting now -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/d4db379d/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #43 from Michael Mair-Keimberger --- FYI, while other games doesn't crash anymore with llvm-3.5/mesa-10.2.7 (painkiller, the cave, serious sam), br?tal legends horribly crash's my system with this versions. With older versions it just closes/crash's the game, but now it crash's the whole system and i always have to reset it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/c2b8567e/attachment.html>
Using a HD 4670 still possible?
Am 08.09.2014 03:41 schrieb "Michel D?nzer" : > > On 07.09.2014 01:01, Christoph Brill wrote: >> >> >> I'm currently trying to get a HD 4670 aka RV730 XT to work against X.org >> 1.16, xf86-video-ati 7.4.0 on a Linux 3.16.1. >> >> Can anyone tell me: Should this card be able to handle an average Gnome >> desktop? > > > Of course. > > > >> The problem was: 3D rendering did not work at all. >> >> Starting gdm lead to hanging Xorg. Calling glxgears on a twm session >> just rendered a black window, which stayed even if the process was >> killed by CTRL+C. I managed to get glxgears do do its job by setting >> "vblank_mode=0". >> >> I guessed my card does not like to play along with vsync at all. So I >> went ahead to disable vsyncing (tearing is still better than no display >> at all). Setting it globally in /etc/drirc seems to get glxgears running. >> >> Testing Xonotic on twm showed, that the card was now able to handle 3D. >> But: gdm still was extremely sluggish and eventually froze. Starting >> gnome-shell directly from startx gets me to the desktop, but any action >> freezes the process. >> >> Is there still hope for this card or should I get rid of it? > > > It sounds like there's a problem with interrupt processing on your system. Please provide the dmesg output. You might try disabling/enabling MSI to see if that works around the problem. Thank you so much for this hint! Booting using radeon.msi=0 finally brings the system into a usable state. The dmesg of a default boot (i.e. radeon.msi=-1) is available at http://pastebin.com/gS1xHYPc > > -- > Earthling Michel D?nzer| http://www.amd.com > Libre software enthusiast |Mesa and X developer -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/330e1ce2/attachment-0001.html>
[Bug 82588] X fails to start with linus-tip or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=82588 --- Comment #16 from Mike Lothian --- This looks bad: f2c6b0f452c3804496f55655fda28c2809e1a58b is the first bad commit commit f2c6b0f452c3804496f55655fda28c2809e1a58b Author: Alex Deucher Date: Wed Jun 25 19:32:36 2014 -0400 drm/radeon/cik: Add support for new ucode format (v5) This adds CIK support for the new ucode format. v2: add size validation, integrate debug info v3: add support for MEC2 on KV v4: fix typos v4: update to latest format Signed-off-by: Alex Deucher :04 04 9d67f55d30562a528f15cd21ae4bde4598688525 6e1c473d75fb7bc7598872f9e535c7a074d1fcfd M drivers -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/1a1c0440/attachment.html>
[Bug 82588] X fails to start with linus-tip or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=82588 --- Comment #17 from Mike Lothian --- Created attachment 106226 --> https://bugs.freedesktop.org/attachment.cgi?id=106226&action=edit Firmware sha1sums -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/14ed2433/attachment.html>
[Bug 74428] hyperz causes gpu hang in Counter-strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=74428 --- Comment #6 from Corey Richardson --- I can't reproduce this on git-f976b4c. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/82d5be40/attachment.html>
[Bug 73785] [HyperZ] Team Fortress 2 causes random GPU stalls on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=73785 --- Comment #9 from bahamut2k456 at aol.com --- Currently running revision git-d13d2fd, hyperz enabled, on a 280x. I'm seeing no issues. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/daba9ce1/attachment.html>
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #31 from Chernovsky Oleg --- A quick update - I was finally able to retrieve all needed data from fglrx (via some ADL SDK overdrive6 tinkering). It seems there is a lot of work (e.g. there is a feature for setting series of pairs temperature<->fanspeed), but at least I figured out the purpose of used registers and data values (I hope). So I'll try to come up with basic functionality and hwmon interface this week. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/21888ced/attachment.html>
[Bug 81382] Text console blanking does not go away
https://bugs.freedesktop.org/show_bug.cgi?id=81382 --- Comment #12 from Daniel Kirsten --- (In reply to comment #11) > I've got the same notebook as Daniel Kirsten, They sold different Amilo Xi 2550, there are even some Amilo Xi 2550 with an Nvidia graphic card. > If I change /sys/class/backlight/radeon_bl0/brightness or > /sys/class/backlight/acpi_video0 the display stayes dark. I can control brightness by writing 0-7 into /sys/class/backlight/acpi_video0/brightness You should comment out lines 233-234 in drivers/gpu/drm/radeon/atombios_encoders.c, i.e., /* if (bd->props.brightness == 0) 234 bd->props.brightness = RADEON_MAX_BL_LEVEL;*/ then it works. Daniel -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/b6bb5b7f/attachment.html>
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #32 from Anton L. --- (In reply to comment #31) > A quick update - I was finally able to retrieve all needed data from fglrx > (via some ADL SDK overdrive6 tinkering). It seems there is a lot of work > (e.g. there is a feature for setting series of pairs > temperature<->fanspeed), but at least I figured out the purpose of used > registers and data values (I hope). > > So I'll try to come up with basic functionality and hwmon interface this > week. Hi, Oleg. Do you require dumps for PITCAIRN chips -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/820cf915/attachment.html>
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #33 from Chernovsky Oleg --- (In reply to comment #32) > Hi, Oleg. Do you require dumps for PITCAIRN chips Yes, I need as much dumps as possible. I hope overdrive v6 works for all SI chips, so I've made simple example program for testing >SI asics, it lays here https://github.com/Adonai/radeon-fancontrol. You can check if it works while in X session with fglrx driver. So you should do the following: 1) install fglrx and configure it 2) switch to text console and stop any X being used 3) rmmod fglrx 4) now start mmiotrace (kernel has pretty nice doc here https://www.kernel.org/doc/Documentation/trace/mmiotrace.txt) 5) modprobe fglrx 6) start X && export DISPLAY=:0 7) now begin to collect data from mmiotrace (via cat trace_pipe &), you can put some marks here 8) start above mentioned program. There should be some noize from GPU fan for 6 seconds, it's normal 9) after it exits (in 10 seconds) collect its output and piped mmiotrace logs and post the results here Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140913/138e66bc/attachment.html>
3.7+ kernels and Radeon HD 4250 backlight
Hi!
I have problems running android-x86 (32 bit, 4.0-r1) with kernel 3.10
64 bit. Android drivers (binder and ashmem) are modified for this mode
(no problems). Problem is with radeon fb. Function radeon_iocl() is
failed on line: DRM_ERROR("copy_to_user %s:%u\n", __func__, __LINE__)
on request RADEON_INFO_TILING_CONFIG. Looks like pointer to userspace
is wrong.
