[Buildroot] Buildroot 2011.11 on x86_64 - neither udev nor mdev loads needed modules at startup

[Buildroot] Buildroot 2011.11 on x86_64 - neither udev nor mdev loads needed modules at startup

[Wojciech Zabolotny]

Hi,

I compiled the buildroot-2011.11 for x86_64 platform. Unfortunately
after the startup the device drivers are not loaded. I've tried to use
both mdev and udev, and results are the same.
I have the following settings in the kernel configuration:
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

When I load the drivers manually:
eg. (on qemu-system-x86_64):
#modprobe e1000
#modprobe uhci_hcd

the NIC and the USB device (passed by -usbdevice host:0xabcd:0xcdef)
are recognized correctly.
The syptoms were the same on the real hardware (E350M1 board) which
currently not available to me.

I attach my buildroot configuration and my kernel configuration
together with /var/log/messages from the emulated machine.

The "mount" command returns the following:
rootfs on / type rootfs (rw,relatime)
devtmpfs on /dev type devtmpfs
(rw,relatime,size=998680k,nr_inodes=249670,mode=755)
proc on /proc type proc (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,relatime,mode=777)
tmpfs on /tmp type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)

The udevd is running (what's interesting, after I run "#modprobe
e1000", there are even two udevd processes running both as
"/sbin/udevd -d").

Is it a problem with this release of buildroot, or have I something
misconfigured?
-- 
TIA & Merry Christmas!
WZab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel_config.gz
Type: application/x-gzip
Size: 32361 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111225/38e9d3cb/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildroot_config.gz
Type: application/x-gzip
Size: 5000 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111225/38e9d3cb/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: var_log_messages.gz
Type: application/x-gzip
Size: 3616 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111225/38e9d3cb/attachment-0005.bin>

[Buildroot] Buildroot 2011.11 on x86_64 - neither udev nor mdev loads needed modules at startup

[Wojciech Zabolotny]

I've found one problem with /etc/init.d/S10udev script:

Instead of:
  udevadm control --stop_exec_queue
There should be:
  udevadm control --stop-exec-queue

However it doesn't solve the main issue...
-- 
Regards,
Wojtek

[Buildroot] Buildroot 2011.11 on x86_64 - neither udev nor mdev loads needed modules at startup

[Wojciech Zabolotny]

I've found yet another problem associated with udev's pci-db.
The database path is compiled as "/usr/local/wzab/asus_amd/buildroot-2011.11/output/target/usr/share/hwdata/pci.ids" (containing the whole path to the directory in which I compiled the buildroot) 
instead of only "/usr/share/hwdata/pci.ids".

However working around this problem by:
#mkdir -p /usr/local/wzab/asus_amd/buildroot-2011.11/output
#ln -s / /usr/local/wzab/asus_amd/buildroot-2011.11/output/target

improved operation of pci-db, but didn't help to automatically load modules for recognized hardware...

Additionally to analyze my problems with udev, I had to compile strace.
It didn't compile "out of the box" leading to error:

/usr/local/wzab/asus_amd/buildroot-2011.11/output/host/usr/bin/x86_64-unknown-linux-uclibc-gcc -DHAVE_CONFIG_H -I. -I./linux/x86_64 -I./linux   -Wall -pipe -Os  -fPIC -DPIC -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT file.o -MD -MP -MF .deps/file.Tpo -c -o file.o file.c
file.c: In function 'printstat64':
file.c:1046:16: error: storage size of 'statbuf' isn't known

To compile it I had to comment out the line 1010 in file.c:
// #if !defined HAVE_STAT64 && defined LINUX && defined X86_64
and corresponding line 1040:
//#endif

Anyway the reason why the modules are not loaded automatically is still unclear :-(.
-- 
Regards,
Wojtek

[Buildroot] Buildroot 2011.11 on x86_64 - neither udev nor mdev loads needed modules at startup

[Diego Iastrubni]

While not a solution...

On Mon, Dec 26, 2011 at 5:45 PM, Wojciech Zabolotny <wzab01@gmail.com>wrote:

>
> Anyway the reason why the modules are not loaded automatically is still
> unclear :-(.


When I started using buildroot for my devices, I found the same problem.
However, since this is a dedicated device, the amount of hardware that can
be plugged in is rather small... so I "modprobed" the needed modules (2-3)
and continued.

How are modules loaded enerally, the kernel requests them from a user space
utility?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111226/4d512e37/attachment.html>

[Buildroot] SOLVED! Re: Buildroot 2011.11 on x86_64 - neither udev nor mdev loads needed modules at startup

[Wojciech Zabolotny]

Finally I've got it! The reason was so simple, that I can't believe I've spent such a long time at it :-(.

In the buildroot-2011.11 the modprobe is located in /usr/bin:
# which modprobe
/usr/bin/modprobe
However in the /lib/udev/rules.d scripts the modprobe is called as /sbin/modprobe .

So I've added the symlink /sbin/modprobe pointing to /usr/sbin/modprobe and everything works perfectly!
-- 
Thanks & Regards,
Wojtek

[Buildroot] SOLVED! Re: Buildroot 2011.11 on x86_64 - neither udev nor mdev loads needed modules at startup

[Wojciech Zabolotny]

Ooops, I've forgotten about one more detail.

I have compiled the external module-init-tools instead of those provided by busybox.
I had to add "udevadm trigger --action=add" command to the /etc/init.d/S10udev file
  [...]
$UDEV_BIN -d || (echo "FAIL" && exit 1)
udevadm trigger --action=add
echo "done"
;;
[...]

In case if I've forgotten any other modification, I attach my "buildroot_config", my "busybox_config" and my "kernel_config" files.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel_config.gz
Type: application/x-gzip
Size: 32276 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111226/20f53042/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox_config.gz
Type: application/x-gzip
Size: 6485 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111226/20f53042/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildroot_config.gz
Type: application/x-gzip
Size: 4981 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111226/20f53042/attachment-0005.bin>

[Buildroot] SOLVED! Re: Buildroot 2011.11 on x86_64 - neither udev nor mdev loads needed modules at startup

[wzab]

I've tested yet another configuration. With modprobe provided by busybox and without external module-init-tools.
In this setup the modprobe is located correctly in /sbin, so the only modification needed to assure automatic loading of modules is addition of "udevadm trigger --action=add" to the 
/etc/init.d/S10udev file right after the  $UDEV_BIN -d || (echo "FAIL" && exit 1) line.

It could be interesting to check if the automatic loading of modules with mdev may be achieved using the recipe described in: https://bugs.busybox.net/show_bug.cgi?id=2377
i.e. by writing the script:

#!/bin/sh
[ "$ACTION" = add ]&&  [ "$MODALIAS" != "" ]&&  modprobe $MODALIAS
[ "$ACTION" = remove ]&&  [ "$MODALIAS" != "" ]&&  modprobe -r $MODALIAS
/sbin/mdev $@

and passing it's path to the /sys/kernel/uevent_helper
(or simply to the CONFIG_UEVENT_HELPER_PATH in the kernel configuration).
If someone verifies it, please let me know. I think, I'll stay with my udev based setup ;-).
-- 
Regards,
Wojtek

[Buildroot] SOLVED! Re: Buildroot 2011.11 on x86_64 - neither udev nor mdev loads needed modules at startup

[Wojciech Zabolotny]

I've tested yet another configuration. With modprobe provided by busybox and without external module-init-tools.
In this setup the modprobe is located correctly in /sbin, so the only modification needed to assure automatic loading of modules is addition of "udevadm trigger --action=add" to the 
/etc/init.d/S10udev file right after the  $UDEV_BIN -d || (echo "FAIL" && exit 1) line.

It could be interesting to check if the automatic loading of modules with mdev may be achieved using the recipe described in: https://bugs.busybox.net/show_bug.cgi?id=2377
i.e. by writing the script:

#!/bin/sh
[ "$ACTION" = add ]&&  [ "$MODALIAS" != "" ]&&  modprobe $MODALIAS
[ "$ACTION" = remove ]&&  [ "$MODALIAS" != "" ]&&  modprobe -r $MODALIAS
/sbin/mdev $@

and passing it's path to the /sys/kernel/uevent_helper
(or simply to the CONFIG_UEVENT_HELPER_PATH in the kernel configuration).
If someone verifies it, please let me know. I think, I'll stay with my udev based setup ;-).
-- 
Regards,
Wojtek

[Buildroot] SOLVED! Re: Buildroot 2011.11 on x86_64 - neither udev nor mdev loads needed modules at startup

[Diego Iastrubni]

On Tue, Dec 27, 2011 at 1:59 AM, Wojciech Zabolotny <wzab01@gmail.com>wrote:

> I've tested yet another configuration. With modprobe provided by busybox
> and without external module-init-tools.
> In this setup the modprobe is located correctly in /sbin, so the only
> modification needed to assure automatic loading of modules is addition of
> "udevadm trigger --action=add" to the /etc/init.d/S10udev file right after
> the  $UDEV_BIN -d || (echo "FAIL" && exit 1) line.
>
> ...

> #!/bin/sh
> [ "$ACTION" = add ]&&  [ "$MODALIAS" != "" ]&&  modprobe $MODALIAS
> [ "$ACTION" = remove ]&&  [ "$MODALIAS" != "" ]&&  modprobe -r $MODALIAS
> /sbin/mdev $@
>
> and passing it's path to the /sys/kernel/uevent_helper
>

Still not working here using udev. Everything seems to be as you described.
Next step - making that wrapper with add/remove actions.

[/root 10.10.10.44] $ cat /sys/kernel/uevent_helper
/sbin/udevadm
[/root 10.10.10.44] $ cat /etc/init.d/S10udev  | grep adm
#       (including startup time!) and administration.  For example, if
        #udevadm trigger
        udevadm trigger --action=add
        udevadm control --stop_exec_queue
[/root 10.10.10.44] $ grep modprobe /lib/udev/rules.d/*
/lib/udev/rules.d/75-probe_mtd.rules:KERNEL=="mtd*ro",
ENV{MTD_FTL}=="smartmedia", RUN+="/sbin/modprobe -bv sm_ftl"
/lib/udev/rules.d/80-drivers.rules:DRIVER!="?*", ENV{MODALIAS}=="?*",
RUN+="/sbin/modprobe -bv $env{MODALIAS}"
/lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="tifm",
ENV{TIFM_CARD_TYPE}=="SD", RUN+="/sbin/modprobe -bv tifm_sd"
/lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="tifm",
ENV{TIFM_CARD_TYPE}=="MS", RUN+="/sbin/modprobe -bv tifm_ms"
/lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="memstick",
RUN+="/sbin/modprobe -bv --all ms_block mspro_block"
/lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="i2o", RUN+="/sbin/modprobe
-bv i2o_block"
/lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="scsi",
ENV{DEVTYPE}=="scsi_device", TEST!="[module/sg]", RUN+="/sbin/modprobe -bv
sg"
/lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="module",
KERNEL=="parport_pc", RUN+="/sbin/modprobe -bv ppdev"
[/root 10.10.10.44] $ which modprobe
/sbin/modprobe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111227/df4cc14a/attachment.html>

[Buildroot] SOLVED! Re: Buildroot 2011.11 on x86_64 - neither udev nor mdev loads needed modules at startup

[Wojciech Zabolotny]

On Tue, Dec 27, 2011 at 12:56 PM, Diego Iastrubni <diegoiast@gmail.com> wrote:
> On Tue, Dec 27, 2011 at 1:59 AM, Wojciech Zabolotny <wzab01@gmail.com>
> wrote:
>>
>> I've tested yet another configuration. With modprobe provided by busybox
>> and without external module-init-tools.
>> In this setup the modprobe is located correctly in /sbin, so the only
>> modification needed to assure automatic loading of modules is addition of
>> "udevadm trigger --action=add" to the /etc/init.d/S10udev file right after
>> the ?$UDEV_BIN -d || (echo "FAIL" && exit 1) line.
>>
> ...
>>
>> #!/bin/sh
>> [ "$ACTION" = add ]&& ?[ "$MODALIAS" != "" ]&& ?modprobe $MODALIAS
>> [ "$ACTION" = remove ]&& ?[ "$MODALIAS" != "" ]&& ?modprobe -r $MODALIAS
>> /sbin/mdev $@
>>
>> and passing it's path to the /sys/kernel/uevent_helper
>
>
> Still not working here using udev. Everything seems to be as you described.
> Next step - making that wrapper with add/remove actions.
>
> [/root 10.10.10.44] $ cat /sys/kernel/uevent_helper
> /sbin/udevadm
> [/root 10.10.10.44] $ cat /etc/init.d/S10udev ?| grep adm
> # ? ? ? (including startup time!) and administration. ?For example, if
> ? ? ? ? #udevadm trigger
> ? ? ? ? udevadm trigger --action=add
> ? ? ? ? udevadm control --stop_exec_queue
> [/root 10.10.10.44] $ grep modprobe /lib/udev/rules.d/*
> /lib/udev/rules.d/75-probe_mtd.rules:KERNEL=="mtd*ro",
> ENV{MTD_FTL}=="smartmedia", RUN+="/sbin/modprobe -bv sm_ftl"
> /lib/udev/rules.d/80-drivers.rules:DRIVER!="?*", ENV{MODALIAS}=="?*",
> RUN+="/sbin/modprobe -bv $env{MODALIAS}"
> /lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="tifm",
> ENV{TIFM_CARD_TYPE}=="SD", RUN+="/sbin/modprobe -bv tifm_sd"
> /lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="tifm",
> ENV{TIFM_CARD_TYPE}=="MS", RUN+="/sbin/modprobe -bv tifm_ms"
> /lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="memstick",
> RUN+="/sbin/modprobe -bv --all ms_block mspro_block"
> /lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="i2o", RUN+="/sbin/modprobe
> -bv i2o_block"
> /lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="scsi",
> ENV{DEVTYPE}=="scsi_device", TEST!="[module/sg]", RUN+="/sbin/modprobe -bv
> sg"
> /lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="module",
> KERNEL=="parport_pc", RUN+="/sbin/modprobe -bv ppdev"
> [/root 10.10.10.44] $ which modprobe
> /sbin/modprobe
>

My complete S10udev looks like below:
#!/bin/sh
#
# udev	This is a minimal non-LSB version of a UDEV startup script.  It
#	was derived by stripping down the udev-058 LSB version for use
#	with buildroot on embedded hardware using Linux 2.6.12+ kernels.
#
#	You may need to customize this for your system's resource limits
#	(including startup time!) and administration.  For example, if
#	your early userspace has a custom initramfs or initrd you might
#	need /dev much earlier; or without hotpluggable busses (like USB,
#	PCMCIA, MMC/SD, and so on) your /dev might be static after boot.
#
#	This script assumes your system boots right into the eventual root
#	filesystem, and that init runs this udev script before any programs
#	needing more device nodes than the bare-bones set -- /dev/console,
#	/dev/zero, /dev/null -- that's needed to boot and run this script.
#

# Check for missing binaries
UDEV_BIN=/sbin/udevd
test -x $UDEV_BIN || exit 5

# Check for config file and read it
UDEV_CONFIG=/etc/udev/udev.conf
test -r $UDEV_CONFIG || exit 6
. $UDEV_CONFIG

case "$1" in
    start)
        echo -n "Populating $udev_root using udev: "
        echo -e '\000\000\000\000' > /proc/sys/kernel/hotplug
        $UDEV_BIN -d || (echo "FAIL" && exit 1)
        udevadm trigger --action=add
        echo "done"
        ;;
    stop)
        # Stop execution of events
        udevadm control --stop_exec_queue
        killall udevd
        ;;
    *)
        echo "Usage: $0 {start|stop}"
        exit 1
        ;;
esac


exit 0

-- 
HTH & Regards,
Wojtek

[Buildroot] strace doesn't compile on x86_64

[Arnout Vandecappelle]

On Monday 26 December 2011 16:45:08 Wojciech Zabolotny wrote:
> Additionally to analyze my problems with udev, I had to compile strace.
> It didn't compile "out of the box" leading to error:
> 
> /usr/local/wzab/asus_amd/buildroot-2011.11/output/host/usr/bin/x86_64-unknown-linux-uclibc-gcc -DHAVE_CONFIG_H -I. -I./linux/x86_64 -I./linux   -Wall -pipe -Os  -fPIC -DPIC -D_LARGEFILE_SOURCE 
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT file.o -MD -MP -MF .deps/file.Tpo -c -o file.o file.c
> file.c: In function 'printstat64':
> file.c:1046:16: error: storage size of 'statbuf' isn't known
> 
> To compile it I had to comment out the line 1010 in file.c:
> // #if !defined HAVE_STAT64 && defined LINUX && defined X86_64
> and corresponding line 1040:
> //#endif

 Yes, I noticed that as well...  strace should be configure'd (and 
compiled) without the -D_LARGEFILE64_SOURCE flag.  But I'm not sure
how to handle it cleanly so I never got around to try to patch it.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] strace doesn't compile on x86_64

[vbr vbr]

I have this issue as well. any clue from the experts?

Thanks
Vincent


On Thu, Jan 12, 2012 at 2:47 PM, Arnout Vandecappelle <arnout@mind.be>wrote:

> On Monday 26 December 2011 16:45:08 Wojciech Zabolotny wrote:
> > Additionally to analyze my problems with udev, I had to compile strace.
> > It didn't compile "out of the box" leading to error:
> >
> >
> /usr/local/wzab/asus_amd/buildroot-2011.11/output/host/usr/bin/x86_64-unknown-linux-uclibc-gcc
> -DHAVE_CONFIG_H -I. -I./linux/x86_64 -I./linux   -Wall -pipe -Os  -fPIC
> -DPIC -D_LARGEFILE_SOURCE
> > -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT file.o -MD -MP -MF
> .deps/file.Tpo -c -o file.o file.c
> > file.c: In function 'printstat64':
> > file.c:1046:16: error: storage size of 'statbuf' isn't known
> >
> > To compile it I had to comment out the line 1010 in file.c:
> > // #if !defined HAVE_STAT64 && defined LINUX && defined X86_64
> > and corresponding line 1040:
> > //#endif
>
>  Yes, I noticed that as well...  strace should be configure'd (and
> compiled) without the -D_LARGEFILE64_SOURCE flag.  But I'm not sure
> how to handle it cleanly so I never got around to try to patch it.
>
>  Regards,
>  Arnout
>
> --
> Arnout Vandecappelle                               arnout at mind be
> Senior Embedded Software Architect                 +32-16-286540
> Essensium/Mind                                     http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR
> Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120114/bea61ea4/attachment.html>