Hi Momsen,

Would you mind giving us more detail information, like driver version, ucode,
mac80211 version, your HW and so on. 

BTW, I didn't find this issue on SONY-NAPA in my testing environment.
Additionally, would you mind testing the latest driver from
http://intellinuxwireless.org/. 

Thanks in advance!

--Songbo

 

On my lenovo R60, with iwl3945 wireless adapter, the wifi led isn't working.
The version of linux kernel is 2.6.21.3,
mac80211-8.0.0
iwlwifi-0.0.24

I would be happy to provide you with more info if needed.

Also see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240116

Well I tested almost every driver up to 0.0.25 and the versions in -mm
mac version up to 7.0.0, and the mainline version
ucode is the recent one. 2.14.3 I guess.

I'm using a acer travelmate 3022 

I can confirm the sam behaviour on my Acer TM3012, kill switch and LED.

I have just tried the git version iwl3945 on my dell 640m laptop with core2duo
centrino technology on ubuntu gutsy.
The driver seems to work, iwconfig lists the adapter, and I can set the wireless
parameters, but the led doesn't work at all.
I use the latest ucode from the website (
http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-ucode-2.14.1.tgz ).
The ipw3945 driver has led working, but I don't really like the idea of a
regulatory userspace daemon, and the wifi performance of the (ipw3945) driver is
rather bad, also, suspend and resume are difficult with the regulatory daemon
not letting the driver unload.
I haven't actually tested the driver yet, but it seems to me it should work.

The same behavior on HP Pavillion dv5000 (Centrino duo laptop), Arch linux
2.6.21.
Exactly as it is explained here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240116
with exactly the same results/logs/listings with one exception: I can't unload
the module.
modprobe -rv ipw3945 hungs (kill -9 xxx doesn't help). Module unloading is
enabled in the kernel, but force option is not.

(In reply to comment #7)
Looks like the problem is described and solved here:
http://bughost.org/bugzilla/show_bug.cgi?id=1096

Indeed, version 1.2.1 (1.2.1-2-1 on Arch) has this problem solved at least for
my machine. Thanks a lot!

This is _not_ ipw3945 but it _is_ iwl3945, the link you gave us is from the
ipw3945 project, which has the led working pretty well, but has a userspace
regulation daemon, which some of us guy would like to see go, which is why a new
driver development has been started by intel.
If I got your comment wrong, please tell, I was not at all trying to start a
flame on a bug, or something similar...
btw, the bug you linked to has to do with some register not being read, which
causes trouble when the module is loaded and the rf kill_switch is on, it
doesn't seem to have much in common with our bug, but correct me if I'm wrong.

the same problem with T60.

Same on x61s (Sidux Tartaros)
The ipw3945 driver works with the led.

Same problem on Dell Inspiron 6400 (core2duo) 

kernelversion: 2.6.22 (with new wlanstack)
iwlwifi-version: 0.0.36
iwl3945-ucode: 2.14.4

the leds does not work. i cannot test the kill switch because i don´t want to 
loose my internet connection now ;-)

leds and kill switch worked perfekt with ipw3945.

greetings,

psypointer

Actually the killswitch itself works partially (iwlwifi-0.0.42): If wlan0 is up
and associated and I press the killswitch button, connection goes down. Then
pressing the killswitch button will bring the interface up again (although I
couldn't successfully associate). 

If the driver is loaded while the killswitch is enabled, pressing the killswitch
will not change the driver's state, i.e. the interface will stay down...

LED still is not working at all...

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

Lenovo T60p

kernel: 2.6.22
iwlwifi: 1.0.0
iwl3945-ucode: 2.14.4

Kill switch appears to work.  LED does not.

LED on T61 does not work.

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

killswitch works.

killswitch does not appear to work for i4965 chips. Killswitch will kill, but
not bring the device back up to a usable state.

Same on a Fujitsu Siemens Computers Si1520 with ipw3945:

The LED is off permanently, the kill switch ( Fn+F2 ) works, but only for off.
To turn on again I have to switch on then run rcnetwork restart. Same for
wireless switch ( separate switch above keyboard, which turns off/on wlan and
bluetooth together )

openSUSE 10.3 alpha7, iwlwifi 1.0.0 (iwl3945.ko), kernel 2.6.22.1-10-default

This does work nicely with ipw3945.ko

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

Compal EL80, killswitch works, led does not. 3945 chipset. tried with 2.14.4 
and 1.0.0-1 and with 2.14.1.5 and 0.1.14. Neither work with led. Kernel 
2.6.22.5, kernel26pierlo, ArchLinux.

Cheers

HP-Compaq 6710s

iwl3945

1.1.20

ucode - 2.14.4
kernel 2.6.23

LED doesn't work

i wish this could be fixed in the not too distant future.
1.1.21 and kernel 2.6.23.8 on arch linux still don't have a working led :/

Created an attachment (id=1258) [details]
patch to make iwl leds work on 2.6.24-rc kernels

I use the attached patch to get working LEDs on 2.6.24-rc kernels. It was taken
from the ipw3945 devel list and adapted to the change Kconfig syntax, no other
changes

How can I use the 2.6.24-rc patch to patch my 2.6.20 kernel?

The attached patch does cut the LED Wireless indicator on for my Thinkpad T61.
But it does not flash to indicate activity. It only is solid green. It's great
to have an indication the wireless is on. But having it indicate activity would
make it even better.

Kill Switch works perfect now with iwlwifi included in 2.6.24-rc3. My Thinkpad
T61 with 4965AGN chip actually works without issue using the killswitch. I have
two patches not currently upstream in my kernel:
                  thinkpad-acpi 0.18
                  iwlwifi led patch <-- As submitted in this bug.

When the swith is in kill the wireless light cuts off and network manger shows
no signal. Once cut back on the wireless led cuts back on and network manager
reestablishes the connection. I have extensively tested it cutting it on and off
many times and it seems ok now...

Now if we can only get the LED going ...

Oh I also am using firmware iwlwifi-4965-ucode version 4.44.1.20 . The distro I
am using is ubuntu 7.10 (Gutsy).

Created an attachment (id=1263) [details]
updated patch for 2.6.24-rc4

I took the 2007-11-25 patch, changed to iwlwifi-1.2.0/origin ( since
iwlwifi-1.2.22 won't even compile and install for kernel 2.6. 20)

and ran  patch < iwl-led.patch and got the following output:

patching file Kconfig
Hunk #1 FAILED at 126.
1 out of 1 hunk FAILED -- saving rejects to file Kconfig.rej
patching file iwl-priv.h
Hunk #1 succeeded at 128 (offset 1 line).
patching file iwlwifi.h
Hunk #1 succeeded at 55 (offset 5 lines).
patching file iwl-leds.h
patching file iwl3945-base.c
Hunk #1 succeeded at 6101 (offset 20 lines).
Hunk #3 succeeded at 6364 (offset 20 lines).
Hunk #4 succeeded at 8418 (offset -13 lines).
Hunk #5 succeeded at 8464 (offset 20 lines).
Hunk #6 succeeded at 8758 (offset -11 lines).
patching file iwl4965-base.c
Hunk #1 succeeded at 6489 (offset 33 lines).
Hunk #3 succeeded at 6733 (offset 33 lines).
Hunk #4 succeeded at 9015 (offset -10 lines).
Hunk #5 succeeded at 9071 (offset 33 lines).
Hunk #6 succeeded at 9354 (offset -10 lines).


So looks like the patch actually applied alright for all of the files except
Kconfig.  The Kconfig.rej looks like this:

***************
*** 126,128 ****
          inserted in and remvoed from the running kernel whenever you want),
          say M here and read <file:Documentation/kbuild/modules.txt>.  The
          module will be called iwl3945.ko.
--- 126,134 ----
          inserted in and remvoed from the running kernel whenever you want),
          say M here and read <file:Documentation/kbuild/modules.txt>.  The
          module will be called iwl3945.ko.
+ config IWLWIFI_LEDS
+       bool    "IWLWIFI leds"
+       depends on IWLWIFI && MAC80211_LEDS
+       default y
+       ---help---
+         This options enables the wireless led.



Is there a way to I could fix Kconfig manually?

Created an attachment (id=1269) [details]
led-patched iwlwifi files

I tried to apply the led fix to iwlwifi-1.2.22. I did get it to apply (with
some manual intervention on Kconfig and iwlpriv (which does not exist anymore,
but is now part of iwl3945.h and iwl4965.h).
Unfortunatly I still don't see the led working!

You must enable LED support on in the Mac80211 options in the kernel.

There has been a lot of activity happening in this bug lately. Yi Zhu are you
going to integrate this patch or some other form of this patch anytime soon. It
would be EXTREMELY nice to finally have LED support working? Clearly it is now
one of th most wanted features by users.

Led support is enabled in the mac80211 module, so that is not the reason it does
not work.

Thank you very much for your effort in providing this feature.
It will be really very appreciated seing this feature implemented!

Could you also make a patch for current stable 2.6.23.10 Kernel? 
Since 2.6.24 development goes on at a high pace rc4 is already obsolete (rc5 is
out there now!)

I hope to see the led support in official drivers soon.

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

Applied the patch to 2.6.24-rc7, and led work. Any chance this patch will get
into .24? Or is it queued for .25?

There has been some work on the mailing list. This patch was based off of
another patch. IT is not the most optimal apparently. A more optimal patch has
been put on the list .. but it had a very long reaction time. If you would like
for LED to get worked on say something on the list. It is becoming a LONG LONG
overdue feature at this point.

Can someone upload here a patch that applies cleanly to 2.6.24-rc7? I have 
tried applying the patches here but it didn't really work.
I'd like to try and see if it works on my iwl4965 based laptop. 

With 2.6.22 and an older iwlwifi version it works (the rf_kill is locked on 
"off", or "0", so the wireless always works), but with later kernels the 
software switch is locked on "2" so I can't turn it back on "0".

Thank you for your help!

Confirming the bug here. Wireless LED does not work, killswitch does work on my
system, however.

My system:
Dell Vostro 1400
Intel 3945ABG
Intel Core 2 Duo
Ubuntu Gutsy (7.10)

I'm trying this driver in an attempt to resolve the issue where the ipw3945
driver would lock up and be unable to be modprobe -r'd, and the system would
lock up.

If any more info is needed, I can provided it (dmesg, lshw, etc). I agree that
this is long overdue--It can't be too hard to code in, either, right?

Confirming the bug here. Wireless LED does not work, killswitch does work on my
system, however.

My system:
Dell Vostro 1400
Intel 3945ABG
Intel Core 2 Duo
Ubuntu Gutsy (7.10)

I'm trying this driver in an attempt to resolve the issue where the ipw3945
driver would lock up and be unable to be modprobe -r'd, and the system would
lock up.

If any more info is needed, I can provided it (dmesg, lshw, etc). I agree that
this is long overdue--It can't be too hard to code in, either, right?

Confirming LED bug on Lenovo ThinkPad X61, i.e. not led blinking (works with
ipw3945 on default Ubuntu Gutsy kernel):

Core2 Duo 2.2Ghz T7500
Ubuntu Gutsy 7.10
Custom Kernel 2.6.24.14
iwl3945 - 1.2.23
iwl3945-ucode - 2.14.1.5
mac80211 - 10.0.4 - make installed, but not sure if it using kernel's stack

dmesg:
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux,
1.2.23ds
iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
wmaster0: Selected rate control algorithm 'iwl-3945-rs'

If anyone needs more info, let me know,

(In reply to comment #42)
> Confirming LED bug on Lenovo ThinkPad X61, i.e. not led blinking (works with
> ipw3945 on default Ubuntu Gutsy kernel):
> 
> Core2 Duo 2.2Ghz T7500
> Ubuntu Gutsy 7.10
> Custom Kernel 2.6.24.14
> iwl3945 - 1.2.23
> iwl3945-ucode - 2.14.1.5
> mac80211 - 10.0.4 - make installed, but not sure if it using kernel's stack
> 
> dmesg:
> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux,
> 1.2.23ds
> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> wmaster0: Selected rate control algorithm 'iwl-3945-rs'
> 
> If anyone needs more info, let me know,
> 

Sorry, kernel version is 2.6.23.14

I have installed 2.6.24-rc8 from the Debian trunk tree
(http://wiki.debian.org/DebianKernel) and while 
leds do not work, the kill switch is now set to "0". It is still not possible
to toggle it but at least now 
wireless works.

Thank you for this improvement!

(In reply to comment #30)
> Created an attachment (id=1263) [edit] [details]
> updated patch for 2.6.24-rc4
> 
FYI: Apply fine on vanilla 2.6.24 and it results in a working wifi led on my
Dell Inspiron 9400 with 3945 :-)

I just compiled 2.6.24 on my ThinkPad T60  1953-E7U  and the led isn't working
still.

(In reply to comment #46)
> I just compiled 2.6.24 on my ThinkPad T60  1953-E7U  and the led isn't working
> still.
Sorry for asking the obvious, but did you apply the patch and enabled it ?
In case of, on my system, the following is returned when "zcat /proc/config.gz |
grep LEDS":
CONFIG_MAC80211_LEDS=y
CONFIG_RFKILL_LEDS=y
CONFIG_IWLWIFI_LEDS=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
(With IWLWIFI_LEDS the option added by the patch)

I thought the patch would be included in the stable version.

There has been heavy disscussion about LED support on the mailing list. It is
still being worked out in the mac80211 list. This patch does work,but does not
satisfy everyone.

This is a SUPER well known issue. I know I've been waiting for a while. So
please give it time and if need be bring up concerns on the mailing list (so it
is known users really really really would like this issue fixed asap)

(In reply to comment #47)
> (In reply to comment #46)
> > I just compiled 2.6.24 on my ThinkPad T60  1953-E7U  and the led isn't working
> > still.
> Sorry for asking the obvious, but did you apply the patch and enabled it ?
> In case of, on my system, the following is returned when "zcat /proc/config.gz |
> grep LEDS":
> CONFIG_MAC80211_LEDS=y
> CONFIG_RFKILL_LEDS=y
> CONFIG_IWLWIFI_LEDS=y
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=m
> CONFIG_LEDS_TRIGGERS=y
> CONFIG_LEDS_TRIGGER_TIMER=m
> CONFIG_LEDS_TRIGGER_HEARTBEAT=m
> (With IWLWIFI_LEDS the option added by the patch)
> 

Ok, the led goes on when I associate with an AP, but it doesn't blink when it's
not connected or when it attempts to connect, or when the signal is low.  From
my understanding the code for the LED was borrowed from the ipw3945, so I'm not
sure why it doesn't work.

Here's what I got:

root@tpt60:~# zcat /proc/config.gz | grep LEDS
CONFIG_MAC80211_LEDS=y
CONFIG_IWLWIFI_LEDS=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_HEARTBEAT=m

I use patch mentioned above on 2.6.24 on Dell Latitude 430. Led works but after
suspend/resume is turned off. echo 255 > /sys/class/leds/iwl-phy0:asoc/brightnes
turn it on again.

This incident was opened 2007-02-14, ipw3945 still works rocksolid, this is one
more example of people loosing their minds on air bubbles. Ridiculous.

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

I applied the attached patch for rc4 kernels to my 2.6.24-gentoo sources
successfully, but the LED options just plain don't show up in menuconfig.  I've
verified the files are patched correctly a few times, even tried just pasting
the relevant LED vars from here into my .config but they just disappear when the
kernel builds.  What am I missing??

Thinkpad T61, 2.6.24-gentoo-r2
Using modules included in kernel source
mac80211, iwl4965 1.1.17kds
ieee80211 stack git-1.1.13

(In reply to comment #54)
You can find my current config with led enabled at
http://users.skynet.be/muaddib/config.gz (2.6.24-gentoo-r2)

(In reply to comment #52)
> This incident was opened 2007-02-14, ipw3945 still works rocksolid, this is one
> more example of people loosing their minds on air bubbles. Ridiculous.

Exactly! I've installed 2.6.24 yesterday on my Fedora 8, and - surprise
surprise - dkms-ipw3945-1.2.1 stopped working! So, I'm forced to use that
'super-duper' iwl3945 driver now. Not working LED light is one of many issues I
have with it, but after reading all these comments I reckon these issues would
stay like that for quite a while... :/

hi
I tested this patch on laptop compal fl90, kernel 2.6.24.3, wifi iwl4965
but color of diod for wifi (is blue) and bluetooth (is orange) is reverze

Orange, blue, I don't care -- can we please have something upstream now?  We
can sort-out the proper colors later...

An appropriate LED patch has just made it into the the kernel tree. 

http://git.kernel.org/?p=linux/kernel/git/rchatre/iwlwifi-2.6.git;a=commit;h=ec2ce7fc7890b37d564a274513d8d99ed4edb9ac

Is there any timeline for this to go into the Linus maintree ?

I merged iwlwifi branch with the maintree 2.6.25 and result is pretty good: now
the led is even blinking when there is some activity :-)

For courageous people, I made a patch against vanilla 2.6.25 to get a 2.6.25
source merged with iwlwifi branch (for the people who don't want to pull the
full Linus tree nor play with merge conflicts...) at
http://users.skynet.be/muaddib/patches/linux-2.6.25-iwl-merge.patch.bz2 (601k -
3.7 Megs unbz2...)  
[note: kernel name will be 2.6.25-wl - Btw, no guaranteed I didn't fsck up the
merge but seems stable on my machine...]

I'd very much welcome an inclusion of this fix in the mainline kernel, too.
iwl4965 on 2.6.24 works fine on my ThinkPad X61t with the exception of the wlan
LED. Since Fn+F5 will toggle between "wlan on/bluetooth off", "wlan
off/bluetooth on" and "wlan&bluetooth on" on this laptop, a working wlan LED is
more than just convenience.

Could I use this patch on the compat-wireless drivers? And if so, then how??

i'm sorry to start making a bit of noise, but i've been running for a week now
to track down this problem.
I'm running Ubuntu Hardy 8.04 64 bits:
$ uname -a
Linux BluBUG 2.6.24-17-generic #1 SMP Thu May 1 13:57:17 UTC 2008 x86_64
GNU/Linux
# lspci
04:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN
Network Connection (rev 61)

I suffer from not being able to turn off the soft button kill switch, so I cant
use my wifi.
 echoing "0 > /sys/class/net/wlan0/device/rf_kill" will make NetworkManager
detect the wifi, but ifconfig wont see it, or will the led turn on, and still
the fn+F2 wont work.

I've open a ticket at
https://answers.edge.launchpad.net/ubuntu/+question/32865, and I guess I can
make it into a bug ticket, so Ubuntu Devs patch this, but I'm willing to try
what ever you guys/galls need, if you tell me how.

Thanks in advance.

(In reply to comment #60)
> Is there any timeline for this to go into the Linus maintree ?

Just by looking at the change log, it appears to be in 2.6.26.

The led doesn't work any more starting from the kernel version 2.6.31. Is there
known workaround for this? How to investigate the problem?

Can you check if config_iwlwifi_leds is enabled?

Yes, CONFIG_IWLWIFI_LEDS is ‘y’. The led doesn’t work neither in Ubuntu nor in
vanilla kernel.

What kernel source you are using? Can you check if you have this patch
commit 616dcbdb0488e1cd7287d478a66fee78bb515bcd
Author: Maxim Levitsky <maximlevitsky@gmail.com>
Date:   Sat Oct 31 21:19:24 2009 +0200

    iwl3945: fix leds

     Commit a2502f115999405f1d3109ff8f7e8f2551efc26e,
     moved led processing into irq tasklet, but iwl3945 specific tasklet
     was forgotten

    Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>

The patch is three-day old, so haven’t a chance to have it. I’ll try it out in
tomorrow.

The above patch is going to be revertes as we discoverd it is causing a major
warn_on
Can you apply this patch instead
http://bugzilla.intellinuxwireless.org/attachment.cgi?id=2220 ?

Neither of patches worked out. Actually in the second case I already had
iwl3945_led_background(priv), and changing it with iwl_leds_background(priv)
didn’t have any visual effect.

Let me verify I understand the led correctly. When I used Ubuntu 9.04 with
kernel 2.6.28 and 29, every time I pushed the button RF kill, the led toggled
its state. But the situation is different in the Ubuntu 9.10 with the kernel
2.6.31. The led is lit initially, and the RF kill works normally, except of it
doesn’t influence on the led. Next time I wake the laptop up from hibernation,
the led is somehow off.

I’ll try to use the latest snapshot of the driver the next week.

iwl3945_led_background is gone from the source code. what repository of source
code you are using?

(In reply to comment #72)
> iwl3945_led_background is gone from the source code. what repository of source
> code you are using?

I use latest stable version of vanilla linux kernel: 2.6.31.5

I’m still too busy to checkout the latest snapshot of iwlwifi, but I’m still
looking forward for it.

(In reply to comment #72)
> iwl3945_led_background is gone from the source code. what repository of source
> code you are using?

Well, I was able to test out the latest source code. It doesn’t work either.
Noticed that there’s no option `grep CONFIG | grep LED` (don’t remember its
real name) in the code any more.

So I can do other needed experiments, provide additional required information
to fix the problem.

> Well, I was able to test out the latest source code. It doesn’t work either.
> Noticed that there’s no option `grep CONFIG | grep LED` (don’t remember its
> real name) in the code any more.
> 
Yes in recent code LEDS are self contained so need of symbol there.
Have you tried the latest iwlwifi code?
> So I can do other needed experiments, provide additional required information
> to fix the problem.

(In reply to comment #75)
> Have you tried the latest iwlwifi code?

Yes. I checked out the source code from the git repositary. But the led still
doesn't work.

Created an attachment (id=2222) [details]
Here is the patch to apply on top of iwlwifi

(In reply to comment #77)
> Created an attachment (id=2222) [details] [details]
> Here is the patch to apply on top of iwlwifi

Nothing changed. Right now I’m writing from within `uname -r` ==
"2.6.32-rc6-wl-2009.11.10", connected through wlan0. And no single blink comes
from the led. It just stays lit forever.

As another data point, the led blinks just fine here with Fedora's
2.6.31.5-127.fc12.x86_64.

(In reply to comment #79)
> As another data point, the led blinks just fine here with Fedora's
> 2.6.31.5-127.fc12.x86_64.

If so, is there something else required from the user space to let the led work
correctly (I don’t use Ubuntu kernel either)? May something special need to be
mounted somewhere?

(In reply to comment #79)
> As another data point, the led blinks just fine here with Fedora's
> 2.6.31.5-127.fc12.x86_64.

Again, I’ve checked both Ubuntu 8.10 (live image was ready), and F12 beta
(downloaded). Led does work in Ubuntu 8.10, but DOES NOT work in Fedora on my
laptop. Neither does it in Ubuntu 9.10.

I really would like to understand the significance of this issue. 

It's going strong since 2007-02-14, yet I doubt that it's of the least
significance for data transfer via wireless. Not even cosmetic.

Why not concentrate resources on issues worthwhile ?

(In reply to comment #82)
> I really would like to understand the significance of this issue. 
> 
> It's going strong since 2007-02-14, yet I doubt that it's of the least
> significance for data transfer via wireless. Not even cosmetic.
> 
> Why not concentrate resources on issues worthwhile ?

Agree. I thought this was an ordinary regression, but I’ve mistaken.

Recently a module parameter has been added called led_mode. Same module
parameter 
has not been added to 3945. I am going to send a patch soon to add it to 3945.

I am not able to reproduce the issue here. Can you send me the log with
modprobe iwl3945 debug=0x80000

Created an attachment (id=2225) [details]
modprobe iwl3945 debug=0x80000

Here’s the output of dmesg.

(In reply to comment #85)
> I am not able to reproduce the issue here. Can you send me the log with
> modprobe iwl3945 debug=0x80000

I’ve noticed that my /sys/class/led is very short:

asus::mail  mmc0::

Does this matter?

By the logs i can see the throughput and blink index never changes so leds
doesn't blink. Have you tried different mix of traffic? What kind of tests you
did?

(In reply to comment #88)
> By the logs i can see the throughput and blink index never changes so leds
> doesn't blink. Have you tried different mix of traffic? What kind of tests you
> did?

This was just turning on, DHCP discovery and again off. So packets did travel
through the interface. Which else traffic should I sniff?

Traffic does goes through. Can you try ping and browsing and see if led blinks?
Try to get the dmesg o/p again for this traffic if it doesn't blink.

Sorry for that noise. It appears to be a bug of acpi-support for asus.

Mark it as Verified.