ptop goes thorough a suspend and resume.
What kind of flicker is it? E.g. does it only affect X or also console,
does it flicker all the time or only when there is activity, what does
it look like, ...
--
Earthling Michel Dänzer | http://www.amd.c
and resume.
What kind of flicker is it? E.g. does it only affect X or also console,
does it flicker all the time or only when there is activity, what does
it look like, ...
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
rg itself has always been working, only OpenGL can be problematic.
Have you verified r600_dri.so is used for that?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
--
To unsubscribe from this list:
OpenGL can be problematic.
Have you verified r600_dri.so is used for that?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
From: Michel Dänzer
If the image size would ever read as 0, pci_get_rom_size could keep
processing the same image over and over again.
Reported-by: Federico
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer
---
v2:
* Use unsigned instead of u16 for the local length variable (not sure
From: Michel Dänzer michel.daen...@amd.com
If the image size would ever read as 0, pci_get_rom_size could keep
processing the same image over and over again.
Reported-by: Federico federic...@gmail.com
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
v2:
* Use
On 12.11.2014 02:54, Marcus Overhagen wrote:
This crash occured after about a day with 3.18.0-rc3
Is it a regression? If yes, can you bisect?
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
On 12.11.2014 02:54, Marcus Overhagen wrote:
This crash occured after about a day with 3.18.0-rc3
Is it a regression? If yes, can you bisect?
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
ned values instead of hardcoding.
Signed-off-by: Joe Perches
---
I think this should be NUM_SHADER_ENGINES_SHIFT?
(Joe can't type)
exactly right, thanks Michel
Applied with a compile fix.
Joe, in the future please make sure your patches compile before
submitting them.
--
Earthling Mic
amp;& (rdev->family <= CHIP_HEMLOCK)) {
u32 efuse_straps_4;
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
--
To unsubscribe from this list: send t
efuse_straps_4;
Reviewed-by: Michel Dänzer michel.daen...@amd.com
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
gt; 12) + 1;
+ num_shader_engines = ((gb_addr_config & NUM_SHADER_ENGINES_MASK)
+ >> NUM_SHADER_ENGINES) + 1;
^^
I think this should be NUM_SHADER_ENGINES_SHIFT?
Looks good to me other than that.
--
Earthling
= ((gb_addr_config NUM_SHADER_ENGINES_MASK)
+ NUM_SHADER_ENGINES) + 1;
^^
I think this should be NUM_SHADER_ENGINES_SHIFT?
Looks good to me other than that.
--
Earthling Michel Dänzer| http
On 06.09.2014 01:49, Mikael Pettersson wrote:
> Michel Dänzer writes:
> > On 30.08.2014 22:59, Mikael Pettersson wrote:
> > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen
> corruption
> > > after a while in X + firefox. This stil
On 06.09.2014 01:49, Mikael Pettersson wrote:
Michel Dänzer writes:
On 30.08.2014 22:59, Mikael Pettersson wrote:
Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen
corruption
after a while in X + firefox. This still occurs with yesterday's HEAD
of Linus' repo
*/
- if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush)
+ if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush &&
+ !rdev->asic->mmio_hdp_flush)
rdev->asic->ring[
)
+ if (hdp_flush rdev-asic-ring[ring-idx]-hdp_flush
+ !rdev-asic-mmio_hdp_flush)
rdev-asic-ring[ring-idx]-hdp_flush(rdev, ring);
/* We pad to match fetch size */
while (ring-wptr ring-align_mask) {
--
Earthling Michel Dänzer
;> it is already somewhat below capacity, it gets "punished" by not
>>> getting refilled? I'd just like to understand the logic behind that line.
>>>
>>> thanks,
>>> -mario
>>
>> I'll happily forward that question to Konrad who wrote the
some BOs ended up in GTT instead with write-combined CPU mappings) on
radeonsi without any noticeable issues.
Tested-by: Michel Dänzer michel.daen...@amd.com
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X
On 27.07.2014 03:02, Steven Chamberlain wrote:
> On 25/07/14 02:25, Michel Dänzer wrote:
>> Attached is fair.s from Debian gcc 4.8.3-5. Does that look better? I'm
>> going to try reproducing the problem with a kernel built by that now.
>
> It looks like gcc-4.9 Debian pa
On 27.07.2014 03:02, Steven Chamberlain wrote:
On 25/07/14 02:25, Michel Dänzer wrote:
Attached is fair.s from Debian gcc 4.8.3-5. Does that look better? I'm
going to try reproducing the problem with a kernel built by that now.
It looks like gcc-4.9 Debian package version 4.9.1-2 available
On 29.07.2014 01:48, Linus Torvalds wrote:
> On Sun, Jul 27, 2014 at 8:47 PM, Michel Dänzer wrote:
>> On 27.07.2014 04:56, Linus Torvalds wrote:
>>>
>>> Also, Michel - can you try this patch if you still have your
>>> gcc-4.9.0 install, and send me the resulti
On 29.07.2014 01:48, Linus Torvalds wrote:
On Sun, Jul 27, 2014 at 8:47 PM, Michel Dänzer mic...@daenzer.net wrote:
On 27.07.2014 04:56, Linus Torvalds wrote:
Also, Michel - can you try this patch if you still have your
gcc-4.9.0 install, and send me the resulting fair.s file again
e a GCC bugzilla account and add myself to the CC
list if that helps.
FWIW though, the fair.i file you attached is basically identical to what
I'm getting, the only difference being a handful of file path strings.
--
Earthling Michel Dänzer| http://www.amd.com
Libre so
file you attached is basically identical to what
I'm getting, the only difference being a handful of file path strings.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
--
To unsubscribe from
On 23.07.2014 18:31, Michel Dänzer wrote:
> On 23.07.2014 18:25, Peter Zijlstra wrote:
>> On Wed, Jul 23, 2014 at 10:28:19AM +0200, Peter Zijlstra wrote:
>>
>>> Of course, the other thing that patch did is clear sgp->power (now
>>> sgc->capacity).
>&
On 23.07.2014 18:31, Michel Dänzer wrote:
On 23.07.2014 18:25, Peter Zijlstra wrote:
On Wed, Jul 23, 2014 at 10:28:19AM +0200, Peter Zijlstra wrote:
Of course, the other thing that patch did is clear sgp-power (now
sgc-capacity).
Hmm, re-reading the thread there isn't a clear confirmation
is operating on, lemme try and figure that out.
>
> Ah, this appears to be load_balance()'s:
>
> cpumask_copy(cpus, cpu_active_mask);
Right, according to addr2line it's the memcpy in bitmap_copy().
> Which totally doesn't make sense, both src and dst are static sto
s.
It can take a long time for the problem to occur, so I need to run at
least for one or two days to be at least somewhat sure a given kernel is
not affected.
I'll try reproducing the problem with your previous suggestions first,
but if I manage to do that, I guess there's no alternative to bisecti
days to be at least somewhat sure a given kernel is
not affected.
I'll try reproducing the problem with your previous suggestions first,
but if I manage to do that, I guess there's no alternative to bisecting...
--
Earthling Michel Dänzer| http://www.amd.com
Libre
generate a #GP. Puzzled.
Could it be the memcpy length being off or something like that?
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
--
To unsubscribe from this list: send the line unsubscribe linux
On 22.07.2014 15:13, Michel Dänzer wrote:
> On 18.07.2014 18:29, Michel Dänzer wrote:
>> On 17.07.2014 16:58, Peter Zijlstra wrote:
>>> On Thu, Jul 17, 2014 at 04:31:04PM +0900, Michel Dänzer wrote:
>>>>
>>>> I've been running into the panic captured in th
On 18.07.2014 18:29, Michel Dänzer wrote:
> On 17.07.2014 16:58, Peter Zijlstra wrote:
>> On Thu, Jul 17, 2014 at 04:31:04PM +0900, Michel Dänzer wrote:
>>>
>>> I've been running into the panic captured in the attached picture (hope
>>> it's legible) randoml
On 18.07.2014 18:29, Michel Dänzer wrote:
On 17.07.2014 16:58, Peter Zijlstra wrote:
On Thu, Jul 17, 2014 at 04:31:04PM +0900, Michel Dänzer wrote:
I've been running into the panic captured in the attached picture (hope
it's legible) randomly while running 3.16-rc4 and -rc5. I haven't
On 22.07.2014 15:13, Michel Dänzer wrote:
On 18.07.2014 18:29, Michel Dänzer wrote:
On 17.07.2014 16:58, Peter Zijlstra wrote:
On Thu, Jul 17, 2014 at 04:31:04PM +0900, Michel Dänzer wrote:
I've been running into the panic captured in the attached picture (hope
it's legible) randomly while
On 17.07.2014 16:58, Peter Zijlstra wrote:
> On Thu, Jul 17, 2014 at 04:31:04PM +0900, Michel Dänzer wrote:
>>
>> I've been running into the panic captured in the attached picture (hope
>> it's legible) randomly while running 3.16-rc4 and -rc5. I haven't
>> not
On 17.07.2014 16:58, Peter Zijlstra wrote:
On Thu, Jul 17, 2014 at 04:31:04PM +0900, Michel Dänzer wrote:
I've been running into the panic captured in the attached picture (hope
it's legible) randomly while running 3.16-rc4 and -rc5. I haven't
noticed any pattern as to when it happens
.
Signed-off-by: Michel Dänzer
---
v2: Updated commit log, how about this?
drivers/net/ethernet/realtek/r8169.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 06bdc31..61623e9 100644
--- a/drivers/net/ethernet
I can't do that. I don't really understand any of this stuff,
I just googled the IOMMU event message, found similar patches for other
chipsets, and adapted them for my mainboard until the problem stopped.
--
Earthling Michel Dänzer| http://www.amd.com
Libre softw
.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
.
Signed-off-by: Michel Dänzer mic...@daenzer.net
---
v2: Updated commit log, how about this?
drivers/net/ethernet/realtek/r8169.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 06bdc31..61623e9 100644
On 15.07.2014 18:29, Hayes Wang wrote:
> Michel Dänzer [mailto:mic...@daenzer.net]
>> Sent: Tuesday, July 15, 2014 2:42 PM
>> To: Francois Romieu; nic_swsd
>> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: [PATCH] r8169: Enable RX_MULTI
Without this, the ethernet port on my ASUS A88X Pro mainboard stops
working sometimes, with messages like these in dmesg:
AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x001e
address=0x3000 flags=0x0050]
Signed-off-by: Michel Dänzer
---
drivers/net/ethernet/realtek
Without this, the ethernet port on my ASUS A88X Pro mainboard stops
working sometimes, with messages like these in dmesg:
AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x001e
address=0x3000 flags=0x0050]
Signed-off-by: Michel Dänzer mic...@daenzer.net
---
drivers/net
On 15.07.2014 18:29, Hayes Wang wrote:
Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Tuesday, July 15, 2014 2:42 PM
To: Francois Romieu; nic_swsd
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: [PATCH] r8169: Enable RX_MULTI_EN for RTL_GIGA_MAC_VER_40
Without
define for it somewhere
> instead of hardcoding 8 VMIDs on the KGD side and 8 VMIDs on KFD side
> without any relation to each other.
Seconded, and there should be more explanation and rationale for the way
things are set up in the code or at least in the commit log.
--
Earthling Michel Dänz
/*
> + * number of VMs
> + * VMID 0 is reserved for Graphics
> + * radeon compute will use VMIDs 1-7
> + * KFD will use VMIDs 8-15
> + */
> + rdev->vm_manager.nvm = 8;
This comment is inaccurate: Graphics can use VMIDs 1-7 as well.
--
Earthling
0 is reserved for Graphics
+ * radeon compute will use VMIDs 1-7
+ * KFD will use VMIDs 8-15
+ */
+ rdev-vm_manager.nvm = 8;
This comment is inaccurate: Graphics can use VMIDs 1-7 as well.
--
Earthling Michel Dänzer| http://www.amd.com
Libre
a define for it somewhere
instead of hardcoding 8 VMIDs on the KGD side and 8 VMIDs on KFD side
without any relation to each other.
Seconded, and there should be more explanation and rationale for the way
things are set up in the code or at least in the commit log.
--
Earthling Michel Dänzer
DELAYED_WORK(>uvd.idle_work, radeon_uvd_idle_work_handler);
Returning -EINVAL here results in rather misleading dmesg output I
think. This should probably be handled more gracefully.
Anyway, the return statement would need to be indented per the kernel
coding style, and please leave empty li
misleading dmesg output I
think. This should probably be handled more gracefully.
Anyway, the return statement would need to be indented per the kernel
coding style, and please leave empty lines before the if and after the
return.
--
Earthling Michel Dänzer | http
7-rc2/
Please also provide the Xorg.0.log file from after you restarted gdm.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
--
To unsubscribe from this list: send the line "unsubscrib
and a picture showing a tty0 with parts of the
image corrupted by the image of the GDM screen before it was restarted,
can be found at http://artipc10.vub.ac.be/~frederik/linux-3.7-rc2/
Please also provide the Xorg.0.log file from after you restarted gdm.
--
Earthling Michel Dänzer
expected 'struct device *' but
> argument is of type 'struct device *'
>
> V2:
> 1, Add compilation error messages;
> 2, Make the From: address the same as Signed-off-by address.
>
> Signed-off-by: Huacai Chen
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer
device *'
V2:
1, Add compilation error messages;
2, Make the From: address the same as Signed-off-by address.
Signed-off-by: Huacai Chen che...@lemote.com
Reviewed-by: Michel Dänzer michel.daen...@amd.com
--
Earthling Michel Dänzer | http://www.amd.com
Libre
clude/drm/drm_sarea.h
> index ee5389d..1d1a858 100644
> --- a/include/drm/drm_sarea.h
> +++ b/include/drm/drm_sarea.h
> @@ -37,6 +37,8 @@
> /* SAREA area needs to be at least a page */
> #if defined(__alpha__)
> #define SAREA_MAX 0x2000U
> +#elif define
0x2000U
+#elif defined(__mips__)
+#define SAREA_MAX 0x4000U
#elif defined(__ia64__)
#define SAREA_MAX 0x1U /* 64kB */
#else
This should be four separate patches.
--
Earthling Michel Dänzer
s bad or good but look for a nearby commit
that compiles.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
commit
that compiles.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
the DRM lock, so the 'each tasklet can only
run once at a time' restriction is fine.
I'm looking forward to any suggestions what to do with this in case
tasklets disappear, and I'll gladly provide further clarification on the
requirements.
--
Earthling Michel Dänzer
the DRM lock, so the 'each tasklet can only
run once at a time' restriction is fine.
I'm looking forward to any suggestions what to do with this in case
tasklets disappear, and I'll gladly provide further clarification on the
requirements.
--
Earthling Michel Dänzer
gainst the drm tree fix it? Only build tested.
---
>From f0e6bdc165cb484b8992b14172a7280f301bf513 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michel_D=C3=A4nzer?= <[EMAIL PROTECTED]>
Date: Fri, 25 May 2007 11:02:05 +0200
Subject: Make sure the drawable code doesn't call malloc(0).
Signed-off-by: Miche
f0e6bdc165cb484b8992b14172a7280f301bf513 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michel_D=C3=A4nzer?= [EMAIL PROTECTED]
Date: Fri, 25 May 2007 11:02:05 +0200
Subject: Make sure the drawable code doesn't call malloc(0).
Signed-off-by: Michel Dänzer [EMAIL PROTECTED]
---
linux-core/drm_drawable.c | 41
On Fri, 2005-02-18 at 16:14 -0500, Jon Smirl wrote:
> On Fri, 18 Feb 2005 16:08:22 -0500, Bill Nottingham <[EMAIL PROTECTED]> wrote:
> > Under Fedora (and RHEL), they're there because we generally
> > don't want to load them unless the user asked for them.
>
> Is there a specific reason why they
On Fri, 2005-02-18 at 16:14 -0500, Jon Smirl wrote:
On Fri, 18 Feb 2005 16:08:22 -0500, Bill Nottingham [EMAIL PROTECTED] wrote:
Under Fedora (and RHEL), they're there because we generally
don't want to load them unless the user asked for them.
Is there a specific reason why they are
301 - 366 of 366 matches
Mail list logo
