iwl4965 detection problem

Hi,

I just got my hands on a new Toshiba Portege R500 laptop, which comes with the Intel 4965 chip in it. After installing the latest Fedora Core 8 test 3 on it, and updating the kernel I am still seeing a problem with detection of the 4965 in my laptop.

Fedora Core 8 test 3 is based on a 2.6.23.1 kernel.

Basically on the first load of the iwl4965 module no interface is detected, but if I rmmod and modprobe it again, it shows up and works just fine.

I haven't yet tried the latest kernel.org tree on this box, but looking through the git log, I don't see any commits that look like they were addressing this problem.

Is this a problem you have heard about before? Anything information I can provide to help?

I have attached the lspci -vv entry for this device, as well as the dmesg output.

Cheers,
Jes

02:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or
AGN Network Connection (rev 61)
Subsystem: Intel Corporation Unknown device 1101
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 2300
Region 0: Memory at ff8fe000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable+
Address: 00000000fee0300c Data: 41a9
Capabilities: [e0] Express Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <512ns, L1 unlimited
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0
Link: Latency L0s <128ns, L1 <64us
Link: ASPM L0s Enabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1

dmesg output:

First time it's loaded:

firewire_ohci: Added fw-ohci device 0000:03:0b.1, OHCI version 1.10
sdhci: SDHCI controller found at 0000:03:0b.3 [104c:803c] (rev 0)
PCI: Enabling device 0000:03:0b.3 (0000 -> 0002)
ACPI: PCI Interrupt 0000:03:0b.3[D] -> GSI 23 (level, low) -> IRQ 23
mmc0: SDHCI at 0x90005800 irq 23 DMA
iwl4965: Intel(R) Wireless WiFi Link 4965AGN driver for Linux, 1.1.17kds
iwl4965: Copyright(c) 2003-2007 Intel Corporation
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:02:00.0 to 64
iwl4965: Detected Intel Wireless WiFi Link 4965AGN tpm_inf_pnp 00:0a: Found TPM with ID IFX0102
tpm_inf_pnp 00:0a: TPM found: config base 0x4e, data base 0x680, chip version 0x000b, vendor id 0x15d1 (Infineon), product id 0x000b (SLB 9635 TT 1.2)
intel_rng: FWH not detected
.......
rmmod+modprobe'ing it again:

[drm] Initialized drm 1.1.0 20060810
[drm] Initialized i915 1.6.0 20060119 on minor 0
ACPI: PCI interrupt for device 0000:02:00.0 disabled
iwl4965: Intel(R) Wireless WiFi Link 4965AGN driver for Linux, 1.1.17kds
iwl4965: Copyright(c) 2003-2007 Intel Corporation
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:02:00.0 to 64
iwl4965: Detected Intel Wireless WiFi Link 4965AGN
iwl4965: Tunable channels: 13 802.11bg, 19 802.11a channels
phy1: Selected rate control algorithm 'iwl-4965-rs'

-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

You'll need to update more than just the kernel. There were issues with Test 3 for udev and network init scripts that didn't distinguish between the wmasterX and wlanX interfaces, and since both have the same MAC address things got confused.

Try updating to the latest Rawhide bits rather than using Test 3. The make sure you remove the following files:

rm -f /etc/sysconfig/network-scripts/ifcfg-wlan0*
rm -f /etc/udev/rules.d/70-persistent-net.rules

The initscripts don't care what's after the ifcfg- (because you could name it ifcfg-Home or ifcfg-Some-Other-Place, it doesn't have to be the device name) and therefore even a ifcfg-wlan0.bak will cause the problem too.

Quoted 8 lines · Dan Williams

You'll need to update more than just the kernel. There were issues with Test 3 for udev and network init scripts that didn't distinguish between the wmasterX and wlanX interfaces, and since both have the same MAC address things got confused.

Try updating to the latest Rawhide bits rather than using Test 3. The make sure you remove the following files:

Quoted 7 lines

rm -f /etc/sysconfig/network-scripts/ifcfg-wlan0*
rm -f /etc/udev/rules.d/70-persistent-net.rules

The initscripts don't care what's after the ifcfg- (because you could name it ifcfg-Home or ifcfg-Some-Other-Place, it doesn't have to be the device name) and therefore even a ifcfg-wlan0.bak will cause the problem too.

Hi Dan,

I think I have the latest updates, provided fedora/core/development is rawhide? I got udev-116-3.fc8 and initscripts-8.60-1.

That said, I am pretty sure this is a driver issue - even right after the install, when Fedora hadn't figured out the device and didn't try to load the module, it didn't find the device either unless I loaded it, unloaded it and loaded it again.

I've had this same problem with one machine and there were problems with those two files. I fixed it on that machine (and was fixed on a few others using this procedure) by removing those two files and rebooting.

The symptom is that the driver loads and recognizes the card, but no wireless devices show up to userspace (via iwconfig, ifconfig, or in /sys/class/net) because device renames by udev and/or init scripts stomped over them (like trying to rename wmaster0 -> eth1 and then renaming wlan0 -> eth1 but failing because it was already taken).

Try killing those two files, making sure you're up to date, then restarting.

Quoted 10 lines · Dan Williams

I've had this same problem with one machine and there were problems with those two files. I fixed it on that machine (and was fixed on a few others using this procedure) by removing those two files and rebooting.

The symptom is that the driver loads and recognizes the card, but no wireless devices show up to userspace (via iwconfig, ifconfig, or in /sys/class/net) because device renames by udev and/or init scripts stomped over them (like trying to rename wmaster0 -> eth1 and then renaming wlan0 -> eth1 but failing because it was already taken).

Quoted 2 lines

Try killing those two files, making sure you're up to date, then restarting.

I tried that, but no go :-( Even before the card was detected by Fedora, when I manually loaded the iwl4965 module, nothing showed up in ifconfig -a, I had to unload/reload for anything to happen.

I've been seeing this behaviour _sometimes_ as well. (/me hates _sometimes_)

Fresh off the presses, an F8-based build w/ the latest round of iwl4965 updates from Zhu Yi and friends:

	http://koji.fedoraproject.org/koji/taskinfo?taskID=215212

I haven't had a chance to test it yet myself (built it overnight), so YMMV. Still, there is a lot of iwl4965 churn in there so it is probably worth some testing. (Newer than wireless-2.6!)

At least it's consistent here as opposed to sometimes.

One thing I noted is that rmmod often takes a few seconds, no idea if it has any value?

Disable interrupts in the iwl4965 before calling request_irq() for the case that the previous OS or the BIOS left a pending interrupt in the chip. This behavior has been observed on some laptops such as T61 Thinkpads and Toshiba Portege R500

Quoted 4 lines · Jes Sorensen

Disable interrupts in the iwl4965 before calling request_irq() for the case that the previous OS or the BIOS left a pending interrupt in the chip. This behavior has been observed on some laptops such as T61 Thinkpads and Toshiba Portege R500

Any reason this would not be appropriate for iwl3945 as well?

I haven't had a chance to build the driver with this change, ie. it's untested, but I have a suspicion that this patch might do the job.

Quoted 2 lines · Jes Sorensen

I haven't had a chance to build the driver with this change, ie. it's untested, but I have a suspicion that this patch might do the job.

So, tested a kernel with this patch applied, and voila! My wireless now works on first boot!

Should I post it to linux-kernel or Andrew or will someone on this list collect it and push it upstream?

Quoted 4 lines · Jes Sorensen

Quoted 2 lines · Jes Sorensen

I haven't had a chance to build the driver with this change, ie. it's untested, but I have a suspicion that this patch might do the job.

Quoted 5 lines

So, tested a kernel with this patch applied, and voila! My wireless now works on first boot!

Should I post it to linux-kernel or Andrew or will someone on this list collect it and push it upstream?

posting it here is enough.
you should add 3945 repost it in a new thread.

Disable interrupts in the iwl4965 before calling request_irq() for the case that the previous OS or the BIOS left a pending interrupt in the chip. This behavior has been observed on some laptops such as T61 Thinkpads and Toshiba Portege R500

Signed-off-by Jes Sorensen <[email protected]>