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'
On Fri, Oct 26, 2007 at 05:23:50PM +0200, dragoran wrote:
> On 10/26/07, Jes Sorensen <[email protected]> wrote:
> > Jes Sorensen wrote:
> > > 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?
>
> posting it here is enough.
> you should add 3945 repost it in a new thread.
I've got the patch, duped for 3945 as well.
Thanks,
John
--
John W. Linville
[email protected]
On Thu, 2007-10-25 at 15:37 +0200, Jes Sorensen wrote:
> 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.
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.
Dan
> 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
On 10/26/07, Jes Sorensen <[email protected]> wrote:
> Jes Sorensen wrote:
> > 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?
posting it here is enough.
you should add 3945 repost it in a new thread.
On Fri, 2007-10-26 at 16:10 +0200, Jes Sorensen wrote:
> 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]>
ACK.
Good catch. And it explains why it doesn't work _sometimes_ (although I
never have the problem on my box).
Thanks,
-yi
Dan Williams wrote:
> 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.
Hi Dan,
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.
Cheers,
Jes
On Fri, Oct 26, 2007 at 10:05:58AM +0200, Jes Sorensen wrote:
> Dan Williams wrote:
> >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.
> 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!)
For any non-iwl4965 F8 users it may still be worthwhiles to give
those kernels a spin -- the stuff in the current F8 kernels is a
little old now.(*)
Let me know...
John
(*) I had to stop shoving stuff into F8 a couple of weeks back after
a big wireless update broke a bunch of people's wireless while F8
was trying to freeze... :-(
--
John W. Linville
[email protected]
On Thu, 2007-10-25 at 16:15 +0200, Jes Sorensen wrote:
> Dan Williams wrote:
> > 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.
>
> 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.
Dan
Jes Sorensen wrote:
> 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?
Cheers,
Jes
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]>
--- linux/drivers/net/wireless/iwlwifi/iwl4965-base.c~ 2007-10-26 06:49:02.000000000 +0200
+++ linux/drivers/net/wireless/iwlwifi/iwl4965-base.c 2007-10-26 16:03:40.387241088 +0200
@@ -9090,6 +9090,8 @@
priv->power_mode = IWL_POWER_AC;
priv->user_txpower_limit = IWL_DEFAULT_TX_POWER;
+ iwl_disable_interrupts(priv);
+
pci_enable_msi(pdev);
err = request_irq(pdev->irq, iwl_isr, IRQF_SHARED, DRV_NAME, priv);
On Fri, Oct 26, 2007 at 04:10:39PM +0200, Jes Sorensen wrote:
> 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?
John
--
John W. Linville
[email protected]
John W. Linville wrote:
> 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!)
Hi John,
Thanks for the suggestion, just tried it out - seems to behave the
same way as the old kernel :-(
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?
Cheers,
Jes
Dan Williams wrote:
> 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.
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.
Cheers,
Jes
John W. Linville wrote:
> On Fri, Oct 26, 2007 at 04:10:39PM +0200, Jes Sorensen wrote:
>
>> 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 cannot say for sure since I don't have one here, but a brief look at
the code indicates that it might.
I'm trying to build a kernel here with the patch now.
Cheers,
Jes