linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: hotplug (was devfs)
@ 2002-11-13 14:15 Oliver.Neukum
  2002-11-13 15:14 ` David Brownell
  2002-11-13 15:48 ` Nick Craig-Wood
  0 siblings, 2 replies; 3+ messages in thread
From: Oliver.Neukum @ 2002-11-13 14:15 UTC (permalink / raw)
  To: linux-hotplug

On Wed, 13 Nov 2002, Nick Craig-Wood wrote:

> On Tue, Nov 12, 2002 at 01:51:08PM +0100, Oliver Neukum wrote:
> > > Actually, here's a question: are /sbin/hotplug upcalls serialized in
> > > some fashion?  I'd hate to online a thousand devices in my disk array
> > > and have the machine forkbomb itself.
> >
> > Nope, no serialisation. You don't have any guarantee even that
> > addition will be delivered before removal.
>
> And that is why (we finally discovered) we were getting
> non-deterministic device numbering of USB nodes.
>
> We have machines with 6 x 4 port USB <-> serial converters attached.
> These would get randomly assigned usb device ids and hence random
> /dev/ttyUSB nodes.  Not very useful when there is a load of different
> things attached to the 24 serial ports!

Please clarify. Did this happen if you connected a hub these gadgets
sit on? Do you use the same type of device six times ?

> Sometimes we also found that one of the devices wouldn't get
> initialised properly.
>
> We fixed these problems by removing hotplug and loading the relevant
> kernel modules in the correct order and voila a perfectly

Modules ? Plural?

> deterministic order for the /dev/ttyUSBs with all devices initialised.
> Plugging in our USB bus with 24 devices on it does indeed produce a
> mini-forkbomb effect ;-) (Especially since these Keyspan devices are
> initialised twice - once without firmware and once with firmware.)

There's a further problem.

> So - perhaps hotplug ought to be serialised?

Definitely, but how far?

	Regards
		Oliver




-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about 
your web server security? Click here for a FREE Thawte 
Apache SSL Guide and answer your Apache SSL security 
needs: http://www.gothawte.com/rd523.html
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: hotplug (was devfs)
  2002-11-13 14:15 hotplug (was devfs) Oliver.Neukum
@ 2002-11-13 15:14 ` David Brownell
  2002-11-13 15:48 ` Nick Craig-Wood
  1 sibling, 0 replies; 3+ messages in thread
From: David Brownell @ 2002-11-13 15:14 UTC (permalink / raw)
  To: linux-hotplug

Oliver.Neukum@lrz.uni-muenchen.de wrote:
> On Wed, 13 Nov 2002, Nick Craig-Wood wrote:
> 
>>We have machines with 6 x 4 port USB <-> serial converters attached.
>>These would get randomly assigned usb device ids and hence random
>>/dev/ttyUSB nodes.  Not very useful when there is a load of different
>>things attached to the 24 serial ports!

Right, this is why "physical" paths are needed as well as
sequentially assigned /dev/...N nodes.


>>Sometimes we also found that one of the devices wouldn't get
>>initialised properly.
>>
>>We fixed these problems by removing hotplug and loading the relevant
>>kernel modules in the correct order and voila a perfectly
> 
> Modules ? Plural?

Sounds like a better fix might have been to teach hotplug
about your additional modules... or to fix the modules
so they initialized correctly!


>>So - perhaps hotplug ought to be serialised?
> 
> 
> Definitely, but how far?

Until about the last week before 2.4.0final shipped, hotplug
was serialized.  The serialization got removed at the same
time keventd got added.

Why was it removed?  Because serializing meant that kernel
locks had to be held until a user mode program returned.
That caused deadlock when, for example, network hotplug
had to grab that same lock ... it basically wasn't possible
to get away from that problem in at least that case, and by
extension likely other cases.

So I'm not sure I see hotplug ever getting serialized.
But then, I don't see any reason it would ever fix the
problem of needing to map /dev/... nodes to the physical
device they represent, either.

- Dave





-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about 
your web server security? Click here for a FREE Thawte 
Apache SSL Guide and answer your Apache SSL security 
needs: http://www.gothawte.com/rd523.html
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: hotplug (was devfs)
  2002-11-13 14:15 hotplug (was devfs) Oliver.Neukum
  2002-11-13 15:14 ` David Brownell
@ 2002-11-13 15:48 ` Nick Craig-Wood
  1 sibling, 0 replies; 3+ messages in thread
From: Nick Craig-Wood @ 2002-11-13 15:48 UTC (permalink / raw)
  To: linux-hotplug

On Wed, Nov 13, 2002 at 03:15:01PM +0100, Oliver.Neukum@lrz.uni-muenchen.de wrote:
> On Wed, 13 Nov 2002, Nick Craig-Wood wrote:
> > On Tue, Nov 12, 2002 at 01:51:08PM +0100, Oliver Neukum wrote:
> > > > Actually, here's a question: are /sbin/hotplug upcalls serialized in
> > > > some fashion?  I'd hate to online a thousand devices in my disk array
> > > > and have the machine forkbomb itself.
> > >
> > > Nope, no serialisation. You don't have any guarantee even that
> > > addition will be delivered before removal.
> >
> > And that is why (we finally discovered) we were getting
> > non-deterministic device numbering of USB nodes.
> >
> > We have machines with 6 x 4 port USB <-> serial converters attached.
> > These would get randomly assigned usb device ids and hence random
> > /dev/ttyUSB nodes.  Not very useful when there is a load of different
> > things attached to the 24 serial ports!
> 
> Please clarify. Did this happen if you connected a hub these gadgets
> sit on?

It happens on bootup when effectively the USB subsystem becomes aware
of all the devices at once and also when you disconnect and reconnect
the hub the devices sit on.

> Do you use the same type of device six times ?

Yes.

> > Sometimes we also found that one of the devices wouldn't get
> > initialised properly.
> >
> > We fixed these problems by removing hotplug and loading the relevant
> > kernel modules in the correct order and voila a perfectly
> 
> Modules ? Plural?

We found we had to load the keyspan module then the usb-uhci module
for ideal startup without hotplug.

> > deterministic order for the /dev/ttyUSBs with all devices initialised.
> > Plugging in our USB bus with 24 devices on it does indeed produce a
> > mini-forkbomb effect ;-) (Especially since these Keyspan devices are
> > initialised twice - once without firmware and once with firmware.)
> 
> There's a further problem.

Do you mean the double initialisation?  That is the way the keyspan
devices work.  They enumerate first time as a dumb device, get sent
their firmware and then enumerate again.

> > So - perhaps hotplug ought to be serialised?
> 
> Definitely, but how far?

Indeed!

-- 
Nick Craig-Wood
ncw1@axis.demon.co.uk


-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about 
your web server security? Click here for a FREE Thawte 
Apache SSL Guide and answer your Apache SSL security 
needs: http://www.gothawte.com/rd523.html
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-11-13 15:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-11-13 14:15 hotplug (was devfs) Oliver.Neukum
2002-11-13 15:14 ` David Brownell
2002-11-13 15:48 ` Nick Craig-Wood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).