Hi, Paul,
On Thu, 13 Apr 2023 at 17:21, Paul E. McKenney wrote:
>
> Been there, done that!
>
> And actually, it is kind of reassuring that the Linux kernel avoids
> tens-of-milliseocnds latency blows in the common case on your system.
Especially since we're talking about a HZ=100 non-preemptive
Hi, Paul,
On Thu, 13 Apr 2023 at 15:43, Paul E. McKenney wrote:
>
> My guess would be that you have CONFIG_RCU_EXP_CPU_STALL_TIMEOUT set to
> some small non-zero number, for example, you might have set up a recent
> Android .config or some such. The default of zero would give you about
> 21
Hi, Jani,
On Wed, 12 Apr 2023 at 10:28, Jani Nikula wrote:
>
> Please file a bug at fdo gitlab [1]. Add drm.debug=0xe and maybe
> log_buf_len=4M or similar kernel parameters, and attach dmesg all the
> way from boot to reproducing the problem.
Sure, will do, thanks!
> How long is "for some
Hi, everyone,
I apologise in advance if I've sent this to {too many, the wrong}
people. For some time now, I've been getting sporadic (in about one
out of five boots) DRM-related RCU complaints on an Ivy Bridge-based
(Core i7-3720QM) Mac Mini. Call trace (on Linux 6.3-rc6) follows:
[
Hi again, everyone.
So, while preparing to file the bug report with the requested
information, I got a trace completely unrelated to DRM (on a swapon
call, it seems).
[4.868340] rcu: INFO: rcu_sched detected expedited stalls on
CPUs/tasks: { 4- } 3 jiffies s: 265 root: 0x10/.
[
Hi, Christian,
On Wed, 20 May 2020 at 16:00, Christian König
wrote:
>
> So I've used an ancient system (32bit) to setup a test box for this.
>
>
> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
> 15 years old.
Oh, I have one of those in box somewhere, but no AGP
On Wed, 13 May 2020 at 14:44, Christian Zigotzky wrote:
>
> OpenGL version string: 1.5 Mesa 7.6
> OpenGL version string: 1.3 Mesa 7.2
>
> Screenshots:
>
> - http://www.supertuxkart.de/stk07ubuntu910ppc.png
> - http://www.supertuxkart.de/opensuse111-stk073.jpg
Those are *extremely old* (and I
On Wed, 13 May 2020 at 11:58, Michel Dänzer wrote:
>
> How do you know you're hitting that particular issue?
Sorry, somehow I misread that. I was still thinking of the AGP hangs.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Wed, 13 May 2020 at 08:19, Daniel Vetter wrote:
>
> i915 is even worse, we manually mess around with clflush. In
> userspace. So really there's 2 axis for dma memory: coherent vs.
> non-coherent (which is something the dma-api somewhat exposed), i.e.
> do you need to clflush or not, and cached
On Wed, 13 May 2020 at 11:27, Michel Dänzer wrote:
>
> The only theoretical problem there was that the kernel still had a
> cacheable mapping of the same memory, and any access via that (e.g.
> prefetch due to access to a neighbouring page) could trigger a machine
> check. But I don't remember
On Tue, 12 May 2020 at 08:58, Michel Dänzer wrote:
>
> FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a big
> performance difference between AGP and PCI GART. The latter was sort of
> usable for normal desktop operation, but not so much for OpenGL apps
> (which were usable
On Tue, 12 May 2020 at 17:38, Daniel Vetter wrote:
>
> Otherwise all agree, agp is a mighty mess and essentially just
> crapshot outside of x86. It kinda worked for the much more static
> allocations for dri1, but with in-kernel memory managers all the cache
> flushing issues showed up big time
A segunda, 11/05/2020, 21:21, Alex Deucher escreveu:
>
>
> Note there is no loss of functionality here, at least on radeon
> hardware. It just comes down to which MMU gets used for access to
> system memory, the AGP MMU on the chipset or the MMU built into the
> GPU. On powerpc hardware, AGP
13 matches
Mail list logo
