hotplugging on an embedded system under 2.6.17(-rcX)

hotplugging on an embedded system under 2.6.17(-rcX)

[Guennadi Liakhovetski]

Hi all,

We are building an embedded system based on oe / bitbaker distro and 
2.6.17(-rc5) kernel. And we'd like to use hotplug on it. Hotplug in a 
generic sense, not as _the_ /proc/sys/kernel/hotplug = /sbin/hotplug 
thing. And this is my first embedded 2.6 project with hotplug...

First I was pretty much unaware of the way udev / hotplug co-exist now, so 
we just installed _the_ "hotplug" package in the same way we were doing 
under 2.4 and then we noticed that the boot-time is VERY long, upon closer 
investigation it turned out to be the hotplug script that was using up 
most of that time being started multiple times on each modprobe.

Now, I've read that now the actual "hotplpug" package is deprecated and 
superseded by the udev (from kernel 2.6.15). But one requires a pretty 
modern version of udev to really fully replace "hotplug" and best 
co-operate with the kernel. First question - starting from which version 
of udev is advised for 2.6.15+ kernels?

Secondly, the version of udev we have from oe is 071. If I just install it 
I see the udevd is started, it even dynamically manages / creates device 
nodes, and I can see with strace that it also receives all modprobe / 
rmmod events from the kernel, but, I suspect it is not quite properly 
configured yet, e.g., when I plug in a USB keyboard usbhid doesn't get 
loaded. Ok, I can read docs, install the latest version of udev, configure 
it, but before I do all that - will it be _much_ faster than the hotplug? 
If not - we'll have to look for another solution...

Are there any ready embedded fast hotplug solutions? Will it be faster if 
one compiles most stuff in the kernel? Our main problem is the startup 
time when about 10-20 kernel modules get loaded...

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany


_______________________________________________
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

Re: hotplugging on an embedded system under 2.6.17(-rcX)

[Greg KH]

On Tue, Jun 06, 2006 at 11:56:33AM +0200, Guennadi Liakhovetski wrote:
> Hi all,
> 
> We are building an embedded system based on oe / bitbaker distro and 
> 2.6.17(-rc5) kernel. And we'd like to use hotplug on it. Hotplug in a 
> generic sense, not as _the_ /proc/sys/kernel/hotplug = /sbin/hotplug 
> thing. And this is my first embedded 2.6 project with hotplug...

Why do you want to use hotplug?  Seriously, if you don't need it I
wouldn't just add it for the fun of it.

What do you want to accomplish?  automatic loading of modules?  network
connections bring up/down?  udev dynamic and persistant device nodes?
All of this needs to be determined before you grab a desktop version of
the udev and hotplug packages.

> First I was pretty much unaware of the way udev / hotplug co-exist now, so 
> we just installed _the_ "hotplug" package in the same way we were doing 
> under 2.4 and then we noticed that the boot-time is VERY long, upon closer 
> investigation it turned out to be the hotplug script that was using up 
> most of that time being started multiple times on each modprobe.

What "hotplug package" did you use?

> Now, I've read that now the actual "hotplpug" package is deprecated and 
> superseded by the udev (from kernel 2.6.15). But one requires a pretty 
> modern version of udev to really fully replace "hotplug" and best 
> co-operate with the kernel. First question - starting from which version 
> of udev is advised for 2.6.15+ kernels?

The latest.

> Secondly, the version of udev we have from oe is 071.

That's quite old, why are you using that version?  I would not recommend
it.

> If I just install it I see the udevd is started, it even dynamically
> manages / creates device nodes, and I can see with strace that it also
> receives all modprobe / rmmod events from the kernel, but, I suspect
> it is not quite properly configured yet, e.g., when I plug in a USB
> keyboard usbhid doesn't get loaded. Ok, I can read docs, install the
> latest version of udev, configure it, but before I do all that - will
> it be _much_ faster than the hotplug?  If not - we'll have to look for
> another solution...

It is much faster than hotplug, but it all comes down to what your udev
rules are doing.  What are they doing?

> Are there any ready embedded fast hotplug solutions? Will it be faster if 
> one compiles most stuff in the kernel? Our main problem is the startup 
> time when about 10-20 kernel modules get loaded...

Do you need 20 modules?  Why?

thanks,

greg k-h


_______________________________________________
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

Re: hotplugging on an embedded system under 2.6.17(-rcX)

[Guennadi Liakhovetski]

On Tue, 6 Jun 2006, Greg KH wrote:

> Why do you want to use hotplug?  Seriously, if you don't need it I
> wouldn't just add it for the fun of it.
>
> What do you want to accomplish?  automatic loading of modules?  network
> connections bring up/down?  udev dynamic and persistant device nodes?
> All of this needs to be determined before you grab a desktop version of
> the udev and hotplug packages.

Sure. Mainly USB (hot-pluggable:-)) device configuration. Compiling 
everything in the kernel is not optimal because loading of the kernel 
image from flash is also slow. We have wlan dongle on USB, we want to be 
able to connect a keyboard. In fact, we only need hotplug for USB. The 
rest we can load just from scripts / compile direct in the kernel. Device 
nodes can be static. And the packages come from handhelds.org / 
openembedded - so, not really "desktop versions":-)

>> First I was pretty much unaware of the way udev / hotplug co-exist now, so
>> we just installed _the_ "hotplug" package in the same way we were doing
>> under 2.4 and then we noticed that the boot-time is VERY long, upon closer
>> investigation it turned out to be the hotplug script that was using up
>> most of that time being started multiple times on each modprobe.
>
> What "hotplug package" did you use?

The old style script-based hotplug. It is labled as 
linux-hotplug_20040920-r7_armv5te.ipk. Would hotplug-ng be MUCH faster?

>> Now, I've read that now the actual "hotplpug" package is deprecated and
>> superseded by the udev (from kernel 2.6.15). But one requires a pretty
>> modern version of udev to really fully replace "hotplug" and best
>> co-operate with the kernel. First question - starting from which version
>> of udev is advised for 2.6.15+ kernels?
>
> The latest.

Theoretically - yes. But in the README it says "configuration is very 
complicated, better to use a package from the distribution":-)

>> Secondly, the version of udev we have from oe is 071.
>
> That's quite old, why are you using that version?  I would not recommend
> it.

Openembedded last stable distribution.

>> If I just install it I see the udevd is started, it even dynamically
>> manages / creates device nodes, and I can see with strace that it also
>> receives all modprobe / rmmod events from the kernel, but, I suspect
>> it is not quite properly configured yet, e.g., when I plug in a USB
>> keyboard usbhid doesn't get loaded. Ok, I can read docs, install the
>> latest version of udev, configure it, but before I do all that - will
>> it be _much_ faster than the hotplug?  If not - we'll have to look for
>> another solution...
>
> It is much faster than hotplug, but it all comes down to what your udev
> rules are doing.  What are they doing?

So far default oe. I've thrown those away that we will never ever need, 
like ieee1394, pci, etc. I could reduce their number further yet.

>> Are there any ready embedded fast hotplug solutions? Will it be faster if
>> one compiles most stuff in the kernel? Our main problem is the startup
>> time when about 10-20 kernel modules get loaded...
>
> Do you need 20 modules?  Why?

i2c, irda, bluetooth, sound, touchscreen, backlight, input... Sure, some 
of them can be linked together, or direct in the kernel...

The important question is - on which way are we likely to achieve best 
results? Every way has optimisation / configuration potential, just it 
would be nice to know in advance which way is likely to be the fastest.

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany


_______________________________________________
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

Re: hotplugging on an embedded system under 2.6.17(-rcX)

[Kay Sievers]

On Wed, 2006-06-07 at 10:28 +0200, Guennadi Liakhovetski wrote:
> On Tue, 6 Jun 2006, Greg KH wrote:
> 
> > Why do you want to use hotplug?  Seriously, if you don't need it I
> > wouldn't just add it for the fun of it.
> >
> > What do you want to accomplish?  automatic loading of modules?  network
> > connections bring up/down?  udev dynamic and persistant device nodes?
> > All of this needs to be determined before you grab a desktop version of
> > the udev and hotplug packages.
> 
> Sure. Mainly USB (hot-pluggable:-)) device configuration. Compiling 
> everything in the kernel is not optimal because loading of the kernel 
> image from flash is also slow.

"Hotplugging" today is mainly "dispatch device events from the kernel to
userland" and not only loading modules. If you only need to autoload
modules, you can do this with one damn simple generic binary or script
pluggged into /sbin/hotplug.
But if you need to hook into event to notify system daemons or run
programs for specific devices, forget the whole old hotplug package
and /sbin/hotplug and run the udev daemon and specify rules to plug into
the device events.

> We have wlan dongle on USB, we want to be 
> able to connect a keyboard. In fact, we only need hotplug for USB. The 
> rest we can load just from scripts / compile direct in the kernel. Device 
> nodes can be static. And the packages come from handhelds.org / 
> openembedded - so, not really "desktop versions":-)

Yeah, but everything that is a bit more than a pocket calculator these
days is very close to a desktop setup without the desktop :)

> >> First I was pretty much unaware of the way udev / hotplug co-exist now

They don't. You can make it not to fail horribly if you know what you
are doing, but it's definitely not "co-existence". :)

> so
> >> we just installed _the_ "hotplug" package in the same way we were doing
> >> under 2.4 and then we noticed that the boot-time is VERY long, upon closer
> >> investigation it turned out to be the hotplug script that was using up
> >> most of that time being started multiple times on each modprobe.
> >
> > What "hotplug package" did you use?
> 
> The old style script-based hotplug. It is labled as 
> linux-hotplug_20040920-r7_armv5te.ipk. Would hotplug-ng be MUCH faster?

Hotplug-ng does not help here. After it has proven to be a good idea,
that functionality has moved into the kernel itself to export MODALIAS.

> >> Now, I've read that now the actual "hotplpug" package is deprecated and
> >> superseded by the udev (from kernel 2.6.15). But one requires a pretty
> >> modern version of udev to really fully replace "hotplug" and best
> >> co-operate with the kernel. First question - starting from which version
> >> of udev is advised for 2.6.15+ kernels?
> >
> > The latest.

Definitely.

> Theoretically - yes. But in the README it says "configuration is very 
> complicated, better to use a package from the distribution":-)

Well, you create a distribution, so it should be solvable for you to get
the box booting. :) It's mentioned that way, cause we don't have the
resources to support people trying to replace the customized version
that comes with their distro.

> >> Secondly, the version of udev we have from oe is 071.
> >
> > That's quite old, why are you using that version?  I would not recommend
> > it.
> 
> Openembedded last stable distribution.
> 
> >> If I just install it I see the udevd is started, it even dynamically
> >> manages / creates device nodes, and I can see with strace that it also
> >> receives all modprobe / rmmod events from the kernel, but, I suspect
> >> it is not quite properly configured yet, e.g., when I plug in a USB
> >> keyboard usbhid doesn't get loaded. Ok, I can read docs, install the
> >> latest version of udev, configure it, but before I do all that - will
> >> it be _much_ faster than the hotplug?  If not - we'll have to look for
> >> another solution...
> >
> > It is much faster than hotplug, but it all comes down to what your udev
> > rules are doing.  What are they doing?
> 
> So far default oe. I've thrown those away that we will never ever need, 
> like ieee1394, pci, etc. I could reduce their number further yet.

They all work almost the same these days, and the very basic setup can
be handled by the same code.

> >> Are there any ready embedded fast hotplug solutions? Will it be faster if
> >> one compiles most stuff in the kernel? Our main problem is the startup
> >> time when about 10-20 kernel modules get loaded...
> >
> > Do you need 20 modules?  Why?
> 
> i2c, irda, bluetooth, sound, touchscreen, backlight, input... Sure, some 
> of them can be linked together, or direct in the kernel...
> 
> The important question is - on which way are we likely to achieve best 
> results? Every way has optimisation / configuration potential, just it 
> would be nice to know in advance which way is likely to be the fastest.

It totally depends on your setup. If you need a generic approach and not
something very small and customized, you want to disable /sbin/hotplug
forking, not use any of the old shell scripts, and use udev to manage
the kernel events. Look at the example rules in etc/udev/ in the udev
tree, there are examples for calling modprobe and doing all other sorts
of event handling without using any of the old hotplug stuff or module
map files.

A good compromise between a generic setup and speed would probably be to
disable /sbin/hotplug, copy the initially needed device nodes to a
temporary /dev (it shouldn't be more than a few in your setup).

Bring up your system to a well defined state (which should be possible
in your setup, unlike it is for a generic desktop) like loading modules,
setting up interfaces, starting system services, ...

Start the udev daemon and let udev handle all future device events
emitted if something is connected or disconnected from the box.

You probably don't want to use initramfs, event-replay, coldplug or
anything we need in the generic distro case, where we need don't know in
advance on what kind of box we are booting up or how we can access the
root filesystem.

Kay




_______________________________________________
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

Re: hotplugging on an embedded system under 2.6.17(-rcX)

[Guennadi Liakhovetski]

On Wed, 7 Jun 2006, Kay Sievers wrote:

> A good compromise between a generic setup and speed would probably be to
> disable /sbin/hotplug, copy the initially needed device nodes to a
> temporary /dev (it shouldn't be more than a few in your setup).
>
> Bring up your system to a well defined state (which should be possible
> in your setup, unlike it is for a generic desktop) like loading modules,
> setting up interfaces, starting system services, ...
>
> Start the udev daemon and let udev handle all future device events
> emitted if something is connected or disconnected from the box.
>
> You probably don't want to use initramfs, event-replay, coldplug or
> anything we need in the generic distro case, where we need don't know in
> advance on what kind of box we are booting up or how we can access the
> root filesystem.

That's approximately what I've done now - disabled the default mounting of 
tmpfs on the top of /dev and "synthesizing" nodes, left the static initial 
device nodes alone, disabled /proc/sys/kernel/hotplug, started udev to let 
it handle further hotplug events - seems to work quite good so far! I'll 
test benchmark it further, but so far it looks really good!

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany


_______________________________________________
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

Re: hotplugging on an embedded system under 2.6.17(-rcX)

[Kay Sievers]

On Wed, 2006-06-07 at 12:06 +0200, Guennadi Liakhovetski wrote:
> On Wed, 7 Jun 2006, Kay Sievers wrote:
> 
> > A good compromise between a generic setup and speed would probably be to
> > disable /sbin/hotplug, copy the initially needed device nodes to a
> > temporary /dev (it shouldn't be more than a few in your setup).
> >
> > Bring up your system to a well defined state (which should be possible
> > in your setup, unlike it is for a generic desktop) like loading modules,
> > setting up interfaces, starting system services, ...
> >
> > Start the udev daemon and let udev handle all future device events
> > emitted if something is connected or disconnected from the box.
> >
> > You probably don't want to use initramfs, event-replay, coldplug or
> > anything we need in the generic distro case, where we need don't know in
> > advance on what kind of box we are booting up or how we can access the
> > root filesystem.
> 
> That's approximately what I've done now - disabled the default mounting of 
> tmpfs on the top of /dev

But you are not using /dev from flash, right?

> and "synthesizing" nodes, left the static initial 
> device nodes alone, disabled /proc/sys/kernel/hotplug, started udev to let 
> it handle further hotplug events - seems to work quite good so far! I'll 
> test benchmark it further, but so far it looks really good!

Sounds good.

Kay



_______________________________________________
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

Re: hotplugging on an embedded system under 2.6.17(-rcX)

[Guennadi Liakhovetski]

On Wed, 7 Jun 2006, Kay Sievers wrote:

> On Wed, 2006-06-07 at 12:06 +0200, Guennadi Liakhovetski wrote:
>>
>> That's approximately what I've done now - disabled the default mounting of
>> tmpfs on the top of /dev
>
> But you are not using /dev from flash, right?

Emn, which flash? It's not NOR-flash in this case, it's on CF... In other 
setups we do have /dev in NOR-flash. Is it bad? We even did ext2 rw in NOR 
as /dev - rw because you have to be able to "write" to it, ext2 because it 
will anyway not be written TO the flash. Now with udev creating new nodes 
dynamically we wouldn't do that of course.

>> and "synthesizing" nodes, left the static initial
>> device nodes alone, disabled /proc/sys/kernel/hotplug, started udev to let
>> it handle further hotplug events - seems to work quite good so far! I'll
>> test benchmark it further, but so far it looks really good!
>
> Sounds good.

Yeah... Only I cannot repeat it... I mean, I have one experimantal system, 
where it works. And another "clean" system (near to the final 
configuration) where I cannot get it to work - I cannot get udevd to load 
modules there... under /dev/.udev/failed I get:

# ls -l /dev/.udev/failed/
total 0
lrwxrwxrwx  1 root root 58 Jan  1  1970 devices@platform@pxa27x-ohci@usb1@1-1@1-1.1@1-1.1:1.0 -> /sys/devices/platform/pxa27x-ohci/usb1/1-1/1-1.1/1-1.1:1.0
lrwxrwxrwx  1 root root 58 Jan  1  1970 devices@platform@pxa27x-ohci@usb1@1-1@1-1.2@1-1.2:1.0 -> /sys/devices/platform/pxa27x-ohci/usb1/1-1/1-1.2/1-1.2:1.0
lrwxrwxrwx  1 root root 58 Jan  1  1970 devices@platform@pxa27x-ohci@usb1@1-1@1-1.2@1-1.2:1.1 -> /sys/devices/platform/pxa27x-ohci/usb1/1-1/1-1.2/1-1.2:1.1

As long as I am searching - any idea? The same kernel.

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany


_______________________________________________
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

Re: hotplugging on an embedded system under 2.6.17(-rcX)

[Kay Sievers]

On Wed, 2006-06-07 at 14:08 +0200, Guennadi Liakhovetski wrote:
> On Wed, 7 Jun 2006, Kay Sievers wrote:
> 
> > On Wed, 2006-06-07 at 12:06 +0200, Guennadi Liakhovetski wrote:
> >>
> >> That's approximately what I've done now - disabled the default mounting of
> >> tmpfs on the top of /dev
> >
> > But you are not using /dev from flash, right?
> 
> Emn, which flash? It's not NOR-flash in this case, it's on CF... In other 
> setups we do have /dev in NOR-flash. Is it bad? We even did ext2 rw in NOR 
> as /dev - rw because you have to be able to "write" to it, ext2 because it 
> will anyway not be written TO the flash. Now with udev creating new nodes
> dynamically we wouldn't do that of course.

Well, I would always use a tmpfs filesystem on /dev, so you always start
with a well defined setup. As long as we don't have a unionfs we can
overlay over /dev, it's the safest to copy your few initial device nodes
to tmpfs and let udev mess around with it from that point. Udev also
stores temporary files in /dev/.udev may be a bit faster on tmpfs.

> >> and "synthesizing" nodes, left the static initial
> >> device nodes alone, disabled /proc/sys/kernel/hotplug, started udev to let
> >> it handle further hotplug events - seems to work quite good so far! I'll
> >> test benchmark it further, but so far it looks really good!
> >
> > Sounds good.
> 
> Yeah... Only I cannot repeat it... I mean, I have one experimantal system, 
> where it works. And another "clean" system (near to the final 
> configuration) where I cannot get it to work - I cannot get udevd to load 
> modules there... under /dev/.udev/failed I get:

You have the RUN+="/sbin/modprobe $env{MODALIAS}" rules like this,
right?
  http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=etc/udev/debian/hotplug.rules

Kay



_______________________________________________
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

Re: hotplugging on an embedded system under 2.6.17(-rcX)

[Guennadi Liakhovetski]

On Wed, 7 Jun 2006, Kay Sievers wrote:

> On Wed, 2006-06-07 at 14:08 +0200, Guennadi Liakhovetski wrote:
>> Yeah... Only I cannot repeat it... I mean, I have one experimantal system,
>> where it works. And another "clean" system (near to the final
>> configuration) where I cannot get it to work - I cannot get udevd to load
>> modules there... under /dev/.udev/failed I get:
>
> You have the RUN+="/sbin/modprobe $env{MODALIAS}" rules like this,
> right?
>  http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=etc/udev/debian/hotplug.rules

I copied the whole /etc/udev over. In fact, all these files:

etc/init.d/udev
etc/rcS.d/S04udev
etc/scsi_id.config
etc/udev/links.conf
etc/udev/rules.d/devfs-udev.rules
etc/udev/rules.d/local.rules
etc/udev/rules.d/permissions.rules
etc/udev/rules.d/udev.rules
etc/udev/scripts/mount.sh
etc/udev/scripts/network.sh
etc/udev/udev.conf
lib/udev/firmware_helper
lib/udev/udev_run_devd
lib/udev/udev_run_hotplugd
lib/udev/udevsynthesize
sbin/scsi_id
sbin/udevcontrol
sbin/udevd
sbin/udevsynthesize
sbin/vol_id
usr/bin/udevinfo
usr/bin/udevtest
usr/sbin/udevmonitor

AFAIU, udev doesn't depend on d-bus, hal, right? I ran strace on a running 
udevd while loading ohci-hcd. On the working system I see telegrams like

recv(4, "add@/module/ohci_hcd\0ACTION­d\0"..., 2560, 0) = 85

on the non-working one they don't come... Below are recv()s from working 
and non-working cases...

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Working:

1045  recv(4, "add@/module/usbcore\0ACTION­d\0D"..., 2560, 0) = 83
1045  recv(4, "add@/bus/usb/drivers/usbfs\0ACTIO"..., 2560, 0) = 98
1045  recv(4, "add@/bus/usb/drivers/hub\0ACTION="..., 2560, 0) = 94
1045  recv(4, "add@/bus/usb/drivers/usb\0ACTION="..., 2560, 0) = 94
1045  recv(4, "add@/module/ohci_hcd\0ACTION­d\0"..., 2560, 0) = 85
1045  recv(4, "add@/bus/platform/drivers/pxa27x"..., 2560, 0) = 120
1045  recv(4, "add@/class/usb_host/usb_host1\0AC"..., 2560, 0) = 193
1045  recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 151
1045  recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 276
1045  recv(4, "add@/class/usb_device/usbdev1.1\0"..., 2560, 0) = 209
1045  recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 159
1045  recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 289
1045  recv(4, "add@/class/usb_device/usbdev1.2\0"..., 2560, 0) = 213
1045  recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 171
1045  recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 302
1045  recv(4, "add@/class/usb_device/usbdev1.3\0"..., 2560, 0) = 219
1045  recv(4, "add@/module/usbhid\0ACTION­d\0DE"..., 2560, 0) = 81
1045  recv(4, "add@/bus/usb/drivers/usbhid\0ACTI"..., 2560, 0) = 100
1045  recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 171
1045  recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 318
1045  recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 318
1045  recv(4, "add@/class/usb_device/usbdev1.4\0"..., 2560, 0) = 219
1045  recv(4, "add@/class/input/input0\0ACTION=a"..., 2560, 0) = 400
1045  recv(4, "add@/module/hci_usb\0ACTION­d\0D"..., 2560, 0) = 83
1045  recv(4, "add@/bus/usb/drivers/hci_usb\0ACT"..., 2560, 0) = 102
1045  recv(4, "add@/class/bluetooth/hci0\0ACTION"..., 2560, 0) = 217

Non-working:

849   recv(4, "add@/module/ohci_hcd\0ACTION­d\0"..., 2560, 0) = 85
849   recv(4, "add@/bus/platform/drivers/pxa27x"..., 2560, 0) = 120
849   recv(4, "add@/class/usb_host/usb_host1\0AC"..., 2560, 0) = 193
849   recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 151
849   recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 276
849   recv(4, "add@/class/usb_device/usbdev1.1\0"..., 2560, 0) = 209
849   recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 159
849   recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 289
849   recv(4, "add@/class/usb_device/usbdev1.2\0"..., 2560, 0) = 213
849   recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 171
849   recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 302
849   recv(4, "add@/class/usb_device/usbdev1.3\0"..., 2560, 0) = 219
849   recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 171
849   recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 318
849   recv(4, "add@/devices/platform/pxa27x-ohc"..., 2560, 0) = 318
849   recv(4, "add@/class/usb_device/usbdev1.4\0"..., 2560, 0) = 219


_______________________________________________
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

Re: hotplugging on an embedded system under 2.6.17(-rcX)

[Guennadi Liakhovetski]

On Wed, 7 Jun 2006, Guennadi Liakhovetski wrote:

> I copied the whole /etc/udev over. In fact, all these files:

I know what that was - busybox' modprobe... grrrr

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany


_______________________________________________
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