Re: Remaining BKL users, what to do

On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote: The big kernel lock is gone from almost all code in linux-next, this is the status of what I think will happen to the remaining users: kernel/trace/blktrace.c: Should be easy. Ingo? Steven? Jens, Git blame shows this to be your

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote: On Tue, Oct 19, 2010 at 12:24 PM, Greg KH g...@kroah.com wrote: So, there is no need for the i830 driver? Can it just be removed because i915 works instead? No because it provides a different userspace ABI to the i915 driver to a

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote: On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote: I might be able to find some hardware still lying around here that uses an i810. Not sure unless I go hunting it. But I get the impression that if the kernel is a single-CPU

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Tue, 2010-10-19 at 15:36 +0200, Arnd Bergmann wrote: [trimming Cc list] On Tuesday 19 October 2010, Steven Rostedt wrote: I think we also need to cover the PREEMPT case too. But that could be a compile time check, since you can't boot a preempt kernel and make it non preempt. Right

Re: (Short?) merge window reminder

On Mon, May 23, 2011 at 01:21:26PM -0700, Randy Dunlap wrote: They tell him to avoid the question to which 42 is the answer. What 2.6 Linux kernel version was the last before 3.0? -- Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: Problems with videos and i915 driver

On Sun, 2011-10-16 at 14:01 -0400, Steven Rostedt wrote: For the full dmesg: http://rostedt.homelinux.com/private/vid-crash/dmesg Another clue that looks nasty is this line: [0.427196] pci_root PNP0A08:00: address space collision: host bridge window [mem 0x000c8000-0x000d

Problems with videos and i915 driver

Hi Keith, I just upgraded my wife's computer with a new motherboard which has a (lspci -vv): Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 844d Control: I/O+ Mem+ BusMaster+ SpecCycle-

Re: Problems with videos and i915 driver

On Mon, 2011-10-17 at 19:02 +0200, Daniel Vetter wrote: Thanks. Your userspace is issueing MI_WAIT_SCANLINES cmds to the gpu, which just doesn't work. Can you please upgrade xf86-video-intel to the latest released version and check whether it works. Generally userspace with that bug is

Re: Problems with videos and i915 driver

On Mon, 2011-10-17 at 19:52 +0200, Daniel Vetter wrote: On Mon, Oct 17, 2011 at 01:06:59PM -0400, Steven Rostedt wrote: It's running Fedora 14, and I rather avoid Gnome3 and systemd, which prevents me from moving her to Fedora 15. If F14 does not provide the necessary updates, I'll move her

RE: [BUG] Warning at radeon_object.c:236 with latest Linus kernel

and pasting patches out of the browser. Tested-by: Steven Rostedt rost...@goodmis.org Thanks! -- Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] Warning at radeon_object.c:236 with latest Linus kernel

I have a test box that is triggering the following: [ cut here ] WARNING: at /home/rostedt/work/git/linux-trace.git/drivers/gpu/drm/radeon/radeon_object.c:236 radeon_bo_pin_restricted+0x67/0x137 [radeon]() Hardware name: Precision WorkStation 470 Modules linked in:

Re: [BUG] Warning at radeon_object.c:236 with latest Linus kernel

On Tue, 2012-03-27 at 20:14 -0400, Steven Rostedt wrote: You can get the full dmesg here: http://rostedt.homelinux.com/private/dmesg-bxf-20120327 And the config is here: http://rostedt.homelinux.com/private/config-bxf-20120327 -- Steve ___ dri

Re: [PATCHv4 3/8] gpu: host1x: Add channel support

On Fri, 2012-12-21 at 13:39 +0200, Terje Bergstrom wrote: diff --git a/include/trace/events/host1x.h b/include/trace/events/host1x.h index d98d74c..e087910 100644 --- a/include/trace/events/host1x.h +++ b/include/trace/events/host1x.h @@ -37,6 +37,214 @@ DECLARE_EVENT_CLASS(host1x,

Re: Including drm-intel tree to linux-next

On Thu, 2013-02-14 at 15:19 +0100, Borislav Petkov wrote: On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote: Hi Steven, Since about a year ago we've switched drm/i915 to buffer around 2 weeks worth of patches so that we can do decent QA before breaking everyone's tree when

Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, Apr 04, 2013 at 06:38:36PM +0200, Peter Zijlstra wrote: On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the wait times of older task. No, imagine the following: struct ww_mutex A, B; struct mutex C;

Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote: On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: The thing is now that you're not expected to hold these locks for a long time - if you need to synchronously stall while holding a lock performance will go down the

Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Tue, Apr 02, 2013 at 06:59:14PM +0200, Peter Zijlstra wrote: So how about we call the thing something like: struct ww_mutex; /* wound/wait */ Reading this I can't help but think of Elmer Fudd saying Round Robin as Wound Wobin -- Steve int mutex_wound_lock(struct ww_mutex *); /*

Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, Apr 04, 2013 at 06:56:58PM +0200, Daniel Vetter wrote: I think for starters we need to have a slightly more interesting example: 3 threads O, M, Y: O has the oldest ww_age/ticket, Y the youngest, M is in between. 2 ww_mutexes: A, B Y has already acquired ww_mutex A, M has

Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7

On Wed, 25 Sep 2013 06:32:10 +0200 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: I assume if a spin_lock_irqsave doesn't really disable interrupts on a RT kernel with normal spinlocks then local_irq_disable won't really disable interrupts either? That is incorrect. On PREEMPT_RT,

Re: BUG: sleeping function called from invalid context on 3.10.10-rt7

Sorry for the late reply, I was at Linux Plumbers, and had a bunch of stuff to catch up on when I returned. On Sat, 21 Sep 2013 00:07:36 +0200 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: Steven, would it then be acceptable to convert that faster lock into a raw_spinlock_t or is

Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7

On Wed, 25 Sep 2013 10:49:36 +0300 Ville Syrjälä ville.syrj...@linux.intel.com wrote: The preempt_disable/enable is not needed. The spinlock serves the same purpose already. As stated, that was only for the -rt patch, as spin_lock_irqsave does not disable preemption nor does it even disable

Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7

On Wed, 25 Sep 2013 06:32:10 +0200 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: But given the new situation, your proposal is great! If we push the clock readouts into the get_scanoutpos routine, we can make this robust without causing grief for the rt people and without the need

Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7

On Fri, 11 Oct 2013 12:18:00 +0200 Sebastian Andrzej Siewior bige...@linutronix.de wrote: * Mario Kleiner | 2013-09-26 18:16:47 [+0200]: Good! I will do that. Thanks for clarifying the irq and constraints on raw locks in the other thread. Are there any suggestions for now?

Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7

On Fri, 11 Oct 2013 15:30:22 +0200 Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 10/11/2013 02:37 PM, Steven Rostedt wrote: On Fri, 11 Oct 2013 12:18:00 +0200 Sebastian Andrzej Siewior bige...@linutronix.de wrote: * Mario Kleiner | 2013-09-26 18:16:47 [+0200]: Good! I

[RFC][PATCH] tracing/drm: Remove unused TRACE_SYSTEM_STRING define

RING __stringify(TRACE_SYSTEM) Although, I can not find its use anywhere. I could simply use another name, but if this macro is not being used, it should be removed. Cc: Alex Deucher Cc: Christian König Cc: David Airlie Cc: Daniel Vetter Cc: Jani Nikula Reported-by: kbuild test robot Signed-off-by

linux-next: build failure after merge of the drm-intel tree

On Wed, 19 Mar 2014 11:53:50 +1100 Stephen Rothwell wrote: > Caused by commit a25ca17c1eac ("drm/i915: Do not dereference pointers > from ring buffer in evict event"). > > I have used the drm-intel tree from next-20140318 for today. > Bah! I'm still suffering from jet lag (just came back

[RESUBMIT] [PATCH] Replace mentions of "list_struct" to "list_head"

On Fri, 14 Nov 2014 05:09:55 +0400 Andrey Utkin wrote: > There's no such thing as "list_struct". I guess there isn't. > > Signed-off-by: Andrey Utkin Acked-by: Steven Rostedt -- Steve > --- > drivers/gpu/drm/radeon/mkregtable.c | 24

[WARNING - 3.14-rc2] i915: pipe_off wait timed out

I get the following splat in my tests running 3.14-rc2: [3.955123] WARNING: CPU: 0 PID: 1 at /work/autotest/nobackup/linux-test.git/drivers/gpu/drm/i915/intel_display.c:857 intel_wait_for_pipe_off+0x17a/0x2d0() [3.955124] pipe_off wait timed out [3.955127] CPU: 0 PID: 1 Comm:

[BUG] Warning at radeon_object.c:236 with latest Linus kernel

ly cut and pasting patches out of the browser. Tested-by: Steven Rostedt Thanks! -- Steve

[BUG] Warning at radeon_object.c:236 with latest Linus kernel

I have a test box that is triggering the following: [ cut here ] WARNING: at /home/rostedt/work/git/linux-trace.git/drivers/gpu/drm/radeon/radeon_object.c:236 radeon_bo_pin_restricted+0x67/0x137 [radeon]() Hardware name: Precision WorkStation 470 Modules linked in:

[BUG] Warning at radeon_object.c:236 with latest Linus kernel

On Tue, 2012-03-27 at 20:14 -0400, Steven Rostedt wrote: > You can get the full dmesg here: > > http://rostedt.homelinux.com/private/dmesg-bxf-20120327 And the config is here: http://rostedt.homelinux.com/private/config-bxf-20120327 -- Steve

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Tue, Apr 02, 2013 at 06:59:14PM +0200, Peter Zijlstra wrote: > > So how about we call the thing something like: > > struct ww_mutex; /* wound/wait */ Reading this I can't help but think of Elmer Fudd saying "Round Robin" as "Wound Wobin" -- Steve > > int mutex_wound_lock(struct

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, Apr 04, 2013 at 06:38:36PM +0200, Peter Zijlstra wrote: > On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: > > Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the > > wait > > times of older task. > > No, imagine the following: > > struct ww_mutex A, B; > struct

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote: > On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: > > The thing is now that you're not expected to hold these locks for a > > long > > time - if you need to synchronously stall while holding a lock > > performance > > will go

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, Apr 04, 2013 at 06:56:58PM +0200, Daniel Vetter wrote: > > I think for starters we need to have a slightly more interesting example: > > 3 threads O, M, Y: O has the oldest ww_age/ticket, Y the youngest, M > is in between. > 2 ww_mutexes: A, B > > Y has already acquired ww_mutex A, M

Including drm-intel tree to linux-next

On Thu, 2013-02-14 at 15:19 +0100, Borislav Petkov wrote: > On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote: > > Hi Steven, > > > > Since about a year ago we've switched drm/i915 to buffer around 2 > > weeks worth of patches so that we can do decent QA before breaking > > everyone's

[Intel-gfx] [Regression] WARNING: drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object

On Mon, Feb 23, 2015 at 11:12:39PM +0300, Andrey Skvortsov wrote: > > This warning is moved from linux-next to v4.0-rc1 now. After system boot is > just a black screen. > I ssh'ed into the machine and saved the log. I attached updated dmesg.log > with drm.debug=6. Hopefully it helps. > If you

[Intel-gfx] [Regression] WARNING: drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object

On Mon, 16 Mar 2015 17:43:33 +0100 Daniel Vetter wrote: > Is linux-next also affected or is this just a case of i915 maintainers > having failed to push the right patch to -fixes? I just confirmed, linux-next boots without the warning. > > I'll try to figure out what fell apart here

[Intel-gfx] [Regression] WARNING: drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object

Any movement on this? I still get this warning on 4.0-rc4. -- Steve On Thu, 5 Mar 2015 09:27:28 -0500 Steven Rostedt wrote: > On Mon, Feb 23, 2015 at 11:12:39PM +0300, Andrey Skvortsov wrote: > > > > This warning is moved from linux-next to v4.0-rc1 now. After system bo

[Intel-gfx] [Regression] WARNING: drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object

On Tue, 17 Mar 2015 08:53:21 +0100 Daniel Vetter wrote: > Can you please cherry pick 42a7b088127f (\"drm/i915: Make sure the primary > plane is enabled before reading out the fb state\") from -next to 4.0-rc > to test whether this is indeed the difference in ducttape? I cherry-picked that patch

[WARNING 4.1-rc2] i915: Unclaimed register detected before writing to register 0xc4040

[ cut here ] WARNING: CPU: 2 PID: 0 at /work/autotest/nobackup/linux-test.git/drivers/gpu/drm/i915/intel_uncore.c:566 hsw_unclaimed_reg_debug.isra.10+0x6c/0x84() Unclaimed register detected before writing to register 0xc4040 Modules linked in: microcode r8169 CPU: 2

[Intel-gfx] [WARNING 4.1-rc2] i915: Unclaimed register detected before writing to register 0xc4040

On Fri, 8 May 2015 08:55:46 +0200 Daniel Vetter wrote: > On Thu, May 7, 2015 at 9:40 PM, Steven Rostedt wrote: > Please retry with snd-hda-intel blacklisted. At least last time I > checked that was the only culprit left, i915 is just the messenger > here. The other one was stupid

[Intel-gfx] [WARNING 4.1-rc2] i915: Unclaimed register detected before writing to register 0xc4040

On Fri, 8 May 2015 12:18:10 -0400 Steven Rostedt wrote: > On Fri, 8 May 2015 12:08:31 -0400 > Steven Rostedt wrote: > > > > Maybe it's my bios still (it is an older box). I'll just block out > > compiling in SND_HDA_INTEL, so that it doesn't break my tests (th

[Intel-gfx] [WARNING 4.1-rc2] i915: Unclaimed register detected before writing to register 0xc4040

On Fri, 8 May 2015 12:08:31 -0400 Steven Rostedt wrote: > Maybe it's my bios still (it is an older box). I'll just block out > compiling in SND_HDA_INTEL, so that it doesn't break my tests (they > fail on a WARNING). Hmm, right after I posted this I triggered the Call Tr

[PATCHv4 3/8] gpu: host1x: Add channel support

On Fri, 2012-12-21 at 13:39 +0200, Terje Bergstrom wrote: > diff --git a/include/trace/events/host1x.h b/include/trace/events/host1x.h > index d98d74c..e087910 100644 > --- a/include/trace/events/host1x.h > +++ b/include/trace/events/host1x.h > @@ -37,6 +37,214 @@ DECLARE_EVENT_CLASS(host1x, >

[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote: > On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote: > > So, there is no need for the i830 driver? Can it just be removed > > because i915 works instead? > > No because it provides a different userspace ABI to the i915 driver to > a different

[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote: > On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote: > > > I might be able to find some hardware still lying around here that uses an > > > i810. Not sure unless I go hunting it. But I get the impression that if > > > the kernel is a

[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Tue, 2010-10-19 at 15:36 +0200, Arnd Bergmann wrote: > [trimming Cc list] > > On Tuesday 19 October 2010, Steven Rostedt wrote: > > I think we also need to cover the PREEMPT case too. But that could be a > > compile time check, since you can't boot a preempt kernel and ma

Remaining BKL users, what to do

On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote: > The big kernel lock is gone from almost all code in linux-next, this is > the status of what I think will happen to the remaining users: > kernel/trace/blktrace.c: > Should be easy. Ingo? Steven? > Jens, Git blame shows this to be

(Short?) merge window reminder

On Mon, May 23, 2011 at 01:21:26PM -0700, Randy Dunlap wrote: > > They tell him to avoid the question to which 42 is the answer. What 2.6 Linux kernel version was the last before 3.0? -- Steve

Problems with videos and i915 driver

On Sun, 2011-10-16 at 14:01 -0400, Steven Rostedt wrote: > For the full dmesg: > > http://rostedt.homelinux.com/private/vid-crash/dmesg Another clue that looks nasty is this line: [0.427196] pci_root PNP0A08:00: address space collision: host bridge window [mem 0x000c8000-0

Problems with videos and i915 driver

On Sun, 2011-10-16 at 14:01 -0400, Steven Rostedt wrote: You can get the config from here: http://rostedt.homelinux.com/private/vid-crash/config -- Steve

Problems with videos and i915 driver

Hi Keith, I just upgraded my wife's computer with a new motherboard which has a (lspci -vv): Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 844d Control: I/O+ Mem+ BusMaster+ SpecCycle-

Problems with videos and i915 driver

On Mon, 2011-10-17 at 10:55 +0200, Daniel Vetter wrote: > On Sun, Oct 16, 2011 at 02:01:08PM -0400, Steven Rostedt wrote: > > [ 102.695526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer > > elapsed... GPU hung > > [ 102.695538] [drm] capturing error event; look

Problems with videos and i915 driver

On Mon, 2011-10-17 at 19:02 +0200, Daniel Vetter wrote: > Thanks. Your userspace is issueing MI_WAIT_SCANLINES cmds to the gpu, > which just doesn't work. Can you please upgrade xf86-video-intel to the > latest released version and check whether it works. > > Generally userspace with that bug is

Problems with videos and i915 driver

On Mon, 2011-10-17 at 19:52 +0200, Daniel Vetter wrote: > On Mon, Oct 17, 2011 at 01:06:59PM -0400, Steven Rostedt wrote: > > It's running Fedora 14, and I rather avoid Gnome3 and systemd, which > > prevents me from moving her to Fedora 15. If F14 does not provide the > > ne

Re: [PATCH] drm/armada: Include current dir on CFLAGS for armada trace

On Mon, 16 Jan 2017 23:53:53 +0200 Laurent Pinchart wrote: > Hi Gustavo, > > (CC'ing Steven) Sorry for the very late reply. I somehow missed this email. But I figured I would reply to it anyway. At least for knowledge for future changes. > > On Monday 16

Re: tracing, dma-buf: Remove unused trace event dma_fence_annotate_wait_on

On Mon, 16 Oct 2017 11:15:45 +0200 Daniel Vetter <dan...@ffwll.ch> wrote: > On Fri, Oct 13, 2017 at 05:27:59PM +0200, Christian König wrote: > > Am 13.10.2017 um 16:06 schrieb Steven Rostedt: > > > From: Steven Rostedt (VMware) <rost...@goodmis.org> > > >

tracing, dma-buf: Remove unused trace event dma_fence_annotate_wait_on

From: Steven Rostedt (VMware) <rost...@goodmis.org> Commit e941759c74 ("fence: dma-buf cross-device synchronization") added trace event fence_annotate_wait_on, but never used it. It was renamed to dma_fence_annotate_wait_on by commit f54d186700 ("dma-buf: Rename stru

[PATCH] tracing, drm/i915: Remove unused trace events

From: Steven Rostedt (VMware) <rost...@goodmis.org> Commit ce8daef3580 ("drm/i915: Remove dead i915_gem_evict_everything()") removed the only instances of trace_i915_gem_evict_everything. Commit a7b9761d0a ("drm/i915: Split i915_gem_flush_ring() into seperate invalidate/

Re: tracing, dma-buf: Remove unused trace event dma_fence_annotate_wait_on

On Mon, 16 Oct 2017 20:49:11 +0530 Sumit Semwal wrote: > I suspect it should be ok; please do feel free to add my > Acked-by: Sumit Semwal > if you wish :) Done. Thanks! -- Steve ___ dri-devel

Re: [PATCH v2 11/11] docs: fix broken references with multiple hints

cepoint.h > +++ b/include/linux/tracepoint.h > @@ -4,7 +4,7 @@ > /* > * Kernel Tracepoint API. > * > - * See Documentation/trace/tracepoints.txt. > + * See Documentation/trace/tracepoints.rst. > * > * Copyright (C) 2008-2014

Re: [PATCH v3 04/27] docs: fix broken references with multiple hints

on/trace/tracepoints.txt) can be used without > +Tracepoints (see Documentation/trace/tracepoints.rst) can be used without > creating custom kernel modules to register probe functions using the event > tracing infrastructure. > Acked-by: Steven Rostedt (VMware) -- Steve

Re: [PATCH v3 2/3] fbcon: Call WARN_CONSOLE_UNLOCKED() where applicable

On Tue, 26 Jun 2018 15:55:34 +0200 Hans de Goede wrote: > Replace comments about places where the console lock should be held with > calls to WARN_CONSOLE_UNLOCKED() to assert that it is actually held. Why replace the comments? I prefer them, even with the WARN. The reason is, when using

Re: [PATCH v4 0/3] console/fbcon: Add support for deferred console takeover

he fbdev tree? > > Changelog: > > Changes in v4: > -Keep the comments about which fbcon functions need locks in place > For 1 and 2: Acked-by: Steven Rostedt (VMware) I'll let others handle patch 3. -- Steve ___ dri-devel mailing list dr

Re: [PATCH v3 1/2] console: Replace #if 0 with atomic var 'ignore_console_lock_warning'

gt; decrement it after leaving the CS. Setting ignore_console_lock_warning > is only for debugging. Regular operation should not manipulate it. > > Acknoledgements: This patch is based on an earlier version by Steven > Rostedt. The use of atomic increment/decrement was suggested by Pe

Re: [PATCHv3] lib/ratelimit: Lockless ratelimiting

On Fri, 20 Jul 2018 16:33:36 +0100 Dmitry Safonov wrote: > On Fri, 2018-07-20 at 17:09 +0200, Petr Mladek wrote: > > > > On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote: > > > > > Currently ratelimit_state is protected with spin_lock. If the > > > > > .lock > > > > > is > > > > > taken

Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/

On Thu, 6 Sep 2018 09:58:04 -0600 Jonathan Corbet wrote: > Thanks, > > jon (who is increasingly inclined to apply this patch) As Colin Kaepernick now says... "Just do it!" ;-) -- Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/

On Tue, 4 Sep 2018 13:30:30 +0200 Pavel Machek wrote: > I'd say this is still quite valueable, and it might be worth fixing, > rather then removing completely. I agree. Perhaps we should have a 00-DESCRIPTION file in each directory, and each file could start with a: DESCRIPTION: and then

Re: [PATCH v5 2/3] fbcon: Call WARN_CONSOLE_UNLOCKED() where applicable

ad? -- Steve > Best regards > Thomas > > > Acked-by: Steven Rostedt (VMware) > > Reviewed-by: Daniel Vetter > > Reviewed-by: Sergey Senozhatsky > > Signed-off-by: Hans de Goede > > --- > > Changes in v3: > > -New patch in v3 of this patchset >

Re: [PATCH v5 2/3] fbcon: Call WARN_CONSOLE_UNLOCKED() where applicable

On Wed, 11 Jul 2018 19:56:02 +0200 Daniel Vetter wrote: > > Have you seen Steven's suggestion which he send about the same time > > as your mail I'm replying to here ? I personally think that doing > > something like that makes sense (for as long as we have the need > > for the

Re: [PATCH v5 2/3] fbcon: Call WARN_CONSOLE_UNLOCKED() where applicable

On Wed, 11 Jul 2018 17:35:10 +0200 Hans de Goede wrote: > OK, so if we don't remove it, we should probably make it so that it > can be used without triggering any WARN_ONs, which would require changing > the existing WARN_CONSOLE_UNLOCKED() so that the calls from > drivers/tty/vt/vt.c > also do

Re: [PATCH v2] console: Replace #if 1 with a bool to ignore

On Thu, 12 Jul 2018 09:29:38 -0400 Steven Rostedt wrote: > From: Steven Rostedt (VMware) > > There's been discussion on the fb list about the addition of > WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when > the fb module is loaded with lockless_register

[PATCH v2] console: Replace #if 1 with a bool to ignore

From: Steven Rostedt (VMware) There's been discussion on the fb list about the addition of WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when the fb module is loaded with lockless_register_fb the console lock is not taken for debugging reasons. With the addition

Re: [PATCH v5 3/3] console/fbcon: Add support for deferred console takeover

On Wed, 4 Jul 2018 01:13:27 +0900 Sergey Senozhatsky wrote: > On (06/28/18 11:03), Hans de Goede wrote: > [..] > > > > +config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER > > + bool "Framebuffer Console Deferred Takeover" > > + depends on FRAMEBUFFER_CONSOLE=y && DUMMY_CONSOLE=y > > +

Re: [trivial PATCH V2] treewide: Align function definition open/close braces

mt, > ...) > EXPORT_SYMBOL_GPL(__trace_bprintk); > > int __ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap) > - { > +{ > if (unlikely(!fmt)) > return 0; > Acked-by: Steven Rostedt (VMware) <rost...@goodmis.org> -- Steve

Re: [PATCH v3] fbcon: Silence fbcon logo on 'quiet' boots

con can be built as part of a module so >export console_printk > >Signed-off-by: Prarit Bhargava >Cc: Hans de Goede >Cc: Marko Myllynen >Cc: Steven Rostedt (VMware) >Cc: Bartlomiej Zolnierkiewicz >Cc: Kees Cook >Cc: Daniel Vetter >Cc: Thierry Reding >Cc: Y

Re: [PATCH v3] fbcon: Silence fbcon logo on 'quiet' boots

con can be built as part of a module so >export console_printk > >Signed-off-by: Prarit Bhargava >Cc: Hans de Goede >Cc: Marko Myllynen >Cc: Steven Rostedt (VMware) >Cc: Bartlomiej Zolnierkiewicz >Cc: Kees Cook >Cc: Daniel Vetter >Cc: Thierry Reding >Cc: Y

Re: [RFC v3 11/19] kunit: add Python libraries for handing KUnit config and kernel

On Tue, 11 Dec 2018 15:09:26 +0100 Petr Mladek wrote: > > We have liburcu already, which is good. The main sticking points are: > > > > - printk has started adding a lot of %pX enhancements which printf > >obviously doesn't know about. > > I wonder how big problem it is and if it is

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

On Fri, 30 Nov 2018 12:55:21 -0800 Jarkko Sakkinen wrote: > On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote: > > On Fri, 30 Nov 2018, Kees Cook wrote: > > > > > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen > > > wrote: > > > > > > > > In order to comply with the CoC,

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

On Fri, 30 Nov 2018 20:39:01 + Abuse wrote: > On Friday, 30 November 2018 20:35:07 GMT David Miller wrote: > > From: Jens Axboe > > Date: Fri, 30 Nov 2018 13:12:26 -0700 > > > > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote: > > >> On Fri, 30 Nov 2018, Kees Cook wrote: > > >> > >

Re: [PATCH v13 04/20] mm, arm64: untag user pointers passed to memory syscalls

On Thu, 28 Mar 2019 19:10:07 +0100 Andrey Konovalov wrote: > > > Signed-off-by: Andrey Konovalov > > > --- > > > ipc/shm.c | 2 ++ > > > mm/madvise.c | 2 ++ > > > mm/mempolicy.c | 5 + > > > mm/migrate.c | 1 + > > > mm/mincore.c | 2 ++ > > > mm/mlock.c | 5 + > > >

Re: [patch V2 14/29] dm bufio: Simplify stack trace retrieval

On Thu, 18 Apr 2019 14:11:44 +0200 Alexander Potapenko wrote: > On Thu, Apr 18, 2019 at 1:54 PM Thomas Gleixner wrote: > > > > On Thu, 18 Apr 2019, Alexander Potapenko wrote: > > > On Thu, Apr 18, 2019 at 11:06 AM Thomas Gleixner > > > wrote: > > > > -

Re: [patch V2 20/29] tracing: Simplify stacktrace retrieval in histograms

[ Added Tom Zanussi ] On Thu, 18 Apr 2019 10:41:39 +0200 Thomas Gleixner wrote: > The indirection through struct stack_trace is not necessary at all. Use the > storage array based interface. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt Looks fine to me Acked-by:

Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro

On Thu, 23 May 2019 08:10:44 -0700 Linus Torvalds wrote: > On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote: > > > > +# define roundup_64(x, y) (\ > > +{ \ > >

[RFC][PATCH] kernel.h: Add generic roundup_64() macro

From: Steven Rostedt (VMware) In discussing a build failure on x86_32 due to the use of roundup() on a 64 bit number, I realized that there's no generic equivalent roundup_64(). It is implemented in two separate places in the kernel, but there really should be just one that all can use

Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro

On Thu, 23 May 2019 09:51:29 -0700 Linus Torvalds wrote: > On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote: > > > > I haven't yet tested this, but what about something like the following: > > So that at least handles the constant case that the normal "roun

Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro

On Fri, 24 May 2019 16:11:14 +0100 Roger Willcocks wrote: > On 23/05/2019 16:27, Steven Rostedt wrote: > > > > I haven't yet tested this, but what about something like the following: > > > > ...perhaps forget about the constant check, and just force

Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro

On Fri, 24 May 2019 19:30:45 +0300 Nikolay Borisov wrote: > > Yes I do. I corrected it in my next email. > > > > http://lkml.kernel.org/r/20190523133648.591f9...@gandalf.local.home > > Or perhaps just using is_power_of_2 from include/linux/log2.h ? Even better. Thanks, -- Steve

Re: [patch V2 01/29] tracing: Cleanup stack trace code

On Thu, 18 Apr 2019 23:14:45 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 18 Apr 2019, Josh Poimboeuf wrote: > > > On Thu, Apr 18, 2019 at 10:41:20AM +0200, Thomas Gleixner wrote: > > > - Remove the extra array member of stack_dump_trace[]. It's not required > > > as > > > the stack

Re: [patch V2 01/29] tracing: Cleanup stack trace code

o begin with. I think I copied something else that couldn't do it this way for some reason and didn't put any brain power behind the copy. :-/ But that was back in 2008 so I blame it on being "young and stupid" ;-) Other then the above nit and removing the unneeded +1 in max_entri

Re: [patch V2 01/29] tracing: Cleanup stack trace code

On Thu, 18 Apr 2019 17:24:43 -0400 Steven Rostedt wrote: > I believe it was for historical leftovers (there was a time it was > required), and left there for "paranoid" sake. But let me apply the > patch and see if it is really needed. I removed the +1 on the

Re: [patch V2 01/29] tracing: Cleanup stack trace code

On Fri, 19 Apr 2019 00:44:17 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 18 Apr 2019, Steven Rostedt wrote: > > On Thu, 18 Apr 2019 10:41:20 +0200 > > Thomas Gleixner wrote: > > > > > @@ -412,23 +404,20 @@ stack_trace_sysctl(struct ctl_table *tab > >

Re: [patch V2 20/29] tracing: Simplify stacktrace retrieval in histograms

On Thu, 18 Apr 2019 14:58:55 -0500 Tom Zanussi wrote: > > Tom, > > > > Can you review this too? > > Looks good to me too! > > Acked-by: Tom Zanussi > Would you be OK to upgrade this to a Reviewed-by tag? Thanks! -- Steve ___ dri-devel mailing

Re: [patch V2 21/29] tracing: Use percpu stack trace buffer more intelligently

e cpu buffer > for stack retrieval and avoids the fixed length allocation along with the > conditional execution pathes. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt > --- > kernel/trace/trace.c | 77 > +-- &

Re: [patch V2 21/29] tracing: Use percpu stack trace buffer more intelligently

On Thu, 18 Apr 2019 17:43:59 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 18 Apr 2019, Steven Rostedt wrote: > > On Thu, 18 Apr 2019 10:41:40 +0200 > > Thomas Gleixner wrote: > > > -static DEFINE_PER_CPU(struct ftrace_stack, ftrace_stack); > > > +/*

Re: [patch V2 22/29] tracing: Make ftrace_trace_userstack() static and conditional

On Thu, 18 Apr 2019 10:41:41 +0200 Thomas Gleixner wrote: > It's only used in trace.c and there is absolutely no point in compiling it > in when user space stack traces are not supported. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt Funny, these were moved out to g

Re: [patch V2 23/29] tracing: Simplify stack trace retrieval

On Thu, 18 Apr 2019 10:41:42 +0200 Thomas Gleixner wrote: > Replace the indirection through struct stack_trace by using the storage > array based interfaces. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt Reviewed-by: Steven Rostedt (VMw

Re: [patch V2 24/29] tracing: Remove the last struct stack_trace usage

On Thu, 18 Apr 2019 10:41:43 +0200 Thomas Gleixner wrote: > Simplify the stack retrieval code by using the storage array based > interface. > > Signed-off-by: Thomas Gleixner Reviewed-by: Steven Rostedt (VMware) -- Steve ___ dri-d

[PATCH] drm/i915: Copy name string into ring buffer for intel_update/disable_plane tracepoints

From: "Steven Rostedt (VMware)" Currently the intel_update_plane and intel_disable_plane tracepoints record the address of plane->name in the ring buffer, and then when reading the ring buffer uses %s to get the name. The issue with this, is that those two events can be minutes,

  1   2   3   >