Re: Audio I/O parameters

On Tue, Jul 30, 2013 at 02:05:29PM -0400, Steven Rostedt wrote: On Tue, 2013-07-30 at 11:42 -0400, Alan Stern wrote: On Mon, 29 Jul 2013, James Stone wrote: Just an FYI, it is usually better to email my rost...@goodmis.org account. I don't always read my redhat email. That's reserved for

Re: Audio I/O parameters

On Fri, Aug 02, 2013 at 10:14:39AM -0400, Alan Stern wrote: URL Clas-32862d.h.1us : local_clock -perf_event_update_userpage URL Clas-32862d.h.2us : watchdog_overflow_callback -__perf_event_overflow URL Clas-32862d.h.3us : arch_trigger_all_cpu_backtrace_handler

Re: Audio I/O parameters

time values unnecessarily We should not be calling calc_timer_values() for events that do not actually have an mmap()'ed userpage. Signed-off-by: Peter Zijlstra pet...@infradead.org --- kernel/events/core.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/events

Re: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400

On Thu, Feb 13, 2014 at 05:27:20PM +0100, Thomas Gleixner wrote: I think, that's the simplest option for now. We'll look into the hrtimer issue anyway, but as I said it's not a two lines patch. Yeah, and don't forget the reason we ripped that hrtimer softirq stuff out of mainline :-) -- To

Re: Linux 3.16-rc6

On Wed, Jul 23, 2014 at 05:37:43PM -0700, Linus Torvalds wrote: On Wed, Jul 23, 2014 at 2:53 AM, Borislav Petkov b...@alien8.de wrote: Well, it looks like we f*cked up something after -rc5 since I'm starting to see lockdep splats all over the place which I didn't see before. I'm running

Re: Linux 3.16-rc6

On Thu, Jul 24, 2014 at 02:25:13PM +0200, Borislav Petkov wrote: On Thu, Jul 24, 2014 at 10:41:27AM +0200, Borislav Petkov wrote: you can easily reproduce by booting a kvm guest with rc6 + tip/master. Right, so reverting 586fefe5bbdc (locking/selftest: Support queued rwlock) e0645a111cb4

Re: Linux 3.16-rc6

On Thu, Jul 24, 2014 at 11:18:16AM -0700, Linus Torvalds wrote: On Thu, Jul 24, 2014 at 5:58 AM, Peter Zijlstra pet...@infradead.org wrote: So going by the nifty picture rostedt made: [ 61.454336]CPU0CPU1 [ 61.454336

Re: Linux 3.16-rc6

On Thu, Jul 24, 2014 at 04:38:28PM -0400, Waiman Long wrote: Yes, I think I may have a solution for that. Borislav, can you apply the following patch on top of the lockdep patch to see if it can fix the problem? diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index

Re: Linux 3.16-rc6

On Mon, Jul 28, 2014 at 12:37:14PM -0400, Waiman Long wrote: I am planning to take out the check in check_deadlock and only have the test in lock_acquire which change a 3 to 2 when in interrupt context. Now my question is whether to do it as a new patch on top of the existing one in tip or a

Re: Stack dump when try to store uframe_periodic_max

On Mon, Aug 17, 2015 at 10:32:20AM -0400, Alan Stern wrote: On Mon, 17 Aug 2015, Peter Chen wrote: Hi Alan, When run echo 105 /sys/bus/platform/devices/ci_hdrc.1/uframe_periodic_max, if lockdep check is enabled, there is below dump, I am afraid it can't find how to fix it, the

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Wed, Mar 02, 2016 at 11:35:35AM -0500, Steven Rostedt wrote: > On Wed, 2 Mar 2016 17:24:12 +0100 > Peter Zijlstra <pet...@infradead.org> wrote: > > > On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote: > > > 8110f570 : > > > fff

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote: > 8110f570 : > 8110f570: 55 push %rbp > 8110f571: 48 89 e5mov%rsp,%rbp > 8110f574: 41 57 push %r15 > 8110f576: 41 56

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Wed, Mar 02, 2016 at 04:00:49PM +0100, Sedat Dilek wrote: > > > > Right, most odd. Sedat, could you provide objdump -D of the relevant > > sections of vmlinux ? > > > > Can you give some clear instructions - for what shall I look for in special? objdump -D vmlinux | awk '/<[^>]*>:$/ { p=0; }

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Tue, Mar 01, 2016 at 10:07:40AM -0500, Steven Rostedt wrote: > On Tue, 1 Mar 2016 11:05:42 +0100 > Sedat Dilek wrote: > > > > [ FACT #3: TEST-CASE #2 ] > > > > The most reliable test-case is to simply unplug my external Logitech > > USB mouse - saw this by accident. >

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

On Wed, Jan 25, 2017 at 10:23:55AM +0100, Ingo Molnar wrote: > > * Lu Baolu wrote: > > > > Hiding essentially an early udelay() implementation in an early-printk > > > driver is > > > ugly and counterproductive. > Yeah - so could we do this in a more generic

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

On Thu, Jan 26, 2017 at 05:01:05PM +0100, Ingo Molnar wrote: > > > > > > I.e. if there's any polling component then it would be reasonable to add > > > an error > > > component: poll the status and if it goes 'disconnected' then disable > > > early-printk > > > altogether in this case and

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote: > In my driver, udelay() is mostly used to handle time out. > > Xdbc hides most USB things in its firmware. Early printk driver only needs > to setup the registers/data structures and wait until link ready or time out. > Without udelay(),

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

On Wed, Jan 25, 2017 at 11:51:34PM +0800, Lu Baolu wrote: > > What is timeout and why? > > Put it in simple: > > The driver sets the RUN bit in control register and polls READY > bit in status register for the successful USB device enumeration. > As the USB device enumeration might fail and the

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

On Thu, Jan 26, 2017 at 08:19:37AM +0100, Ingo Molnar wrote: > > * Lu Baolu wrote: > > > Fair enough. > > > > USB connection is stable enough, unless the user unplugs the > > USB cable during debugging. > > What does the hardware do in this case? The XHCI registers

Re: Memory barrier needed with wake_up_process()?

On Fri, Sep 02, 2016 at 02:10:13PM -0400, Alan Stern wrote: > Paul, Peter, and Ingo: > > This must have come up before, but I don't know what was decided. > > Isn't it often true that a memory barrier is needed before a call to > wake_up_process()? A typical scenario might look like this: > >

Re: Memory barrier needed with wake_up_process()?

On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote: > Felipe, your tests will show whether my guess was totally off-base. > For the new people, Felipe is tracking down a problem that involves > exactly the code sequence listed at the top of the email, where we know > that the wakeup

Re: Memory barrier needed with wake_up_process()?

On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote: > > Actually, that's not entirely true (although presumably it works okay > for most architectures). Yeah, all load-store archs (with exception of PowerPC and ARM64 and possibly MIPS) implement ACQUIRE with a general fence (after the

Re: Memory barrier needed with wake_up_process()?

On Sat, Sep 03, 2016 at 12:14:13AM +0200, Peter Zijlstra wrote: > On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote: > > > > Actually, that's not entirely true (although presumably it works okay > > for most architectures). > > Yeah, all load-store archs

Re: Memory barrier needed with wake_up_process()?

On Sat, Sep 03, 2016 at 10:16:31AM -0400, Alan Stern wrote: > > Sorry, but that is horrible code. A barrier cannot ensure writes are > > 'complete', at best they can ensure order between writes (or reads > > etc..). > > The code is better than the comment. What I really meant was that the >

Re: Memory barrier needed with wake_up_process()?

On Sat, Sep 03, 2016 at 04:51:07PM +0300, Felipe Balbi wrote: > > That said, I cannot spot an obvious fail, > > okay, but a fail does exist. Any hints on what extra information I could > capture to help figuring this one out? More information on which sleep is not waking woudl help I suppose.

Re: Memory barrier needed with wake_up_process()?

On Sat, Sep 03, 2016 at 10:49:39AM -0400, Alan Stern wrote: > On Sat, 3 Sep 2016, Alan Stern wrote: > > > In other words, we have: > > > > CPU 0 CPU 1 > > - - > > Start DMA Handle DMA-complete irq > >

Re: Memory barrier needed with wake_up_process()?

On Mon, Sep 05, 2016 at 10:43:11AM +0100, Will Deacon wrote: > On Sat, Sep 03, 2016 at 12:16:29AM +0200, Peter Zijlstra wrote: > > Forgot to Cc Will. Will, does ARM64 need to make smp_mb__before_spinlock > > smp_mb() too? > > Yes, probably. Just to confirm, the t

Re: Memory barrier needed with wake_up_process()?

On Tue, Sep 06, 2016 at 02:43:39PM +0300, Felipe Balbi wrote: > > Could you confirm that bulk_{in,out}_complete() work on different > > usb_request structures, and they can not, at any time, get called on the > > _same_ request? > > usb_requests are allocated for a specific endpoint and USB

Re: Memory barrier needed with wake_up_process()?

On Mon, Sep 05, 2016 at 11:29:26AM -0400, Alan Stern wrote: > On Mon, 5 Sep 2016, Peter Zijlstra wrote: > > > > Actually, seeing it written out like this, one realizes that it really > > > ought to be: > > > > > &g

Re: Memory barrier needed with wake_up_process()?

On Tue, Sep 06, 2016 at 01:49:37PM +0200, Peter Zijlstra wrote: > On Tue, Sep 06, 2016 at 02:43:39PM +0300, Felipe Balbi wrote: > > My fear now, however, is that changing smp_[rw]mb() to smp_mb() just > > adds extra overhead which makes the problem much, much less likely to &

Re: Memory barrier needed with wake_up_process()?

On Tue, Sep 06, 2016 at 10:46:55AM -0400, Alan Stern wrote: Not knowing where INFO() goes, you should use trace_printk() not printk(), as the former is strictly per cpu, while the latter is globally serialized and can hide all these problems. > Index:

Re: Memory barrier needed with wake_up_process()?

On Fri, Sep 02, 2016 at 04:29:19PM -0400, Alan Stern wrote: > I'm afraid so. The code doesn't use wait_event(), in part because > there's no wait_queue (since only one task is involved). You can use wait_queue fine with just one task, and it would clean up the code tremendously. You can replace

Re: Memory barrier needed with wake_up_process()?

On Sat, Sep 03, 2016 at 09:58:09AM +0300, Felipe Balbi wrote: > > What arch are you seeing this on? > > x86. Skylake to be exact. So it _cannot_ be the thing Alan mentioned. By the simple fact that spin_lock() is a full barrier on x86 (every LOCK prefixed instruction is). > The following

Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability

On Fri, Nov 11, 2016 at 12:33:29PM +0800, Lu Baolu wrote: > Things become complicated when it comes to USB debug port. > But it's still addressable. > > At this time, we can do it like this. > > write() > { > if (in_nmi() && raw_spin_is_locked()) > return; > >

Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability

On Thu, Nov 10, 2016 at 09:56:41AM +0100, Thomas Gleixner wrote: > On Thu, 10 Nov 2016, Lu Baolu wrote: > > This seems to be a common issue for all early printk drivers. > > No. The other early printk drivers like serial do not have that problem as > they simply do: > >while (*buf) { >

Re: [RESEND PATCH v2 1/4] usb: dbc: early driver for xhci debug capability

On Thu, Oct 20, 2016 at 10:41:32AM +0200, Peter Zijlstra wrote: > I'm already only using early_printk() because regular printk() is an > unfixable piece of crap, and now you're making early_printk() useless > too. Note that the existing USB debug port stuff doesn't seem to have a si

Re: [RESEND PATCH v2 1/4] usb: dbc: early driver for xhci debug capability

On Thu, Oct 20, 2016 at 04:08:17PM +0800, Lu Baolu wrote: > Hi Peter, > > Thanks for your comments. > > On 10/19/2016 09:09 PM, Peter Zijlstra wrote: > > On Wed, Oct 19, 2016 at 08:18:22AM +0800, Lu Baolu wrote: > >> +++ b/drivers/usb/early/xhci-dbc.c > >>

Re: [RESEND PATCH v2 1/4] usb: dbc: early driver for xhci debug capability

On Wed, Oct 19, 2016 at 08:18:22AM +0800, Lu Baolu wrote: > +++ b/drivers/usb/early/xhci-dbc.c > +static int xdbc_bulk_write(const char *bytes, int size) > +{ > + unsigned long flags; > + int ret, timeout = 0; > + > + spin_lock_irqsave(, flags); Yikes!! So how is this supposed to

Re: [PATCH v8 2/5] usb: early: add driver for xhci debug capability

On Thu, Jun 01, 2017 at 10:15:24AM +0200, Vlastimil Babka wrote: > Thanks. I didn't make it clear that the trace_printk() warning is there > even if the code using it doesn't actually execute (i.e. I didn't > specify any early_printk bootparam). There are some roastedy tricks to > detect the

Re: dvb usb issues since kernel 4.9

On Mon, Jan 08, 2018 at 10:31:09PM +0100, Jesper Dangaard Brouer wrote: > I did expected the issue to get worse, when you load the Pi with > network traffic, as now the softirq time-budget have to be shared > between networking and USB/DVB. Thus, I guess you are running TCP and > USB/mpeg2ts on