Bug 304652

Am I right that you see "iwl3945: ipw going down" in the kernel log otherwise, with the interface being non-functional afterwards?

Yes

iwlwifi 0.1.2 as in stable should fix this. Could you give it a try?

Tried 0.1.12 from factory, didn't change anything.

On my system disable_hw_scan helps, too.  Otherwise ipw usually goes down within five minutes after associating with my access point at home.

thoenig@zimtstern:~> rpm -qa |grep iwl
iwl3945-ucode-2.14.1.5-5
iwlwifi-kmp-default-0.1.12_2.6.22.5_4-2

While talking to Mr. Gogol to acquire more information on this issue my way crossed some post which describes the closed source firmware scan as pointless.  Further the post claims that the scan of mac80211 is sufficient.

Thus, I'm asking why we don't set disable_hw_scan=1 by default?

I think we should go with disable_hw_scan=1. I couldn't find any drawbacks so far. I'm going to submit a package with changed default.

Great.

Holger, as iwl3945 was working for you without disable_hw_scan=1 before can you please use it for a while with setting this parameter to see if it brings any regression for you?  Thanks.

I will give it a try.

So things improved a bit with latest versions.
I am able to get a wireless connection at home (wpa encrypted) without "disable_hw_scan". This didn't work with plain beta2.

However, two problems still remain
- iwl3945 is not loaded automatically
- I am not able to connect to 'onenet' (unencrypted, but not publishing its essid)

The latter is a known problem. Hidden SSID does not work in conjunction with wpa_supplicant, that means, no WPA with hidden APs and no NetworkManager at all with hidden APs yet. Using ifup, you should be able to connect to hidden non-WPA APs. iwl3945 not loading automatically is strange. Maybe a udev problem. Kay, any idea?

"no WPA with hidden APs and no NetworkManager at all with hidden APs yet. Using ifup, you should be able to connect to hidden non-WPA APs."

Since ifup just passes the request to NetworkManager, this means that I have to disable NetworkManager alltogether, right ?

Yes.

What does:
  grep . /sys/bus/pci/devices/*/modalias
print?

What does:
  modinfo iwl3945 | grep alias
print?

Created attachment 162209 [details]
output of grep

Created attachment 162211 [details]
output of alias

If I'm not mistaken, the last but one line from the grep output should match the modules alias.

Just an update regarding comment #7: I'm using the 'disable_hw_scan=1' for several days now and didn't note any blackouts or such.

Confirmed, it doesn't seem to harm. It was required with Beta2 but my system works now (post Beta2) without this parameter.

What does:

/sbin/modprobe --first-time -n -v pci:v00008086d00004227sv00008086sd00001011bc02sc80i00

print?

WARNING: module 'ipw3945' is unsupported
WARNING: module 'iwl3945' is unsupported
FATAL: Module pci:v00008086d00004227sv00008086sd00001011bc02sc80i00 not found.

Remove the entries from /etc/modprobe.d/unsupported.blacklist. Don't know who made that entries.

Created attachment 162273 [details]
bzipped tar of /etc/mod*

iwl, 3945 or 8086 do not appear in any /etc/mod* files. See attachment for full list of files.

Looks like an issue with the "supported modules" feature, added to module-init-tools.

Adding agruen and zoz because comments #13 to #22 contain some information about problems with automatic loading of the iwl3945 module.

for now, I followed comment #20 and did the following change to
/etc/modprobe.d/unsupported.blacklist

-  include modules.unsupported.blacklist
+  #include modules.unsupported.blacklist

With the current setting (wlan blacklisted) neither iwl3945 nor ipw3945 are auto-loaded in 10.3

Marian, do the module-init-tools create the blacklist file?

Could bug 308962 be related somehow?

Yes, module-init-tools creates the modules.unsupported.blacklist and /etc/modprobe.d/unsupported.blacklist. But for openSUSE the include line should just be a comment and not active. The blacklist is on only in SLE*.

Michal, can you please fix this?

Klaus, was this a new install or an update (from 10.2?).

It was an upgrade from 10.2 to 10.3beta2 at first. I'm currently running 10.3B3 on my laptop.

Well, and do you happen to remember if the autoloading of unsupported modules was enabled (ie. the default LOAD_UNSUPPORTED_MODULES_AUTOMATICALLY=yes in /etc/sysconfig/hardware/config)?

Has anyone else seen this?

As a band-aid, I could change the package to allways install the commented out file, because we aren't using this package in any SLE* product yet...

/etc/sysconfig/hardware/config is empty on the current system. I do not know if this file was present before, sorry.

I did use the ipw3945 with the 10.2 installation though.

BTW, I did a 10.2->10.3 beta3 update and the line was commented out as expected...

For a while I thought grep or sed could have been missing when the %post scriplet was run, but the package requires util-linux which requires sed and coreutils, so that part sould be ok (esp. during an update).

So then the origin of this bug gets clearer.

If binaries from util-linux are used in %pre or %post scripts, you have to _pre_require util-linux

(In reply to comment #34 from Klaus Kaempf)
> If binaries from util-linux are used in %pre or %post scripts, you have to
> _pre_require util-linux

Right, prerequiring sed and grep is definitely correct (will submit shortly), but I'm not sure if this causes the problem, first because you did an update, so there should have been at least the 10.2 versions, second Requires vs. PreReq should make no difference to the sorting AFAIK (correct me if I'm wrong).

I submitted module-init-tools with "PreReq: grep sed", thanks for pointing out. Let's hope this fixes it, if not please reopen. I also asked on opensuse-factory if people could check their /etc/modprobe.d/unsupported.blacklist. Resolving as FIXED for now.

There is a _huge_ difference between req and prereq.

If one looks at the whole transaction (the complete install or the complete
upgrade), the difference becomes apparent:

Requires is a run-time dependency and says that _at the end of the transaction_
the required package has to be present.

Pre-Requires is an install-time dependency and says that _when the requiring
package is installed_ the required package has to be present.

This also affects the upgrade since the upgrade is also treated as one (big)
transaction so without the prereq the 10.2 version might still be installed but
there is no guarantee that its runable. The 10.2 util-linux probably depends on
a 10.2 glibc which is already upgraded to 10.3.

*** Bug 301088 has been marked as a duplicate of this bug. ***