lkml.org 
[lkml]   [2013]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Wed, 16 Jan 2013, Tejun Heo wrote:

> Hello, Alan.
>
> On Wed, Jan 16, 2013 at 12:01:53PM -0500, Alan Stern wrote:
> > > The problem here is that "flush everything which comes before me" is
> > > used to order async jobs. e.g. after async jobs probe the hardware
> > > they order themselves by flushing before registering them, so unless
> >
> > I don't fully understand this example. What is the point -- to make
> > sure that asynchronously probed devices are registered in the order of
> > their discovery?
>
> People still want devices to be numbered to their physical ports and
> so on, so we keep the registeration order the same as natural
> (whatever that means) hardware order.
>
> > If so, here's how to do it safely: Start up the async jobs in reverse
> > order of discovery. Have each job acquire a cookie when it starts.
> > Then each job needs to wait only for tasks that started after its
> > cookie was issued.
>
> It's a bit clumsy but yeah I guess it could work.
>
> > > There aren't too many which use async anyway so changing stuff
> > > shouldn't be too difficult but I think the simpicity or dumbness is
> > > one of major attractions of async, so it'd be nice to keep things that
> > > way and the PF_USED_ASYNC hack seems to be able to hold things
> > > together for now.
> >
> > Nesting won't matter for the chronological approach. I really think
> > you should consider it more fully. It's not a hack, and it doesn't
> > need to be complicated.
>
> There is benefit to the current dumb implementation in that drivers
> can use it without thinking too much, but yeah it could be that the
> flushing range limit isn't too much of restriction on top. I don't
> know. At this point, I'd prefer to remove request_module() from
> elevator init path for the problem at hand. If we need something more
> involved, changing cookie usage rules definitely seems like an option.

A simpler approach might be to leave the existing synchronization
mechanisms as they are, and use the chronological approach only for the
case of loading a module (or wherever else someone wants to use it).

Alan Stern



\
 
 \ /
  Last update: 2013-01-16 19:41    [W:0.126 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site