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 fashion, not in the early-printk
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(), I
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
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(&xdbc.lock, flags);
Yikes!!
So how is this suppo
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
> >>
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
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) {
>
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(&lock))
> return;
>
> raw
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.
> > YES, it was so simple
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; } /
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
On Wed, Mar 02, 2016 at 11:35:35AM -0500, Steven Rostedt wrote:
> On Wed, 2 Mar 2016 17:24:12 +0100
> Peter Zijlstra wrote:
>
> > On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
> > > 8110f570 :
> > > 8110f570: 55
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:
>
>
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 ll/
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 arch
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 routi
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
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 change
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
> wri
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. Tha
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
> >
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
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
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 Devic
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
> &
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: usb-4.x/drivers/usb/gadget/function/f_mass_st
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 are in the host
> hardware,
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 trig
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 f
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
>
sible) consumer for them at all.
---
Subject: perf: Do not compute 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
---
kernel/events/core.c | 8
1 file changed, 4 in
On Sat, 2007-12-29 at 22:42 -0800, David Brownell wrote:
> On Saturday 29 December 2007, Alan Stern wrote:
> > There's no way to remove these, which means there's
> > no way to prevent lockdep from issuing a warning.
>
> There may be no *efficient* way to do that. If it tracked
> every lock in
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 uns
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
On Wed, Jul 23, 2014 at 05:37:43PM -0700, Linus Torvalds wrote:
> On Wed, Jul 23, 2014 at 2:53 AM, Borislav Petkov 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 rc6 + t
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")
> e06
On Thu, Jul 24, 2014 at 11:18:16AM -0700, Linus Torvalds wrote:
> On Thu, Jul 24, 2014 at 5:58 AM, Peter Zijlstra wrote:
> >
> > So going by the nifty picture rostedt made:
> >
> > [ 61.454336]CPU0
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
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
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 the
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 potent
41 matches
Mail list logo
