Bug 188728 - Problem loading modules specified in modprobe.conf in fc5 smp
Summary: Problem loading modules specified in modprobe.conf in fc5 smp
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-04-12 17:13 UTC by Mike Cohler
Modified: 2015-01-04 22:26 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-17 22:40:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Mike Cohler 2006-04-12 17:13:53 UTC
Description of problem:entry in modprobe.conf seems to not load module after
boot but does after removing the module !


Version-Release number of selected component (if
applicable):kernel-smp-2.6.15-1.2054_FC5


How reproducible:Every time


Steps to Reproduce:
0.  Install kernel-smp-devel, install ieee80211 version 1.1.13, install ipw3945
version 0.0.73 from sourceforge. (and microcode and regulatory daemon)
1.Boot
2.ifup eth1 - get message below:
3. modprobe -vr ipw3945 -  this does shut down the ipw3945d daemon
4. modprobe -v ipw3945  - this time it does load the modules and start the
ipw3945 daemon !
  
Actual results:Get terminal message: 
ipw3945 device eth1 does not seem to be present, delaying initialisation. 

At this point wireless is not up. BUT see below.


Expected results:The regulatory daemon (ipe3945) should start.


Additional info: modprobe.conf has the lines:

alias eth0 b44
alias eth1 ipw3945
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0
remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin
/modprobe -r --ignore-remove snd-hda-intel
install ipw3945 /sbin/modprobe -q eth0; /sbin/modprobe --ignore-install ipw3945;
 sleep 0.5; /sbin/ipw3945d --quiet
remove ipw3945  /sbin/ipw3945d --kill; /sbin/modprobe -r --ignore-remove ipw3945

So immediately after boot ipw3945d is not running but once "modprobe -r ipw3945"
is executed, and then immediately afterwards "modprobe ipw3945" does run the
daemon and the wireless network starts and runs well.

This is pointing to a bug in initscripts possibly ?

Comment 1 Mike Cohler 2006-04-12 17:21:30 UTC
I cannot use kernel 2.6.16 in this machine running fc5 at present because this
newer kernel causes problems with Crossover Office 5.0.1 Pro running MS Office
XP which is essential for this computer.

So I am currently stuck - between the ability to run with no wireless on kernel
2.6.15 (smp) but able to use MS Office, or to try installing kernel 2.6.16 and
attempt to install the ipw3945 driver, but then lose the ability to have
Crossover functioning with Office XP.

Comment 2 Mike Cohler 2006-04-13 21:30:39 UTC
After further investigation, I have discovered that in fact the modules ipw3945
and ieee80211 were loaded during the boot, but crucially the regulatory daemon,
ipw3945d was NOT running.

In order to get the daemon running at boot I found that appending the line:
/sbin/ipw3945d --quiet
to the end of the file /etc/rc.local
Now makes the daemon start during the boot process and the wireless interface is
running perfectly as soon as the machine has booted up.

I am still puzzled as to why the daemon was not running with the original setup,
given that this same line is part of install line in the modprobe.conf file. 

Also others have reported that this same setup without my workaround was
apparently working in fc4 without the need for any further amendment.  Since
this is a new machine I did not get the chance to test under fc4 (smp).

If there is any clue as to why the workaround is required then perhaps this will
lead to a fix which allows the daemon to run without the additional line in
rc.local ?

Hence I guess this is a temporary fix rather than a real solution to the
original problem ?

Thanks

Mike

Comment 3 Dave Jones 2006-10-16 18:08:56 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 4 Brian Millett 2006-10-16 20:18:17 UTC
FC5, kernel 2.6.18-1.2200.fc5smp

Well, the ipw3945 module still does not load correctly.  This is my
/etc/modprobe.d/ipw3945

[bpm]$ cat ipw3945
install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ;
/sbin/ipw3945d --quiet
remove ipw3945 /sbin/ipw3945d --kill ; /sbin/modprobe -r --ignore-remove ipw3945

After booting, the ipw3945d is NOT running.  If I do a modprobe -r ipw3945, then
a modprobe ipw3945, then the daemon starts up correctly.

So, I would have to say that this is still broke.

Comment 5 Mike Cohler 2006-10-17 06:36:14 UTC
I have just tried with the new kernel also - but I cannot compile the driver so
cannot test.  I have tried with both the 1.0.12 and 1.1.0 driver but "make" no
longer completes.  Which version of the driver did you use, Brian? Also which
versions of the microcode and regulatory daemon?  I am using microcode
ipw3945-ucode-1.13 , and regulatory daemon ipw3945d-1.7.22.

Mike

Comment 6 Mike Cohler 2006-10-17 09:07:36 UTC
I upgraded to ieee80211 version 1.2.15 and included the
ieee80211-1.2.15-patch_kernel.patch from sourceforge, then compiled and
installed. I also added the patches for ipw3945.k and ipw3945.h before compiling
the driver version 1.1.0 and then loaded the ipw3945 module. I still needed the
/sbin/ipw3945d --quiet
added to the end of the file /etc/rc.local for the daemon to run on boot.

Mike

Comment 7 Brian Millett 2006-10-17 11:39:44 UTC
Had this patch/email from Paul Johnson:

SUSPEND WORKS with new kernel!  I one-by-one removed RPMS from utopia,
and tested suspend.  As soon as I removed pm-utils and re-installed
the one from Fedora Core, then the suspend to RAM worked, and wake-up
worked as well!

This has a SATA hard disk, it wakes up great.  I'm using the Nvidia
driver version 8774 with the kernel-smp that is in updates-testing,
and the ipw3945 wireless driver 1.0.12 with the following patch
applied (from the devel list)

--- Makefile.old        2006-09-23 13:06:50.000000000 -0700
+++ Makefile    2006-09-23 13:06:50.000000000 -0700
@@ -92,6 +92,8 @@
ifeq ($(IEEE80211_API),)
        IEEE80211_API := $(shell [[ "$(IEEE80211_VER)" == 1.1.14* ]] && \
                { echo "2" ; } || \
+               [[ "$(IEEE80211_VER)" == git-1.1.13* ]] && \
+               { echo "2" ; } || \
                { ver=$(IEEE80211_VER); ver=$${ver\#*.} ; echo $${ver%.*} ; })
        EXTRA_CFLAGS += -DIEEE80211_API_VERSION=$(IEEE80211_API)
endif

Spacing is messed up by cut/paste, but you see the 2 lines are
necessary to make ipw3945 compile.  It too suspends and resumes great.

I have NO special adjustments in acpi scripts, no special nothing.
Suspend just works, as PROMISED.

Comment 8 Dave Jones 2006-10-17 22:40:03 UTC
great!


Comment 9 Brian Millett 2006-10-18 00:28:41 UTC
No, I don't think it means what you think it means.  The above patch was to be
able to compile the ipw3945 module.  However, the bug, or condition still
exists.  That the modprob.conf definition does not correctly load & setup the
ipw3945 module.

Sorry for the confusion.

Comment 10 Dave Jones 2006-10-18 01:04:06 UTC
I don't think this is a general problem, but something specific to that module.
 I recommend asking on the ipw3945 mailing list for help.



Note You need to log in before you can comment on or make changes to this bug.