On Thu, Apr 14, 2011 at 21:03, Jason Vas Dias <jason.vas.dias@xxxxxxxxx> wrote:
> 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.
> 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 ?
_My_ script supports everything, but _your_ options are broken. Nobody
prevents --libdir=/tmp if you like to do that too. :)
> 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 .
Nonsense. "Application directories" are not arch specific, and do not
belong into that dir. It's nothing about Red Hat or anybody else, it's
just some total nonsense Gentoo is doing. Maybe you should have a
/usr64/ and /etc64 too. :)
>> 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 ?
It does. Udev supports and needs both. Please read the man page why.
> 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 ?
Because it's a different API and I don't care to convert rather exotic
tools I personally don't use. Nothing in core udev uses it.
> 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 ?
Because we need to encode filenames in that binary.
> Do you expect people to modify udevd to load /lib/udev/firmware with GDB to diagnose firmware loading problems ?
No, I expect them to configure and install udev correctly and it will
work out-of-the-box, like for everybody else for years. :)
> 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 .
Such file was never part of udev. Not sure what you install on your system.
> 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.
Good luck,
Kay
--
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
