after updating udev to 049 the ipw2100 cant load the firmware after killing the udevd ipw2100 module loads firmware Reproducible: Always Steps to Reproduce: 1.emerge ipw2100 2.modprobe ipw2100 3.dmesg Actual Results: dmesg: ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 1.0.1 ipw2100: Copyright(c) 2003-2004 Intel Corporation ACPI: PCI interrupt 0000:02:02.0[A] -> GSI 11 (level, low) -> IRQ 11 ipw2100: Detected Intel PRO/Wireless 2100 Network Connection ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed. ipw2100: eth1: ipw2100_get_firmware failed: -2 ipw2100: eth1: Failed to power on the adapter. ipw2100: eth1: Failed to start the firmware. ipw2100Error calling regiser_netdev. ipw2100: probe of 0000:02:02.0 failed with error -5 Expected Results: dmesg: ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 1.0.2 ipw2100: Copyright(c) 2003-2004 Intel Corporation ACPI: PCI interrupt 0000:02:02.0[A] -> GSI 11 (level, low) -> IRQ 11 ipw2100: Detected Intel PRO/Wireless 2100 Network Connection my system pentium-m (centrino) kernel gentoo-dev-sources-2.6.9-r9 and -r10 udev 049 ipw2100 1.0.2
problem could be related to baselayout update to version 1.11.8 (bug 74620) it is a ~x86 system stefan
switched from udev to devfs firmware loads without problem stefan
udev-050 dosnt solve the problem
I can not reproduce that here using sys-fs/udev-050 and net-wireless/ipw2100-1.0.2. Did you reboot after installing the new version of udev? Did you run etc-update? Please attach the output of 'emerge -v --info' to this bug report.
I have the same problem. Portage 2.0.51-r8 (default-linux/x86/2004.2/gcc34/2.6, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-gentoo-r10 i686) ================================================================= System uname: 2.6.9-gentoo-r10 i686 Intel(R) Pentium(R) M processor 1500MHz Gentoo Base System version 1.6.8 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Nov 16 2004, 14:54:42)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.8.5-r2, 1.5, 1.4_p6, 1.6.3, 1.7.9, 1.9.3 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r2 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="" ARCH="x86" AUTOCLEAN="yes" BASH_ENV="/etc/spork/is/not/valid/profile.env" CCACHE_SIZE="4G" CFLAGS="-march=pentium-m -O2 -pipe" CHOST="i686-pc-linux-gnu" CLASSPATH="." CLEAN_DELAY="5" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CVS_RSH="ssh" CXXFLAGS="-march=pentium-m -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks fixpackages sandbox sfperms" FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp -P ${DISTDIR} ${URI}" GDK_USE_XFT="1" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" GNOME_USE="gnome gtk2 hal" GRP_STAGE23_USE="ipv6 pam tcpd readline nls ssl gpm perl python berkdb acl ncurses" G_BROKEN_FILENAMES="1" HOME="/root" HOSTNAME="wopr-mobile" INFOPATH="/usr/share/info:/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3/info" JAVAC="/opt/blackdown-jdk-1.4.2.01/bin/javac" JAVA_HOME="/opt/blackdown-jdk-1.4.2.01" JDK_HOME="/opt/blackdown-jdk-1.4.2.01" KDE_USE="-kde -arts -qt" LADSPA_PATH="/usr/lib/ladspa" LDFLAGS="-Wl,-O1" LESS="-R" LESSOPEN="|lesspipe.sh %s" LIBC_USE="nptl userlocales" LOGNAME="root" MAIL="/var/mail/root" MAKEOPTS="-j2" MANPATH="/usr/local/share/man:/usr/share/man:/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3/man:/usr/share/man::/opt/blackdown-jdk-1.4.2.01/man" MOZILLA_USE="mozsvg moznocompose moznoirc moznomail" NOCOLOR="false" OLDPWD="/root" PAGER="/usr/bin/less" PATH="/bin:/sbin:/usr/bin:/usr/sbin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.4.3:/usr/X11R6/bin:/opt/blackdown-jdk-1.4.2.01/bin:/opt/blackdown-jdk-1.4.2.01/jre/bin" PKGDIR="/usr/portage/packages" PORTAGE_ARCHLIST="alpha amd64 arm hppa ia64 m68k mips ppc ppc64 ppc-macos ppc-od s390 sh sparc x86 x86-fbsd x86-obsd x86-od" PORTAGE_BINHOST_CHUNKSIZE="3000" PORTAGE_CALLER="emerge" PORTAGE_GID="250" PORTAGE_MASTER_PID="8253" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" PRELINK_PATH="" PRELINK_PATH_MASK="" PWD="/root" REMOTEHOST="wopr.local" RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp -P ${DISTDIR} ${URI}" RPMDIR="/usr/portage/rpm" RSYNC_RETRIES="3" RSYNC_TIMEOUT="180" SHELL="/bin/zsh" SHLVL="1" SSH_CLIENT="192.168.0.1 2035 22" SSH_CONNECTION="192.168.0.1 2035 192.168.0.2 22" SSH_TTY="/dev/pts/0" SYNC="rsync://rsync.gentoo.org/gentoo-portage" SYSTEM_USE="acpi -apm mmx sse dvd dvdr cdr" TERM="xterm" USE="X acpi alsa apache2 avi berkdb bitmap-fonts cdr crypt cups dvd dvdr encode esd f77 flac font-server foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 hal imagemagick imlib java jpeg libg++ libwww lirc mad mikmod mmx mono motif moznocompose moznoirc moznomail mozsvg mpeg mysql ncurses nls nptl oggvorbis opengl oss pam pdflib perl php png ppds python quicktime readline samba sdl slang spell sqlite sse ssl svg svga tcltk tcpd tiff truetype truetype-fonts type1-fonts userlocales x86 xml2 xmms xprint xv zlib" USER="root" USERLAND="GNU" USE_EXPAND="VIDEO_CARDS INPUT_DEVICES LINGUAS" XARGS="xargs -r" XINITRC="/etc/X11/xinit/xinitrc" XORG_USE="font-server opengl xprint xv bitmap-fonts truetype-fonts type1-fonts" _="/usr/bin/emerge"
Greg, any ideas on this one?
the problem is still there after a reboot do you use the baslayout version 1.11.8 i found it is a problem with udev ipw2100 baselayout emerge -v --info Portage 2.0.51-r8 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-gentoo-r10 i686) ================================================================= System uname: 2.6.9-gentoo-r10 i686 Intel(R) Pentium(R) M processor 1300MHz Gentoo Base System version 1.6.8 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Jun 20 2004, 08:06:17)] distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.8.5-r2, 1.5, 1.4_p6, 1.6.3, 1.7.9, 1.9.3 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r2 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="" ANT_HOME="/usr/share/ant-core" ARCH="x86" AUTOCLEAN="yes" BASH_ENV="/etc/spork/is/not/valid/profile.env" CCACHE_SIZE="2G" CFLAGS="-O3 -march=pentium4 -funroll-loops -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CLASSPATH="." CLEAN_DELAY="5" COLORTERM="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CVS_RSH="ssh" CXXFLAGS="-O3 -march=pentium4 -funroll-loops -fomit-frame-pointer -pipe" DCCC_PATH="/usr/lib/distcc/bin" DESKTOP_SESSION="kde-3.3.2" DISPLAY=":0.0" DISTCC_LOG="" DISTCC_VERBOSE="0" DISTDIR="/usr/portage/distfiles" DM_CONTROL="/var/run/xdmctl" EDITOR="/bin/nano" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp -P ${DISTDIR} ${URI}" GDK_USE_XFT="1" GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/ ftp://mirror.switch.ch/mirror/gentoo/ http://gd.tuwien.ac.at/opsys/linux/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://www.gigaload.org/gentoo.org/ http://gentoo.inode.at/ http://ftp.easynet.nl/mirror/gentoo/" GLIBC_SSP_CHECKED="1" GRP_STAGE23_USE="ipv6 pam tcpd readline nls ssl gpm perl python berkdb ncurses" GS_LIB="/home/stefan/.fonts" GTK2_RC_FILES="/etc/gtk-2.0/gtkrc:/home/stefan/.gtkrc-2.0:/home/stefan/.kde3.3/share/config/gtkrc" GTK_RC_FILES="/etc/gtk/gtkrc:/home/stefan/.gtkrc:/home/stefan/.kde3.3/share/config/gtkrc" G_BROKEN_FILENAMES="1" HOME="/home/stefan" HOSTNAME="endor" INFOPATH="/usr/share/info:/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3/info" JAVAC="/opt/blackdown-jdk-1.4.2.01/bin/javac" JAVA_HOME="/opt/blackdown-jdk-1.4.2.01" JDK_HOME="/opt/blackdown-jdk-1.4.2.01" KDEDIR="/usr/kde/3.3" KDEDIRS="/usr" KDE_FULL_SESSION="true" KDE_MALLOC="1" KDE_MULTIHEAD="false" KDE_NO_IPV6="1" KONSOLE_DCOP="DCOPRef(konsole-10463,konsole)" KONSOLE_DCOP_SESSION="DCOPRef(konsole-10463,session-1)" LADSPA_PATH="/usr/lib/ladspa" LANGUAGE="49" LESS="-R" LESSOPEN="|lesspipe.sh %s" LINGUAS="de" LOGNAME="stefan" LS_COLORS="no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.mng=01;35:*.xcf=01;35:*.pcx=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.avi=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.mov=01;35:*.qt=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.pdf=00;32:*.ps=00;32:*.txt=00;32:*.log=00;32:*.tex=00;32:*.doc=00;32:*.mp3=00;36:*.wav=00;36:*.mid=00;36:*.midi=00;36:*.au=00;36:*.ogg=00;36:" MAKEOPTS="-j3" MANPATH="/usr/local/share/man:/usr/share/man:/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3/man:/usr/share/man::/opt/blackdown-jdk-1.4.2.01/man:/usr/qt/3/doc/man:/usr/lib/wine/man" MOZILLA_FIVE_HOME="/usr/lib/mozilla" NOCOLOR="false" PAGER="/usr/bin/less" PATH="/usr/kde/3.3/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.4.3:/usr/X11R6/bin:/opt/blackdown-jdk-1.4.2.01/bin:/opt/blackdown-jdk-1.4.2.01/jre/bin:/usr/qt/3/bin:/usr/kde/3.3/bin:/usr/NX/bin:/usr/games/bin:/usr/lib/wine/bin" PKGDIR="/usr/portage/packages" PORTAGE_ARCHLIST="alpha amd64 arm hppa ia64 m68k mips ppc ppc64 ppc-macos ppc-od s390 sh sparc x86 x86-fbsd x86-obsd x86-od" PORTAGE_BINHOST_CHUNKSIZE="3000" PORTAGE_CALLER="emerge" PORTAGE_GID="250" PORTAGE_MASTER_PID="10479" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" PRELINK_PATH="" PRELINK_PATH_MASK="" PWD="/home/stefan" QMAKESPEC="linux-g++" QTDIR="/usr/qt/3" RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp -P ${DISTDIR} ${URI}" RPMDIR="/usr/portage/rpm" RSYNC_RETRIES="3" RSYNC_TIMEOUT="180" SESSION_MANAGER="local/endor:/tmp/.ICE-unix/10422" SHELL="/bin/bash" SHLVL="3" SYNC="rsync://rsync.gentoo.org/gentoo-portage" TERM="xterm" USE="X aalib acl acpi alsa apm arts audiofile avi berkdb bitmap-fonts cdparanoia cdr crypt cups directfb divx4linux dvd dvdread encode fam fbcon flac foomaticdb gdbm ggi gif gphoto2 gtk gtk2 icq imagemagick imap imlib java jpeg junit kde libg++ libwww mad maildir mikmod mmx motif mozilla moznocompose moznoirc moznomail mpeg mysql nas ncurses network nls oggvorbis opengl oss pam pcmcia pdflib perl plotutils png povray python qt quicktime readline rtc sdl slang spell sse ssl svga tcltk tcpd tetex theora tiff truetype unicode usb userlocales v4l wifi x86 xine xinerama xml2 xmms xosd xprint xscreensaver xv xvid zlib linguas_de" USER="stefan" USERLAND="GNU" USE_EXPAND="VIDEO_CARDS INPUT_DEVICES LINGUAS" WINDOWID="37748743" XARGS="xargs -r" XCURSOR_SIZE="" XCURSOR_THEME="gentoo-silver" XDM_MANAGED="/var/run/xdmctl/xdmctl-:0,maysd,mayfn,sched,method=classic" XINITRC="/etc/X11/xinit/xinitrc" _="/usr/bin/emerge" stefan
What device node is the ipw2100 driver using to upload firmware in?
Where can I see to which device node the driver tries to load the firmware?
Same problem here. Downgrading baselayout to 1.11.7-r2 fixes the problem.
Adding base-system to CC: since sys-apps/baselayout seems to be the cause of this problem.
downgrading to 11.7-r2 fixes this for me too. I'll see if I can see why.
as discussed with greg and his royal highness Mr Vapier on irc it seems /sbin/rc is doing broken stuff. elif [ -x /sbin/hotplug ] ; then einfo " Using /sbin/hotplug as hotplug agent ..." else Removing that stuff above (as was done in baselayout 1.11.7-2->1.11.8) results in the behaviour described below, broken firmware loading (and probably broken hotplug generally..)
ok, we're talking with upstream about getting udevsend to do our dirty work :) one fix you guys can try to remove the udevsend portion of the if statement in /sbin/rc
Please stop removing mobile@ from CC.
Ok, let's track that down as I'm happy that someone is testing it. I hope the managed events will bring us to the next level in the kernel/userspace integration. Well, breaking something is not really the next level... :) Sorry for the inconvenience the change caused. Can anybody with the failing firmware load please hook a debug script in the hotplug chain: /etc/hotplug.d/default/00-log.hotplug #!/bin/sh echo -e "--------$SEQNUM--------\n"`env`"\n--------$SEQNUM--------\n" >> /dev/.hotplug_d.log And get the log of a successful load. Later change to "managed events" and look at the same event: echo -n /sbin/udevsend > /proc/sys/kernel/hotplug Maybe we do something bad with the hotplug env while handling it with udevd. Thanks, Kay
*** Bug 74620 has been marked as a duplicate of this bug. ***
Downgrading to udev-045 from udev-050 fixes it for me, I'm still running baselayout 1.11.8. I haven't tried any versions between udev-045 and udev-050.
that is because udevsend will only be activated if your udev is 048 or better ;)
Created attachment 46753 [details, diff] shorten the initial timout of udevd to 2 seconds instead of 10
I've attached a patch, that may fix the issue. I've created an artificial kernel module to simulate the error. The environment and the hotplug.d/ handling seems correct. I expect it's a timing issue, cause udevd delays the event execution for missing events for up to 10 seconds to get all events in the right order (sorted by the SEQNUM). The very first events are also delayed for 10 seconds, cause we can't know how long we should wait for earlier ones. I've changed the behavior now to get an initilization phase of 5 seconds, where all events are delayed for a maximum of 2 seconds now. This may fix the firmware loading issue, cause it usually has a timout of 10 seconds. Would be nice, if someone can try this out... Greg will not be able to make a new release until the 2 second week of the new year... Thanks, Kay
Just a quick note to say that the patch seems to have worked for me, loading ipw2100 worked first time off. I haven't tried loading/unloading it several times, but it all seems ok, and if I get any problems later on I'll report it back here.
*** Bug 75723 has been marked as a duplicate of this bug. ***
Ok, this bug is obviously not ipw2100 specific. I tried the patch, but that does NOT work, it appears to do the same thing. Here is the udev log output as requested from that attempt (right now using baselayout 1.11.7-r2 because the default hotplug works there). Note this is WITH the patch in this bug report already, without is the same though :/ === WORKING DEMONSTRATION **MODPROBE PRISM54 --------878-------- DEVPATH=/class/net/eth1 PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add _=/bin/env PWD=/ HOME=/ SHLVL=2 INTERFACE=eth1 SEQNUM=878 --------878-------- **IFCONFIG ETH1 UP --------880-------- DEVPATH=/class/firmware/0000:03:00.0 FIRMWARE=isl3890 PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add _=/bin/env PWD=/ HOME=/ SHLVL=2 SEQNUM=880 --------880-------- --------881-------- DEVPATH=/class/firmware/0000:03:00.0 FIRMWARE=isl3890 PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=remove _=/bin/env PWD=/ HOME=/ SHLVL=2 SEQNUM=881 --------881-------- **RMMOD PRISM54 --------882-------- DEVPATH=/class/net/eth1 PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=remove _=/bin/env PWD=/ HOME=/ SHLVL=2 INTERFACE=eth1 SEQNUM=882 --------882-------- =====NON-WORKING DEMONSTRATION =========ECHO -N /SBIN/UDEVSEND > /PROC/SYS/KERNEL/HOTPLUG========== **MODPROBE PRISM54 --------883-------- SUBSYSTEM=net DEVPATH=/class/net/eth1 PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PWD=/ MANAGED_EVENT=1 SHLVL=1 HOME=/ INTERFACE=eth1 SEQNUM=883 _=/bin/env --------883-------- **IFCONFIG ETH1 UP --------885-------- SUBSYSTEM=firmware DEVPATH=/class/firmware/0000:03:00.0 FIRMWARE=isl3890 PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PWD=/ MANAGED_EVENT=1 SHLVL=1 HOME=/ SEQNUM=885 _=/bin/env --------885-------- --------886-------- SUBSYSTEM=firmware DEVPATH=/class/firmware/0000:03:00.0 FIRMWARE=isl3890 PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=remove PWD=/ MANAGED_EVENT=1 SHLVL=1 HOME=/ SEQNUM=886 _=/bin/env --------886-------- **IFCONFIG ETH1 UP (TRYING AGAIN, DIDN'T WORK) --------888-------- SUBSYSTEM=firmware DEVPATH=/class/firmware/0000:03:00.0 FIRMWARE=isl3890 PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=add PWD=/ MANAGED_EVENT=1 SHLVL=1 HOME=/ SEQNUM=888 _=/bin/env --------888-------- --------889-------- SUBSYSTEM=firmware DEVPATH=/class/firmware/0000:03:00.0 FIRMWARE=isl3890 PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=remove PWD=/ MANAGED_EVENT=1 SHLVL=1 HOME=/ SEQNUM=889 _=/bin/env --------889-------- **RMMOD PRISM54 (FIRMWARE LOADING DIDN'T WORK) --------890-------- SUBSYSTEM=net DEVPATH=/class/net/eth1 PATH=/sbin:/bin:/usr/sbin:/usr/bin ACTION=remove PWD=/ MANAGED_EVENT=1 SHLVL=1 HOME=/ INTERFACE=eth1 SEQNUM=890 _=/bin/env --------890-------- Here is the bad /var/log/messages output ... Notice I tried to ifconfig eth1 up twice to load the firmware, the first one gave a generic error, the second, I got an actual Oops. Dec 26 18:45:16 laptop eth1: islpci_open() Dec 26 18:45:16 laptop eth1: resetting device... Dec 26 18:45:16 laptop eth1: uploading firmware... Dec 26 18:45:26 laptop prism54: request_firmware() failed for 'isl3890' Dec 26 18:45:26 laptop eth1: could not upload firmware ('isl3890') Dec 26 18:45:37 laptop eth1: islpci_open() Dec 26 18:45:37 laptop eth1: resetting device... Dec 26 18:45:37 laptop eth1: uploading firmware... Dec 26 18:45:47 laptop Unable to handle kernel NULL pointer dereference at 0000000000000008 RIP: Dec 26 18:45:47 laptop <ffffffff8027fec1>{firmware_loading_store+97} Dec 26 18:45:47 laptop PML4 3089e067 PGD 30798067 PMD 0 Dec 26 18:45:47 laptop Oops: 0000 [1] Dec 26 18:45:47 laptop CPU 0 Dec 26 18:45:47 laptop Modules linked in: prism54 ohci1394 nvidia snd_intel8x0 snd_ac97_codec snd_mpu401_uart cdc_acm Dec 26 18:45:47 laptop Pid: 12968, comm: firmware.agent Tainted: P 2.6.9-gentoo-r9 Dec 26 18:45:47 laptop RIP: 0010:[<ffffffff8027fec1>] <ffffffff8027fec1>{firmware_loading_store+97} Dec 26 18:45:47 laptop RSP: 0018:000001003044de98 EFLAGS: 00010246 Dec 26 18:45:47 laptop RAX: 0000000000000000 RBX: ffffffff80493110 RCX: 0000000000000028 Dec 26 18:45:47 laptop RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff80493110 Dec 26 18:45:47 laptop RBP: 000001003e4cfbc0 R08: 000000000000000a R09: 0000000000000001 Dec 26 18:45:47 laptop R10: 0000002a9566b9a8 R11: 0000000000000246 R12: 0000000000000002 Dec 26 18:45:47 laptop R13: 0000002a9556c000 R14: 000001003096c980 R15: 000001003044df50 Dec 26 18:45:47 laptop FS: 0000002a95995d50(0000) GS:ffffffff8055cbc0(0000) knlGS:0000000000000000 Dec 26 18:45:47 laptop CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Dec 26 18:45:47 laptop CR2: 0000000000000008 CR3: 0000000000101000 CR4: 00000000000006e0 Dec 26 18:45:47 laptop Process firmware.agent (pid: 12968, threadinfo 000001003044c000, task 000001003046e030) Dec 26 18:45:47 laptop Stack: 0000000000000002 0000000000000002 000001003c494da0 ffffffff8027da3f Dec 26 18:45:47 laptop 0000000000000002 ffffffff8019ca02 0000000000000001 000001003096c980 Dec 26 18:45:47 laptop 0000000000000000 000001003044df50 Dec 26 18:45:47 laptop Call Trace:<ffffffff8027da3f>{class_device_attr_store+31} <ffffffff8019ca02>{sysfs_write_file+178} Dec 26 18:45:47 laptop <ffffffff8016bdd6>{vfs_write+214} <ffffffff8016bf33>{sys_write+83} Dec 26 18:45:47 laptop <ffffffff801102ba>{system_call+126} Dec 26 18:45:47 laptop Dec 26 18:45:47 laptop Code: 48 8b 78 08 e8 96 3f ee ff 48 8b 45 68 48 c7 40 08 00 00 00 Dec 26 18:45:47 laptop RIP <ffffffff8027fec1>{firmware_loading_store+97} RSP <000001003044de98> Dec 26 18:45:47 laptop CR2: 0000000000000008 Dec 26 18:45:47 laptop <3>prism54: request_firmware() failed for 'isl3890' Dec 26 18:45:47 laptop eth1: could not upload firmware ('isl3890') Dec 26 18:46:23 laptop eth1: removing device Dec 26 18:46:23 laptop Unloaded prism54 driver Here is a _good_ loading message: Dec 26 18:51:18 laptop eth1: islpci_open() Dec 26 18:51:18 laptop eth1: resetting device... Dec 26 18:51:18 laptop eth1: uploading firmware... Dec 26 18:51:18 laptop eth1: firmware uploaded done, now triggering reset... -Brad
Dec 26 18:45:37 laptop eth1: uploading firmware... Dec 26 18:45:47 laptop Unable to handle kernel NULL pointer dereference at 0000000000000008 RIP: Dec 26 18:45:47 laptop <ffffffff8027fec1>{firmware_loading_store+97} Huh, we got a kernel bug in the firmware_class. The attempt to write to the file while at the same time the driver removes it after the timeout oopses the kernel. This needs to be fixed too. Brad, are you sure, that you've killed the old running udevd? The 10 seconds delay (in your logs) should not happen with that patch and I can't reproduce it here.
well, I had rebooted, so the new one was definitely running ... here's the steps I did ... Upgraded to udev-050+patch & baselayout-1.11.8, rebooted. Firmware loading failed so then I reverted to baselayout-1.11.7-r2, rebooted and firmware loading worked (but wasn't using udevsend obviously) Then I ran the tests I posted ... so it went through a couple of reboots, so the old udevd was definitely not running ... All I did to apply the patch was add it to the udev-050.ebuild under unpack() to epatch it, the relevant output of the emerge was here (the udev-050.patch is your patch): >>> emerge (1 of 1) sys-fs/udev-050 to / >>> md5 src_uri ;-) udev-050.tar.bz2 >>> Unpacking source... >>> Unpacking udev-050.tar.bz2 to /var/tmp/portage/udev-050/work * Applying udev-050-udev_volume_id.patch ... [ ok ] * Applying udev-050.patch ... [ ok ] >>> Source unpacked. /usr/bin/x86_64-pc-linux-gnu-ar Creating udev_version.h Building ccdv ...snip... -Brad
I just found the reason for the failing operation by a second look at your logs. I've never seen such a a thing before - you completely miss one event seqence. This will cause the daemon to wait for the missing one too long and the firmware_class will timeout. Seems like the udevsend switch exposed a driver bug here. I will look at your driver sources tonight, if I can find something suspicious. --------878-------- DEVPATH=/class/net/eth1 ... --------880-------- DEVPATH=/class/firmware/0000:03:00.0 --------883-------- DEVPATH=/class/net/eth ... --------885-------- DEVPATH=/class/firmware/0000:03:00.0
I'm pretty sure now, that this kernel bug is causes the missing sequence: http://linus.bkbits.net:8080/linux-2.5/cset@41798d05sEo-J9zrpeXvVYgctOLw1w It is fixed 10 weeks ago and it would be nice to know if a later kernel fixes this.
I am still experiencing this problem with 2.6.10-gentoo-r1.
> I am still experiencing this problem with 2.6.10-gentoo-r1. Would be nice if you can record the seqences with a script: http://bugs.gentoo.org/show_bug.cgi?id=74786#c16 and look if the kernel still skips sequence numbers, which is creating the timeout in udev.
Well, at least gentoo-dev-sources-2.6.10-r1 doesn't boot correctly on my AMD64 (keyboard fails to work), I have yet to figure out what causes the issue (e.g. if vanilla 2.6.10 works or not). My working kernel is 2.6.9-gentoo-r9. I can apply that patch from bkbits though to 2.6.9 and see if that helps if I can't get 2.6.10 vanilla up... As far as missing events go ... it doesn't seem to affect anything with the hotplug set to /sbin/hotplug instead of udevsend ... (though the missing events do exist in both .. odd that I hadn't noticed) -Brad
See bug 75394 for more ways udevsend is broken
Hi, I use ipw2100 and prism54 with baselayout 1.11.8 and udev-0.50 and gentoo-dev-sources-2.6.10-r1. I did a reboot, and everything works here! So my problems were fixed when changing to the new kernel.
base-system, what is the status of this bug?
I am still experiencing this problem with sys-kernel/gentoo-dev-sources-2.6.10-r2, sys-apps/baselayout-1.11.8, sys-fs/udev-050, and net-wireless/ipw2100-1.0.2-r1. @30: I currently have no time to investigate this issue further than testing whether or not it works, sorry.
I seem to be having similar problems with Prism54. Upgrading from gentoo-dev-sources-2.6.8-r3 to 2.6.10-r1 did not resolve for me, nor did downgrading from baselayout 1.11.8 to 1.11.7-r2. I'm pretty flummoxed on how to debug, but can provide root access to a dev if required.
It is very likely that this patch solves the issues: http://bugs.gentoo.org/attachment.cgi?id=46753&action=view The current udev has a timeout of 10 seconds to wait for missing event-sequence-numbers. The very first event is also delayed for 10 seconds, as we can't be sure that the event that starts udevd is really the first one. The problem with the setup is that the init script kills udevd and all later events including the firmware load event will be delayed by exactly 10 seconds, which is also the timeout of the firmware_class. The patch reduces the startup timeout to 2 seconds which should solve the problem. We may even change udevd not to delay any firmware event if this is really needed.
I just joined the discussion here - I have the same problem with the IPW2200 driver, udev 0.50 and baselayout 1.11.8. The output I receive when I modprobe ipw2200 without the patch is: ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection ipw2200: ipw-2.2-boot.fw load failed: Reason -2 ipw2200: Unable to load firmware: 0xFFFFFFFE ipw2200: failed to register network device ipw2200: probe of 0000:02:03.0 failed with error -5 I don't have kernel debugging enabled, but if you want me to enable it let me know. Anyways, I applied the new patch in comment 37 to udev and re-emerged udev and there was no change. I get the same output as I listed above. Hope this helps!
> The output I receive when I modprobe ipw2200 without the patch is: o This does happen after the system is up and you modprobe the driver manually? o What kernel version you are using? Kernel 2.6.9 is known to have holes in the sequence numbers, which may cause this. o Please log the hotplug timing with a script: http://bugs.gentoo.org/attachment.cgi?id=46975&action=view Just place it as: /etc/hotplug.d/default/00-log.hotplug 0 If this all does not lead to the reason, it would be nice if you can pass "make DEBUG=true" to the udev build process and post the debug from syslog.
Well, I upgraded my kernel to 2.6.10-gentoo-r3 and using udev-0.50 and the patch that was posted, it looks like everything works now. I tried using the log file that was posted but I couldn't find the log anywhere. Where would the log be located? I figured that once the modprobe worked, everything was better so I didn't compile debugging into udev. If you still want me to do so, I can. The kernel I was using before was 2.6.8.1. I guess that probably was the source of the problem. Thanks for all the help.
> I couldn't find the log anywhere. It may be in /dev/.hotplug_d.log. You may just remove the logger in /etc/hotplug.d/default/00-log.hotplug now. > I didn't compile debugging into udev. If you still want me to do so, I can. No, I have noo other idea than the startup timeout and the seqence number holes in the older kernels. If it works now, I'm happy. :)
Hello, I got trouble with my ipw2100-driver too. It doesn't work for me since version >=1.x Versions prior to this do work. At boottime I get this error: * Loading networking modules ... * modules: wireless ifconfig adsl dhcpcd * ifconfig provides interface * dhcpcd provides dhcp [ ok ] * Configuring wireless network for eth1 * Looks like there was a probem loading the firmware for eth1 * Failed to configure wireless for eth1 dmesg says: ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' ieee80211_crypt: registered algorithm 'CCMP' ieee80211_crypt: registered algorithm 'TKIP' ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 1.0.2 ipw2100: Copyright(c) 2003-2004 Intel Corporation ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 11 ACPI: PCI interrupt 0000:02:02.0[A] -> GSI 11 (level, low) -> IRQ 11 ipw2100: Detected Intel PRO/Wireless 2100 Network Connection So I'm not sure if this is the same bug. So I tried some diferent configurations: kernel-2.6.9-gentoo-r6 ipw2100-1.0.2 baselayout-1.11.8 kernel-2.6.9-gentoo-r6 ipw2100-1.0.2 baselayout-1.11.7-r2 kernel-2.6.10-r1 vanilla with fbsplash and swsusp2 ipw2100-1.0.2 baselayout-1.11.8 But nothing changed. May this problem be related to the discussed one? If so, I would like to help resolving it by collecting information and testing.
You may try this patch: http://bugs.gentoo.org/attachment.cgi?id=46753&action=view Some people reported, that firmware loading was back working after applying it. Or wait for the next release of udev, which is expected during the next few days. Thanks, Kay
Okay, I got it running now. This is what I did: Actually I wasn't using udev-050, I used udev-045. So I upgraded to udev-050 and from this moment on I had exactly the same problems like described here. (dmesg output etc. was the same). After applying the timing-patch for udev-050 and upgrading to ipw2100-1.0.2-r2 I got my WLAN working. Thank you very much Jan
Works for me, too, after applying the attached patch. (This hopefully gets into portage in time for 2005.0.)
with the new 2.6.10-rX kernel it loads the firmware without the udev patch stefan
@46: It did not for me. Could this either be related to a kernel misconfiguration or hardware/laptop specific?
@47 I use : ipw2100-1.0.2-r2 udev-050 without the patch baselayout-1.11.8 gentoo-dev-sources-2.6.10-r6 for kernelconfig see attachment below stefanb
Created attachment 49756 [details] Kernelconfig for post 48 my kernelkonfig i hav no more problems to load the firmware
> It did not for me. It does not work, even with the udev patch applied? Can you please try to comment out the "kill udevd" in the initscripts, if gentoo is still doing this, which is not a good idea as events may get lost by doing this.
@50: With the patch it works for me, like I said in #45.
It doesn't work anymore for me. In post #44 I got it running. But after a long night sshing to a remote machine over WLAN I had the same problems I'm experiencing the whole time. In some time-intervals the connection get stalled and the firmware reloads due to a fatal hardware error. At the next morning it didn't work anymore and I had the same problem as I described in post #44. Now I switched back to Kernel 2.6.9-gentoo-r13, devfsd and ipw2100-0.56-r3. Now it works. Still got the problems with fatal hardware failure and firmware-restarts, but at least it works. I'm sure my problem is different to this one discussed here, because the firmware loads flawless in all cases. So I'll make up a new bugreport in about two weeks (when I got some more time to take a closer look at my problem). bye Jan
The firmware problem is covered in upstream bug report at http://bughost.org/bugzilla/show_bug.cgi?id=245 I am working with the upstream developers on this.
Works for me as of sys-fs/udev-051.
Ok, I think everything has been fixed for this bug now, right? If not, please reopen it with the new information.
udev 056 shows the same problems, 054 worked, I think we have to reopen this bug
54 worked for me, 56 is broken again. let me know how I can help, I have the hardware.
I have the hardware as well.
udev 0.56 works on my system without any problems witch version of baselayout and witch kernel do you use on your systems stefan
re-opening.
hallo is there anyone with a not working ipw2100 with udev then please post a comment if not i will close the bug again stefan
Since it wasn't you, who re-opened the bug, you should just leave it be.
I have a ipw2200 card which shows this issue
Andrew, please attach the output of 'emerge --info' and list which versions of sys-apps/baselayout, sys-fs/udev and net-wireless/ipw2100 you have installed.
Portage 2.0.51.21-r1 (default-linux/amd64/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-gentoo-r8 x86_64) ================================================================= System uname: 2.6.11-gentoo-r8 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.11 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [disabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.5-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O3 -fomit-frame-pointer -mmmx -m3dnow -msse -msse2 -mfpmath=sse,387 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=k8 -O3 -fomit-frame-pointer -mmmx -m3dnow -msse -msse2 -mfpmath=sse,387 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://www.wizards-of-chemistry.net/gentoo-portage" USE="amd64 X acl acpi adns alsa arts artswrappersuid bash-completion bcmath berkdb bitmap-fonts bzip2 bzlib cdparanoia cdr codecs crypt cups curl dba dga dvd dvdread esd exif fam fastcgi fftw flac font-server fortran freetype ftp gd gdbm gif gimp gimpprint gnuplot gphoto2 gpm gsl gtk gtk2 imagemagick imap imlib ipv6 java jp2 jpeg jpeg2k junit kde latex libwww lzw lzw-tiff mad mikmod motif moznoirc moznomail moznoxft mp3 mupad-noscilab mysql nas ncurses nls nptl nptlonly ogg opengl oss pam pcmcia pcre pdf pdflib pear-db perl php png ppds python qt quicktime readline rtc samba scanner sdl session shared simplexml slang soap sqlite ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xine xml2 xmms xosd xpm xrandr xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY sys-apps/baselayout-1.11.11-r3 net-wireless/ipw2200-1.0.3 not working with:sys-fs/udev-056 working with 054
That combination works here - perhaps this is a 64bit issue?
This indeed works with newest ~baselayout on amd64. Seems to be a problem with slightly older baselayout.
OK, re-closing. Thank you for confirming.
I think this bug needs to be reopened for ipw2200 because I'm receiving the same problem (if I should file this as a new bug, let me know). Version numbers and info are listed below. Basically, if I load ipw2200 on boot, the eth1 device is not created and I have to unload the module and reload it. baselayout-1.11.11-r3 udev-056 ipw2200-1.0.3 ipw2200-firmware-2.2 emerge --info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.200 41102-r1, 2.6.11-gentoo-r8 i686) ================================================================= System uname: 2.6.11-gentoo-r8 i686 Intel(R) Pentium(R) M processor 1.60GHz Gentoo Base System version 1.6.11 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 29 2005, 02:37:17)] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe -ftracer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/ config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe -ftracer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acpi alsa apm avi berkdb bitmap-fonts bonobo cdr crypt emboss encode fam foomaticdb fortran gdbm gif gpm gtk gtk2 gtkhtml guile imagemagick imlib ipv 6 java jpeg junit libg++ libwww mad mikmod mmx mp3 mpeg ncurses nls nptl nptlonl y ogg oggvorbis opengl pam pdflib perl png python quicktime readline sdl spell s se sse2 ssl svga tcpd tiff truetype truetype-fonts type1-fonts vorbis xml xml2 x mms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS Let me know if I should create a new bug. Thanks
I can confirm post #69. I'm on the same version numbers, and the problem is identical (having to reload the module to get the device up). First time through, the error message about not being able to load firmware appears.
I just upgraded to baselayout-1.11.12 and this bug has been fixed by it.
