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
gt; INIT_DELAYED_WORK(&rdev->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
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
le pointer type
> include/drm/ttm/ttm_page_alloc.h:82:13: note: 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.
>
&g
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 a
* It requires holding 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 th
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:
ther bug,
> but might be relevant for your use-case. Just try to run both an fbdev
> application and some kms-native thing, and then SIGKILL the native kms
> app.
>
> But since pre-existing not really required, and probably too much effort.
I suspect somet
On 21/06/17 05:14 PM, Daniel Vetter wrote:
> On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
>> On 21/06/17 04:38 PM, Daniel Vetter wrote:
>>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
>>>> This makes the redundant fb helpers .load_
On 26.10.2015 22:42, Luis Henriques wrote:
> 3.16.7-ckt19 -stable review patch. If anyone has any objections, please let
> me know.
>
> --
>
> From: =TF-8?q?Michel Dänzer?=
>
> commit 4281f46ef839050d2ef60348f661eb463c21cc2e upstream.
>
>
entical with the end consumer.
That's actually not really true. Even in cases where a BO is shared with
a different process, it is still used at least occasionally in the
process which allocated it as well. Otherwise there would be no point in
sharing it between processes.
There should be no problem if the memory of a shared BO is accounted for
in each process sharing it. It might be nice to scale each process'
"debt" by 1 / (number of processes sharing it) if possible, but in the
worst case accounting it fully in each process should be fine.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-01-24 10:28 AM, Michal Hocko wrote:
> On Tue 23-01-18 17:39:19, Michel Dänzer wrote:
>> On 2018-01-23 04:36 PM, Michal Hocko wrote:
>>> On Tue 23-01-18 15:27:00, Roman Gushchin wrote:
>>>> On Thu, Jan 18, 2018 at 06:00:06PM +0100, Michal Hocko wrote:
>>
On 2018-01-24 12:01 PM, Michal Hocko wrote:
> On Wed 24-01-18 11:27:15, Michel Dänzer wrote:
>> On 2018-01-24 10:28 AM, Michal Hocko wrote:
> [...]
>>> So how exactly then helps to kill one of those processes? The memory
>>> stays pinned behind or do I still misunders
On 2018-01-24 12:50 PM, Michal Hocko wrote:
> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
>> On 2018-01-24 12:01 PM, Michal Hocko wrote:
>>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote:
> [...]
>>>> 2. If the OOM killer kills a process which is sharing BO
On 2018-01-24 12:50 PM, Michal Hocko wrote:
> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
>> On 2018-01-24 12:01 PM, Michal Hocko wrote:
>>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote:
> [...]
>>>> 2. If the OOM killer kills a process which is sharing BO
On 2018-01-30 10:31 AM, Daniel Vetter wrote:
> On Wed, Jan 24, 2018 at 01:11:09PM +0100, Christian König wrote:
>> Am 24.01.2018 um 12:50 schrieb Michal Hocko:
>>> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
>>>> On 2018-01-24 12:01 PM, Michal Hocko wrote:
>>
On 2018-01-30 11:42 AM, Daniel Vetter wrote:
> On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote:
>> On 2018-01-30 10:31 AM, Daniel Vetter wrote:
>>
>>> I guess a good first order approximation would be if we simply charge any
>>> newly allocated bu
On 2018-01-30 11:40 AM, Christian König wrote:
> Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
>> [SNIP]
>>> Would it be ok to hang onto potentially arbitrary mmget references
>>> essentially forever? If that's ok I think we can do your process based
>>> ac
On 2018-01-30 12:28 PM, Christian König wrote:
> Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
>> On 2018-01-30 11:40 AM, Christian König wrote:
>>> Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
>>>> [SNIP]
>>>>> Would it be ok to hang onto potentially
On 2018-01-30 12:36 PM, Nicolai Hähnle wrote:
> On 30.01.2018 12:34, Michel Dänzer wrote:
>> On 2018-01-30 12:28 PM, Christian König wrote:
>>> Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
>>>> On 2018-01-30 11:40 AM, Christian König wrote:
>>>>>
On 2018-01-30 12:56 PM, Christian König wrote:
> Am 30.01.2018 um 12:42 schrieb Michel Dänzer:
>> On 2018-01-30 12:36 PM, Nicolai Hähnle wrote:
>>> On 30.01.2018 12:34, Michel Dänzer wrote:
>>>> On 2018-01-30 12:28 PM, Christian König wrote:
>>>>>
and consider those in oom_badness? The rule would be
>> that such a memory is bound to the process life time. I guess we will
>> find more users for this later.
>
> I already tried that and the problem with that approach is that some
> buffers are not created by the application which actually uses them.
>
> For example X/Wayland is creating and handing out render buffers to
> application which want to use OpenGL.
>
> So the result is when you always account the application who created the
> buffer the OOM killer will certainly reap X/Wayland first. And that is
> exactly what we want to avoid here.
FWIW, what you describe is true with DRI2, but not with DRI3 or Wayland
anymore. With DRI3 and Wayland, buffers are allocated by the clients and
then shared with the X / Wayland server.
Also, in all cases, the amount of memory allocated for buffers shared
between DRI/Wayland clients and the server should be relatively small
compared to the amount of memory allocated for buffers used only locally
in the client, particularly for clients which create significant memory
pressure.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-01-19 10:58 AM, Christian König wrote:
> Am 19.01.2018 um 10:32 schrieb Michel Dänzer:
>> On 2018-01-19 09:39 AM, Christian König wrote:
>>> Am 19.01.2018 um 09:20 schrieb Michal Hocko:
>>>> On Thu 18-01-18 12:01:32, Eric Anholt wrote:
>>>>> Mi
On 2018-01-19 11:02 AM, Michel Dänzer wrote:
> On 2018-01-19 10:58 AM, Christian König wrote:
>> Am 19.01.2018 um 10:32 schrieb Michel Dänzer:
>>> On 2018-01-19 09:39 AM, Christian König wrote:
>>>> Am 19.01.2018 um 09:20 schrieb Michal Hocko:
>>>>>
t; descriptor is used by more than one at the same time.
In that case, accounting a BO as suggested by Michal above, in every
process that shares it, should work fine, shouldn't it?
The OOM killer will first select the process which has more memory
accounted for other things than the BOs shared with another process.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-12-06 1:23 p.m., Joe Perches wrote:
> On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote:
>> In contrast to the 2b case, the pr_debug output isn't visible by default
>> with 1b, so the latter doesn't fit "always produce output" either.
>
> I th
On 2018-12-06 5:10 p.m., Daniel Thompson wrote:
> On Thu, Dec 06, 2018 at 03:41:16PM +0100, Michel Dänzer wrote:
>> On 2018-12-06 1:23 p.m., Joe Perches wrote:
>>> On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote:
>>>> In contrast to the 2b case, the pr_debug o
On 2018-12-06 5:46 p.m., Joe Perches wrote:
> On Thu, 2018-12-06 at 17:39 +0800, Zhang, Jerry(Junwei) wrote:
>> On 12/6/18 5:33 PM, Koenig, Christian wrote:
>>> Am 06.12.18 um 10:09 schrieb Michel Dänzer:
>>>> On 2018-12-06 3:43 a.m., Zhang, Jerry(Junwei) wrote:
>
On 2018-05-25 10:41 AM, Christoph Hellwig wrote:
> On Tue, May 22, 2018 at 03:13:58PM +0200, Christian König wrote:
>> Am 02.05.2018 um 18:59 schrieb Michel Dänzer:
>>> On 2018-05-02 06:21 PM, Christoph Hellwig wrote:
>>>> On Wed, May 02, 2018 at 04:31:09PM +0200,
From: Michel Dänzer
No need for pr_err here, the pr_err message in ttm_bo_evict is enough
to draw attention to something not going as planned.
Signed-off-by: Michel Dänzer
---
Similar to a previous patch, but this one leaves the pr_err messages in
ttm_bo_evict untouched.
drivers/gpu/drm/ttm
and create a new commit otherwise?
Otherwise the atomic API just moves this same problem to be solved by
userspace.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
pflip_status thus will refuse to notify the job
> completion. The job will eventually times out.
>
> Reverse the order of calling page_flip and setting pflip_status to
> fix the race.
There is no race, amdgpu_crtc->pflip_status is protected by dev->event_
houldn't be printed by default, or buggy / malicious
userspace can spam dmesg. I suggest using DRM_DEBUG_KMS or DRM_DEBUG_DRIVER.
> + return ERR_PTR(-EINVAL);
> + }
>
> obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
> if (obj ==
pu_align_pitch(adev, mode_cmd->width, cpp, false);
Also, this needs to use mode_cmd->pitches[0] instead of mode_cmd->width,
otherwise it'll spuriously fail for larger but well-aligned pitches.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
eight, 8);
> + if (obj->size < pitch * height) {
> + dev_err(&dev->pdev->dev, "Invalid GEM size: expecting %d but
> got %d\n",
> + pitch * height, obj->size);
Same comment as patch 2, and maybe
On 2018-12-20 6:16 p.m., Michel Dänzer wrote:
> On 2018-12-20 6:09 p.m., Daniel Vetter wrote:
>> On Thu, Dec 20, 2018 at 6:03 PM Alex Deucher wrote:
>>> On Thu, Dec 20, 2018 at 11:54 AM Daniel Vetter wrote:
>>
>>>> Not sure about the gamma thing since we
second, but I suspect even a
single one could cause a frame drop. I assume the issue is that gamma
updates are done as separate atomic commits, which can delay other
commits for page flips.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-12-21 2:26 p.m., Daniel Vetter wrote:
> On Fri, Dec 21, 2018 at 10:47:27AM +0100, Michel Dänzer wrote:
>> On 2018-12-20 6:16 p.m., Michel Dänzer wrote:
>>> On 2018-12-20 6:09 p.m., Daniel Vetter wrote:
>>>> On Thu, Dec 20, 2018 at 6:03 PM Alex Deucher wrote:
On 2019-01-07 5:00 a.m., Yu Zhao wrote:
> On Thu, Jan 03, 2019 at 05:33:19PM +0100, Michel Dänzer wrote:
>> On 2018-12-30 2:00 a.m., Yu Zhao wrote:
>>> Userspace may request pitch alignment that is not supported by GPU.
>>> Some requests 32, but GPU ignores it and uses d
return ERR_PTR(-EINVAL);
> + }
>
> obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
> if (obj == NULL) {
>
Apart from the above, the v5 series looks good to me.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-12-23 10:44 p.m., Yu Zhao wrote:
> On Fri, Dec 21, 2018 at 10:07:26AM +0100, Michel Dänzer wrote:
>> On 2018-12-21 4:10 a.m., Yu Zhao wrote:
>>> Userspace may request pitch alignment that is not supported by GPU.
>>> Some requests 32, but GPU ignores it and
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 o
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
On 2018-03-26 04:36 PM, Lucas Stach wrote:
> Am Dienstag, den 30.01.2018, 11:28 +0100 schrieb Michal Hocko:
>> On Tue 30-01-18 10:29:10, Michel Dänzer wrote:
>>> On 2018-01-24 12:50 PM, Michal Hocko wrote:
>>>> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
>&g
On 2018-04-04 11:36 AM, Lucas Stach wrote:
> Am Mittwoch, den 04.04.2018, 11:09 +0200 schrieb Michel Dänzer:
>> On 2018-03-26 04:36 PM, Lucas Stach wrote:
>>> Am Dienstag, den 30.01.2018, 11:28 +0100 schrieb Michal Hocko:
>>>> On Tue 30-01-18 10:29:10, Michel Dänzer
From: Michel Dänzer
When it's set, TTM tries to allocate huge pages if possible. Drivers
which can take advantage of huge pages should set it.
Drivers not setting this flag no longer incur any overhead related to
allocating or freeing huge pages.
Cc: sta...@vger.kernel.org
Signed-o
From: Michel Dänzer
GFP_TRANSHUGE tries very hard to allocate huge pages, which can result
in long delays with high memory pressure. I have observed firefox
freezing for up to around a minute due to this while restic was taking
a full system backup.
Since we don't really need huge pages
[ Dropping Roger He, his e-mail address seems to bounce ]
On 2018-04-27 04:51 AM, zhoucm1 wrote:
> On 2018年04月26日 23:06, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> When it's set, TTM tries to allocate huge pages if possible.
> Do you mean original driver doe
From: Michel Dänzer
Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled)
try to allocate huge pages. However, not all drivers can take advantage
of huge pages, but they would incur the overhead for allocating and
freeing them anyway.
Now, drivers which can take advantage of
On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled)
>> try to allocate huge pages. However, not all drivers can take adva
On 2018-04-29 09:02 AM, Christian König wrote:
> Am 29.04.2018 um 01:02 schrieb Michel Dänzer:
>> On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
>>> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer
>>> wrote:
>>>> From: Michel Dänzer
>&
From: Michel Dänzer
The result was printing the warning only when we were explicitly asked
not to.
Cc: sta...@vger.kernel.org
Fixes: 0176adb004065d6815a8e67946752df4cd947c5b "swiotlb: refactor
coherent buffer allocation"
Signed-off-by: Michel Dänzer
---
lib/swiotlb.c | 2 +-
1 fi
ssions introduced by commit
0176adb004065d6815a8e67946752df4cd947c5b "swiotlb: refactor
coherent buffer allocation" in 4.16-rc1.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 2018-04-29 01:56 AM, Ilia Mirkin wrote:
> On Sat, Apr 28, 2018 at 7:02 PM, Michel Dänzer wrote:
>>
>> Unfortunately, there was an swiotlb regression (not directly related to
>> Christian's work) shortly after this fix, also in 4.16-rc1, which is now
>> fixed in
c_attrs sooner, and only
> allow either GFP_KERNEL or GFP_DMA passed in dma_alloc_coherent.
How about GFP_TRANSHUGE_LIGHT? TTM uses that to opportunistically
allocate huge pages (GFP_TRANSHUGE can result in unacceptably long
delays with memory pressure).
--
Earthling Michel Dänzer
On 2018-05-02 06:21 PM, Christoph Hellwig wrote:
> On Wed, May 02, 2018 at 04:31:09PM +0200, Michel Dänzer wrote:
>>> No. __GFP_NOWARN (and gfp_t flags in general) are the wrong interface
>>> for dma allocations and just cause problems. I actually plan to
>>> ge
int radeon_agpmode = 0;
> +#endif
> int radeon_vram_limit = 0;
> int radeon_gart_size = -1; /* auto */
> int radeon_benchmarking = 0;
>
Pushed to amd-staging-drm-next, thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
ks for that.
> since it's our native granularity after all (while a timestamp is not).
Note that variable refresh rate (Adaptive Sync / FreeSync / G-Sync)
changes things in this regard. It makes the vblank length variable, and
if you wait for multiple vblanks between flips, you get t
On 2019-03-25 10:05 p.m., Kangjie Lu wrote:
> In case alloc_workqueue fails, the fix frees memory and
> returns -ENOMEM to avoid potential NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu
> ---
> v2: use radeon_crtc_destroy to properly clean up resources as
> sugge
issue and mesa was using
SYS_kcmp to compare device node fds.
A far shorter and more portable solution is possible, so let me
prepare a Mesa patch.
Make sure to read my comments on
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6881 first. :)
--
Earthling Michel Dänzer
ell, because you
didn't trim the quoted text (hint, hint).
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
50).
>
> In this case the patch is a clear NAK since you haven't root caused the
> issue and are just working around it in a very questionable manner.
To be fair though, amdgpu & radeon are already disabling write-combining
for system memory pages in 32-bit x86 kernels for similar reasons.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
initialize
req.reply.tval_usec = req32.reply.tval_usec;
before calling drm_ioctl_kernel, since it's not aliased by any req.request.*
member, and drm_wait_vblank_ioctl doesn't always write to it.
--
Earthling Michel Dänzer | https://redhat.com
Libr
select if CONFIG_DRM is
unfortunately needed I think.
Per above, not sure this is really true.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
On 2021-02-08 12:49 p.m., Michel Dänzer wrote:
On 2021-02-05 9:53 p.m., Daniel Vetter wrote:
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
Userspace has discovered the functionality offered by SYS_kcmp and has
started to depend
On 2021-02-08 2:34 p.m., Daniel Vetter wrote:
On Mon, Feb 8, 2021 at 12:49 PM Michel Dänzer wrote:
On 2021-02-05 9:53 p.m., Daniel Vetter wrote:
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
Userspace has discovered the
From: Michel Dänzer
Without __GFP_NOWARN, attempts at allocating huge pages can trigger
dmesg splats like below (which are essentially noise, since TTM falls
back to normal pages if it can't get a huge one).
[ 9556.710241] clinfo: page allocation failure: order:9,
mode:0x194dc2(GFP_HIG
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 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 legibl
se. I can create 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://
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 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 Debi
/*
> + * 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
uld use 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 M
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
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
'm afraid 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:
s
the problem for me.
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/
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
ing this.
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 al
ntirely sure
>> what the rep movsl 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 d
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 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 wi
via the ring buffer, we need to
* do it before padding.
*/
- 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
thanks,
>>> -mario
>>
>> I'll happily forward that question to Konrad who wrote the code (or it
>> may even stem from the ordinary page pool code which IIRC has Dave
>> Airlie / Jerome Glisse as authors)
>
> This is effectively bogus code, i now
AR) && (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: s
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.
--
Earthlin
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
radeon driver is built into the kernel (or loaded from the
initrd?), the attempt to load the firmware might take a long time to
time out.
Please provide more information about the symptoms, e.g. any dmesg
output etc.
--
Earthling Michel Dänzer | h
On 12.04.2016 23:16, Greg Kroah-Hartman wrote:
> On Mon, Apr 11, 2016 at 11:26:00AM +0900, Michel Dänzer wrote:
>> On 11.04.2016 03:36, Greg Kroah-Hartman wrote:
>>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> A regressi
adev,
>
> /* wakeup usersapce */
> if (works->event)
> - drm_send_vblank_event(adev->ddev, crtc_id, works->event);
> + drm_crtc_send_vblank_event(&amdgpu_crtc->base, works->event);
>
> spin_unlock_irqrestore(&adev->ddev->event_lock, flags);
>
>
This patch and patch 8 are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
gt; display so we need to offset the plane position in order for the active
>> pixel to be in the correct place.
>
> Nope, hot_x/y is just for virtual machines to indicate where the logical
> cursor position is within the cursor plane. It should have 2 effect on how
> somethin
On 18.11.2015 17:51, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 05:39:39PM +0900, Michel Dänzer wrote:
>> On 18.11.2015 01:29, Daniel Vetter wrote:
>>>
>>> And no, I have absolutely no idea why radeon is pulling some tricks here,
>>> whi
a problem, you did not know how to debug it, but it already
> happened to pebolle at tiscali ... and yes, it was agpmode. That
> problem is clearly more common then you realize... So this should go
> in.
I agree with Christian, but at the very least, agpmode must not be
mention
none of the drivers do, either.
daenzer@kaveri|11:55:31> grep '#include "drm.h"' include/uapi/drm/*
include/uapi/drm/amdgpu_drm.h:#include "drm.h"
include/uapi/drm/radeon_drm.h:#include "drm.h"
Patches to convert the rest are pending.
--
Earthling Michel
ese days hopefully, but if anybody has any ideas offhand...
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 21.01.2016 14:31, Mario Kleiner wrote:
> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>> On 21.01.2016 05:32, Mario Kleiner wrote:
>>>
>>> So the problem is that AMDs hardware frame counters reset to
>>> zero during a modeset. The old DRM code dealt with driv
On 21.01.2016 15:38, Michel Dänzer wrote:
> On 21.01.2016 14:31, Mario Kleiner wrote:
>> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>>> On 21.01.2016 05:32, Mario Kleiner wrote:
>>>>
>>>> So the problem is that AMDs hardware frame counters reset to
&g
On 21.01.2016 16:58, Daniel Vetter wrote:
> On Thu, Jan 21, 2016 at 03:41:27PM +0900, Michel Dänzer wrote:
>> On 21.01.2016 15:38, Michel Dänzer wrote:
>>> On 21.01.2016 14:31, Mario Kleiner wrote:
>>>> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>>>>
[ Trimming KDE folks from Cc ]
On 21.01.2016 19:09, Daniel Vetter wrote:
> On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote:
>> On 21.01.2016 16:58, Daniel Vetter wrote:
>>>
>>> Can you please point me at the vblank on/off jump bug please?
>>
>
1 - 100 of 204 matches
Mail list logo
