you do not mention in your report but the output of the logs prompt me to ask
... what is the status of your RFKILL switch on your laptop? Please verify that
it it is not engaged.

I don't know, how can I check it. 
Mayby like it:
laptok ~ # find /sys -name "rf_kill"
/sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/rf_kill
laptok ~ # cat /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/rf_kill
1
laptok ~ # echo "0"> /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/rf_kill
laptok ~ # cat /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/rf_kill
0
laptok ~ # /etc/init.d/net.wlan0 restart
 * Starting wlan0
SIOCSIFFLAGS: Connection timed out
SIOCSIFFLAGS: Connection timed out
SIOCSIFFLAGS: Connection timed out
 *   Configuring wireless network for wlan0
 *   Failed to configure wireless for wlan0                                    
                                                                            [
!! ]
laptok ~ # dmesg | tail
iwl4965: Wait for START_ALIVE timeout after 2000ms.
ACPI: PCI interrupt for device 0000:04:00.0 disabled
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PM: Writing back config space on device 0000:04:00.0 at offset 1 (was 100102,
writing 100106)
iwl4965: Wait for START_ALIVE timeout after 2000ms.
ACPI: PCI interrupt for device 0000:04:00.0 disabled
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PM: Writing back config space on device 0000:04:00.0 at offset 1 (was 100102,
writing 100106)
iwl4965: Wait for START_ALIVE timeout after 2000ms.
ACPI: PCI interrupt for device 0000:04:00.0 disabled
laptok ~ #

kernel gentoo-sources-2.6.25-r2 not works too

laptok ~ # dmesg | grep -E "(iwl)|(4965)"
iwl4965: Intel(R) Wireless WiFi Link 4965AGN driver for Linux, 1.2.23kds
iwl4965: Copyright(c) 2003-2007 Intel Corporation
iwl4965: Detected Intel Wireless WiFi Link 4965AGN
iwl4965: Tunable channels: 13 802.11bg, 19 802.11a channels
phy0: Selected rate control algorithm 'iwl-4965-rs'
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl4965: WARNING: Requesting MAC access during RFKILL wakes up NIC

I have a Debian Sid/Lenny with a custom kernel on an Acer Aspire 5920 with
Intel 3945 wireless card.
I have compiled a 2.6.25.4 and 2.6.26-rc3-git5 kernels using the same config of
a working 2.6.24.7 custom linux kernel, but in this new kernels the wireless
button doesn't work anymore. In 2.6.24.7 the led on the button is not working,
but when I press it I can change the state of the wireless card from 0 to 2 and
vice versa all the times I want:
cat /sys/module/iwl3945/drivers/pci\:iwl3945/0000\:06\:00.0/rf_kill 2
cat /sys/module/iwl3945/drivers/pci\:iwl3945/0000\:06\:00.0/rf_kill 0 ...
In 2.6.25.4 kernel the switch doesn't work anymore. I'm not sure if this
behavior can be related to unmapped buttons in ACPI module (just guessing, I'm
not a computer scientist).
In kernel 2.6.26 I can see led working and the button work too, but just for a
couple of times. If I press the button more then trice, it stops working both
from the led and the rf_kill switch.
However I thank you for your great work.

Valerio  

I have the same problem on a thinkpad T61 with Gentoo. 

It seems that Kernels 2.6.25 and 2.6.26 are affected.

Furthermore, the command 
 modprobe -r iwl4965 && modprobe iwl4965 && ifconfig wlan0 up && iwlist scan

worked for me at the first seconds. In fact, the output showed a list of access
points.

But after this, every 

ifconfig wlan0 

command gave SIOCSIFFLAGS not found


It seems, if the card would be scanning for available access points, and if
none is found where it can connect, the card falls asleep and does not wake up. 

In my case, proposed solutions like iwconfig wlan0 txpower on or something else
did not help.

The card falls asleep and I cannot connect to any access points. 

I've been dealing with this problem myself. I've had success running the intel
compat-wireless package (as of this morning). This package builds the latest
iwl3945/iwl4965 modules without removing those you built with the kernel. This
is suggested by the intel wireless project at the moment.

Hope that helps some people out.

Mark this bug as Fixed based on last comment. Please reopen it if you still see
this issue with latest package.

I have used the compact-wireless drivers since last Monday and tested it.
Everything is working very well now :). Thank for your great work

Thanks.

And mark it Verified.

It seems, that some users on gentoo still have this problem:

http://bugs.gentoo.org/show_bug.cgi?id=218565

I tried now a 26.25.2 Kernel. The problem persists. It still persists with
compat-wireless drivers. Moreover, I get the following output:

http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1724

sorry, I mean I tried a 2.6.26.2 Kernel....

This is a hardware rfkill related problem. You need to disable it (radio
enable) before bring up the wlan0 interface. If you are using T61, make sure
the h/w rf_kill switch on right front side of the laptop is switched off.

Benjamin, Did Zhu yi's suggestion solve the problem.

I'm now using a 2.6.24 Kernel where everything works. 

Unfortunately, after trying to install compat wireless on a 2.5.25 or 2.6.26
kernel, I got  this error here:

http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1724


If I now want to test compat wireless on my (good working) 2.6.24 Kernel, I
can't even install during to this output_

http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1724#c4

Unfortunately, it seems that other users of the gentoo distribution have the
same error.

When I can't install compat-wireless because it breaks during installation, I
can't even test if something works or not. Sorry!

OK, I now got back to a 2.6.25 Kernel to test if a compat wireless driver would
work now.

On 2.6.25, compat wireless could be installed.

But this is what I got from your driver:

iwl4965: Unknown parameter `hwcrypto'

On my system this error seems not to depend on kernel options.

(In reply to comment #16)
> iwl4965: Unknown parameter `hwcrypto'

Which compat-wireless version are you using? We change it to "swcrypto" in the
latest driver.

I used the compat wireless version I downloaded at 2008-09-05 from

http://linuxwireless.org/en/users/Download#Wheretodownload

for kernels <=2.6.26

It gave me this error. If this is not the link where one can download an actual
version of compat-wireless for 2.6.25 Kernels, it would be nice, if you tell
me, where I should download the correct version.

(In reply to comment #18)
> It gave me this error. If this is not the link where one can download an actual
> version of compat-wireless for 2.6.25 Kernels, it would be nice, if you tell
> me, where I should download the correct version.

I'm not saying this is not the correct version. It just changes the hwcrypto
module param into swcrypto. You might want to change it in your modules.conf.

thank you. Now I can at least modprobe the device and scan for available hosts.
I will test today, if the connection also works.

Thanks.