On Thursday 14 April 2011 18:13:09 Kay Sievers wrote:
> On Thu, Apr 14, 2011 at 18:53, Jason Vas Dias <jason.vas.dias@xxxxxxxxx> wrote:
> > I upgraded to the gentoo version of udev-167 today and found that my wireless interface ( a b43 )
> > was disabled, that I only now ( a few hours later ) now found was because /lib64/udev/firmware
> > seems to be thoroughly broken (and somehow the gentoo's firmware loading rules usually in
> > /etc/udev/rules.d/50_firmware had disappeared - maybe because they couldn't get this program
> > to work either ? )
> >
> > Having cobbled together a new /etc/udev/rules.d/50_firmware :
> >
> > SUBSYSTEM=="firmware", ACTION=="add", RUN+="/lib64/udev/firmware"
> >
> > "firmware" simply emits some error message the first line of which contains "libusb: main.c:"
> > for valid arguments and does nothing . I double, triple-checked that the correct "FIRMWARE_PATH"
> > is generated during config .
> >
> > But the whole idea of using some complicated libusb internal function, or even any new executable program,
> > is incomprehensible to me - to implement these few lines of shell script , which I ended up having to write,
> > because udev's complicated libusb method failed - so I'm posting here in the hope that udev will see sense
> > and give us a working firmware script instead of some broken libusb using executable, and to help anyone
> > else caught by the same issue:
> >
> > to fix, as root:
> > # mv /lib64/udev/firmware /lib64/udev/firmware.broken
> > # cat <<'EOF'
> > #!/bin/bash
> > logger "FIRMWARE: $1 $2"
> > if ! echo "$1" | egrep -q '^--firmware' ; then
> > logger "FIRMWARE: bad firmware arg: $1";
> > exit 1;
> > elif ! echo "$2" | egrep -q '^--devpath' ; then
> > logger "FIRMWARE: bad devpath arg: $2";
> > exit 1;
> > fi
> > firmware=$1
> > firmware=${firmware#--firmware=}
> > devpath=$2
> > devpath=${devpath#--devpath=}
> > if [ ! -f /sys/${devpath}/loading ] ; then
> > logger "FIRMWARE: no loading: /sys/${devpath}/loading";
> > exit 1;
> > fi
> > if [ ! -f /sys/${devpath}/data ] ; then
> > logger "FIRMWARE: no data: /sys/${devpath}/data";
> > exit 1;
> > fi
> > echo 1 > /sys/${devpath}/loading
> > cp -fp /lib64/firmware/${firmware} /sys/${devpath}/data;
> > status=$?;
> > echo 0 > /sys/${devpath}/loading
> > logger "FIRMWARE: copied /lib64/firmware/$firmware to /sys/${devpath}/loading OK: $status"
> > exit $status;
> > EOF
> > >> /lib64/udev/firmware; chmod a+rx /lib64/udev/firmware
>
> There is something seriously broken on your system:
>
> First, there is no /lib64/udev/ directory for udev ever. Gentoo should
> finally stop doing that nonsense. /lib64 is for shared libs only, the
> application private directory is /lib/udev/ regardless of the
> architecture.
>
> Also all udev default rules like the firmware loader live in
> /lib/udev/rules.d/, not in /etc/udev/rules.d/. /etc is only for
> admins, not for packages.
>
> Udev's firmware binary does never link against libusb:
> $ # ldd /lib/udev/firmware
> linux-vdso.so.1 => (0x00007fff011ff000)
> librt.so.1 => /lib64/librt.so.1 (0x00007fd2e37ea000)
> libc.so.6 => /lib64/libc.so.6 (0x00007fd2e347d000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007fd2e3279000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fd2e3c12000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd2e305c000)
>
> The udev shipped rules file looks like this:
> $ cat /lib/udev/rules.d/50-firmware.rules
> # do not edit this file, it will be overwritten on update
>
> # firmware-class requests, copies files into the kernel
> SUBSYSTEM=="firmware", ACTION=="add", \
> RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
>
> Seems there is a lot to do to clean up the mess you have on your box.
> That's nothing we can fix here. :)
>
> > P.S. why doesn't udev use libusb-1.0 ? Rebuilding against libusb-0.1-compat didn't help though.
>
> That should work fine, and does work here.
>
> Kay
>
Hi - sorry, but I disagree with several points made above :
> there is no /lib64/udev/ directory for udev ever
then why does your configure script support the '--with-rootlibdir=/lib64' setting ?
If you intend not to support a different rootlibdir, then you should enforce that by refusing to install on one -
my system has being running fine for years with no /usr/lib or /lib directories -
I use both elf_x86_64 binaries, which link to /usr/lib64, and elf_i386 binaries,
which link to /lib64 - this is simply done by editing /etc/ld.so.conf and /usr/lib{64,32}/lib{c,pthread}.so
linker scripts (and by changing the default dynamic-linker for gcc to /lib%{-m32:32}%{!-m32:64}/ld-linux.so.2
in gcc's linux.h / linux64.h header files before building (now on gcc-4.6.0, which passes all tests in test suite).
Either say you do not support any other linux platform than Redhat / Fedora derived ones , or support them .
> Udev's firmware binary does never link against libusb:
but it refuses to build without libusb if '--disable-extras' is not given to configure, and without enabling extras, you
don't get any firmware loading functionality at all -
I infer that in your opinion, firmware loading functionality is an optional extra.
Ever tried to do a network boot over a b43 wireless card without firmware loading enabled ?
That might show you how "optional" it is.
> /lib/udev/rules.d/, not in /etc/udev/rules.d/. /etc is only for
If you do not support your configure script's "libexecdir" setting, then why does it provide one ?
I use this configure command line:
$ ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share \
--sysconfdir=/etc --localstatedir=/var/lib --prefix=/usr --sysconfdir=/etc --sbindir=/sbin --libdir=/usr/lib64 --with-rootlibdir=/lib64 --libexecdir=/lib64/udev \
--enable-logging --enable-static --without-selinux --disable-introspection --with-firmware-path=\"/lib64/firmware\"
which does NOT complete unless libusb is installed, and it MUST be libusb-0.1, not libusb-1.0 - why ?
Maybe the libusb message I was seeing was an artefact, but really, why are you using an executable to do a shell script's job ?
Do you expect people to modify udevd to load /lib/udev/firmware with GDB to diagnose firmware loading problems ?
I only installed the gentoo portage version of udev because the problem arose with the vanilla build - and
there were still a few old gentoo udev scripts lying around, such as /etc/udev/rules.d/50_firmware that got removed .
RE:
> # firmware-class requests, copies files into the kernel
> SUBSYSTEM=="firmware", ACTION=="add", \
> RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
Thanks for the correct 50_firmware file settings, but they make no difference - if udevd runs /lib64/udev/firmware executable, firmware fails to load and the system hangs
for @ 5 minutes .
I guess we just must be from different planets of programming - I cannot understand why this /lib64/udev/firmware executable is required to do the job of a shell script
of a few lines.
Thanks & all the best,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
