All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 204181] NULL pointer dereference regression in amdgpu
Date: Fri, 27 Sep 2019 20:18:47 +0000	[thread overview]
Message-ID: <bug-204181-2300-dC8faC0bO5@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-204181-2300@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=204181

--- Comment #56 from Sergey Kondakov (virtuousfox@gmail.com) ---
(In reply to Alex Deucher from comment #54)
> (In reply to Sergey Kondakov from comment #53)
> > Or any of these ?
> > options amdgpu cik_support=1 si_support=1 msi=1 disp_priority=2 dpm=1
> > runpm=1 sched_policy=1 compute_multipipe=1 vm_fragment_size=9 gartsize=1024
> > max_num_of_queues_per_device=65536 sched_hw_submission=32 sched_jobs=1024
> > job_hang_limit=8000 halt_if_hws_hang=1 vm_fault_stop=0 vm_update_mode=0
> > deep_color=1 gpu_recovery=1 lockup_timeout=2500,5000,8000,1000 ras_enable=1
> > mcbp=1 queue_preemption_timeout_ms=48 mes=1 hws_gws_support=1 discovery=1
> 
> remove all of those.  You should use the defaults unless you are
> specifically debugging something.

Then you may consider that I "specifically debugging" THIS. Because when I ask
these questions here or in freedesktop.org, I specifically hope for an factual
response from people with actual understanding and experience of how it works
and what to be a proper way to debug without guesswork, based on knowledge that
would compensate for the lack of meaningful documentation and one of the
highest entry-barriers in software (even corporate monstrosity like Intel can't
figure out GPUs still, market that is dominated by 2 oligopolists that run it
with impunity however they feel like it, after all). This third dereference
would be really hard to debug, though, because there is no clear reproduction
steps, UNLESS you KNOW where and how to look as a developer. Or are you all
just going to ignore the presence of kernel-crashing code because it "may" (or
may not) be not triggered by your defaults ?

So, can you actually tell which code-path may result in this or, better yet,
test it yourself so things like that just would not go into releases ?
The original dereference is triggered by mere presence of PageFlip which is on
by default, so blindly running developer defaults (you can see what exactly I
think about them here: https://bugzilla.kernel.org/show_bug.cgi?id=203703#c9
and c11) didn't help much anyone now, did it ?

Or can you at least explain on what exactly each of these options does, what
may be desired and undesired consequences and how your consensus about defaults
came to be ? Short summary (but not as short as modinfo) or links to mailing
list discussions maybe ? Because my goals (as they are for any desktop user)
are: minimal guaranteed latency (meaning, full aggressive preemption, lowest
scheduling granularity and strict RT priorities) of audio/video/input/network
pipelines under stress-load and in that specific order of priority, with
working fast fail-over or recovery instead of hangs and reboots.

If I'd be using defaults then I still would be sitting on 3,3Ghz (instead of
4Ghz + 2,4Ghz for MMU & cache) FX CPU, non-ECC RAM ran by literally retarded
AMD FX's MMU (you KNOW the one, the laughing stock of 2011-2017 x86 CPUs !) by
slow default JEDEC timings, ~200W (instead of down-clocked and/or
under-voltaged 90-120W) RX580 GPU (that would, no doubt, fry itself at some
point like my previous 6870 did) with slow memory timings, sluggish non-patched
kwin, 64ms of audio latency (instead of 8-12ms) and whole bunch of random
hangs/drops in audio, video stuttering and input delays/skips due to scheduling
priorities that are all other the place by default. So, no, thank you very
much, on that. And YOU should NOT be testing exclusively on defaults either.

(In reply to Tom Seewald from comment #55)
> (In reply to Sergey Kondakov from comment #53)
> > Created attachment 285209 [details]
> > dmesg_2019-09-26-amdgpu-old_dereference_on_patched_5.3.1
> > 
> > After about a day of uptime my patched 5.3.1 hanged during hours-long
> > Youtube video with dereference that is almost identical to the original
> one:
> 
> I don't believe the patches[1] have landed in a stable kernel release yet,
> at least going by the 5.3.1 change log[2] I don't see any reference to them.
> 
> [1] https://patchwork.freedesktop.org/series/64505/
> [2] https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.3.1

They seem to be in queue for 5.3.2:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=7f2f9d496c3b8809143f1fc14e8cb093cc981d78
BUT those only address #1 (PageFlip) dereference, NOT #2 (when vm_update_mode
not 0) and #3 !

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2019-09-27 20:18 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-15 10:11 [Bug 204181] New: NULL pointer dereference regression in amdgpu bugzilla-daemon
2019-07-15 13:07 ` [Bug 204181] " bugzilla-daemon
2019-07-15 15:43 ` bugzilla-daemon
2019-07-15 15:43 ` bugzilla-daemon
2019-07-15 15:45 ` bugzilla-daemon
2019-07-15 15:48 ` bugzilla-daemon
2019-07-15 15:50 ` bugzilla-daemon
2019-07-15 15:50 ` bugzilla-daemon
2019-07-15 15:53 ` bugzilla-daemon
2019-07-15 15:56 ` bugzilla-daemon
2019-07-15 15:58 ` bugzilla-daemon
2019-07-15 15:59 ` bugzilla-daemon
2019-07-16 15:29 ` bugzilla-daemon
2019-07-16 16:36 ` bugzilla-daemon
2019-07-16 16:52 ` bugzilla-daemon
2019-07-16 16:55 ` bugzilla-daemon
2019-07-24 18:33 ` bugzilla-daemon
2019-07-25 10:52 ` bugzilla-daemon
2019-07-25 14:21 ` bugzilla-daemon
2019-07-25 15:42 ` bugzilla-daemon
2019-07-25 15:50 ` bugzilla-daemon
2019-07-26 12:23 ` bugzilla-daemon
2019-07-26 16:02 ` bugzilla-daemon
2019-07-30 21:41 ` bugzilla-daemon
2019-07-31 16:28 ` bugzilla-daemon
2019-08-01  6:13 ` bugzilla-daemon
2019-08-02  2:21 ` bugzilla-daemon
2019-08-04  5:17 ` bugzilla-daemon
2019-08-07 17:43 ` bugzilla-daemon
2019-08-14  6:43 ` bugzilla-daemon
2019-08-14 19:06 ` bugzilla-daemon
2019-08-15 22:05 ` bugzilla-daemon
2019-08-17  5:13 ` bugzilla-daemon
2019-08-19 13:39 ` bugzilla-daemon
2019-08-19 15:11 ` bugzilla-daemon
2019-08-21 13:38 ` bugzilla-daemon
2019-08-21 14:37 ` bugzilla-daemon
2019-08-21 15:27 ` bugzilla-daemon
2019-08-21 18:36 ` bugzilla-daemon
2019-08-21 19:28 ` bugzilla-daemon
2019-08-21 21:39 ` bugzilla-daemon
2019-08-21 21:51 ` bugzilla-daemon
2019-08-22 13:14 ` bugzilla-daemon
2019-08-23 21:02 ` bugzilla-daemon
2019-08-24  9:43 ` bugzilla-daemon
2019-08-26  5:32 ` bugzilla-daemon
2019-09-04  4:50 ` bugzilla-daemon
2019-09-06 10:37 ` bugzilla-daemon
2019-09-06 10:38 ` bugzilla-daemon
2019-09-20  1:58 ` bugzilla-daemon
2019-09-20 13:19 ` bugzilla-daemon
2019-09-20 14:04 ` bugzilla-daemon
2019-09-21  5:26 ` bugzilla-daemon
2019-09-27  3:50 ` bugzilla-daemon
2019-09-27 12:50 ` bugzilla-daemon
2019-09-27 13:19 ` bugzilla-daemon
2019-09-27 20:18 ` bugzilla-daemon [this message]
2019-09-28  0:07 ` bugzilla-daemon
2019-09-29 18:10 ` bugzilla-daemon
2019-09-29 21:54 ` bugzilla-daemon
2019-09-30  2:07 ` bugzilla-daemon
2019-09-30  2:09 ` bugzilla-daemon
2019-11-05 19:38 ` bugzilla-daemon
2019-12-12 19:04 ` bugzilla-daemon
2020-06-19  3:13 ` bugzilla-daemon
2020-06-19  3:14 ` bugzilla-daemon
2020-07-26 22:49 ` bugzilla-daemon
2020-07-26 22:50 ` bugzilla-daemon
2022-11-10  4:02 ` bugzilla-daemon
2022-12-23  9:17 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-204181-2300-dC8faC0bO5@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.