Hi,
Seeing that iwl3945 is now merged, I decided to switch my x60 to use
that instead of ipw3945. That would leave me with zero kernel
dependencies.
Unfortunately it doesn't work. Loading the module reveals the device:
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for
Linux, 1.1.17ks
iwl3945: Copyright(c) 2003-2007 Intel Corporation
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:03:00.0 to 64
iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
phy0: Selected rate control algorithm 'iwl-3945-rs'
# iwconfig wlan0
wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
Mode:Managed Channel:0 Access Point: Not-Associated
Tx-Power=0 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Encryption key:XXXX-XXXX-XX
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
and iwconfig sees it, essid/enc settings are fine, but I don't get a
link.
--
Jens Axboe
Wednesday 17 October 2007 Tarihinde 17:11:11 yazm=C4=B1=C5=9Ft=C4=B1:
> Huh indeed, now it links fine! Thanks for the hint. Would be nice to
> have fixed, though :-)
Yeah indeed I sent a mail about this a couple of days ago, waiting for =
Intel=20
guys to respond :-)
Regards,
ismail
--=20
=46aith is believing what you know isn't so -- Mark Twain
On Thu, Oct 18 2007, Stephen Clark wrote:
> Jens Axboe wrote:
>
>> On Wed, Oct 17 2007, Stephen Clark wrote:
>> =20
>>> Jens Axboe wrote:
>>>
>>> =20
>>>> On Wed, Oct 17 2007, Dan Williams wrote:
>>>> =20
>>>>> On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
>>>>> =20
>>>>>> On Wed, Oct 17 2007, Dan Williams wrote:
>>>>>> =20
>>>>>>> On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
>>>>>>> =20
>>>>>>>> On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
>>>>>>>> =20
>>>>>>>>> Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
>>>>>>>>> =20
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Seeing that iwl3945 is now merged, I decided to switch my x6=
0 to=20
>>>>>>>>>> use
>>>>>>>>>> that instead of ipw3945. That would leave me with zero kerne=
l
>>>>>>>>>> dependencies.
>>>>>>>>>>
>>>>>>>>>> Unfortunately it doesn't work. Loading the module reveals th=
e=20
>>>>>>>>>> device:
>>>>>>>>>>
>>>>>>>>>> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection=
=20
>>>>>>>>>> driver for
>>>>>>>>>> Linux, 1.1.17ks
>>>>>>>>>> iwl3945: Copyright(c) 2003-2007 Intel Corporation
>>>>>>>>>> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -=
> IRQ=20
>>>>>>>>>> 21
>>>>>>>>>> PCI: Setting latency timer of device 0000:03:00.0 to 64
>>>>>>>>>> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connect=
ion
>>>>>>>>>> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
>>>>>>>>>> phy0: Selected rate control algorithm 'iwl-3945-rs'
>>>>>>>>>>
>>>>>>>>>> # iwconfig wlan0
>>>>>>>>>> wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
>>>>>>>>>> Mode:Managed Channel:0 Access Point: Not-Associate=
d
>>>>>>>>>> Tx-Power=3D0 dBm
>>>>>>>>>> Retry min limit:7 RTS thr:off Fragment thr=3D234=
6 B
>>>>>>>>>> Encryption key:XXXX-XXXX-XX
>>>>>>>>>> Link Quality:0 Signal level:0 Noise level:0
>>>>>>>>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid fr=
ag:0
>>>>>>>>>> Tx excessive retries:0 Invalid misc:0 Missed beac=
on:0
>>>>>>>>>>
>>>>>>>>>> and iwconfig sees it, essid/enc settings are fine, but I don=
't get=20
>>>>>>>>>> a
>>>>>>>>>> link.
>>>>>>>>>> =20
>>>>>>>>> Same issue here, try iwlist wlan0 scan first and then it shou=
ld=20
>>>>>>>>> work.
>>>>>>>>> =20
>>>>>>>> Huh indeed, now it links fine! Thanks for the hint. Would be n=
ice to
>>>>>>>> have fixed, though :-)
>>>>>>>> =20
>>>>>>> Odd, doesn't the driver need to do a scan _anyway_ to find the =
right
>>>>>>> BSSID to associate with if the cached scan results are more tha=
n a=20
>>>>>>> few
>>>>>>> seconds old? Can you run '/sbin/iwevent' before trying a fresh
>>>>>>> association, try to associate, ensure that it has failed, and r=
eport=20
>>>>>>> the
>>>>>>> output?
>>>>>>>
>>>>>>> If you don't get something like:
>>>>>>>
>>>>>>> 10:17:05.117937 eth1 Scan request completed
>>>>>>>
>>>>>>> shown there, then there's likely a bug in the driver because it=
's=20
>>>>>>> either
>>>>>>> (a) not scanning before trying to associate, or (b) not sending=
out=20
>>>>>>> scan
>>>>>>> completion events after it's done a scan.
>>>>>>> =20
>>>>>> Indeed, there is now Scan request completed before I run the iwl=
ist
>>>>>> scan. iwevent output:
>>>>>> =20
>>>>> Hmm, the output below doesn't show the scan request completed, ri=
ght?
>>>>>
>>>>> =20
>>>>>> Waiting for Wireless Events from interfaces...
>>>>>> 16:20:27.453588 wlan0 Set Mode:Managed
>>>>>> 16:20:27.462104 wlan0 Set Encryption key:off
>>>>>> 16:20:27.463940 wlan0 Set Encryption key:****-****-** Sec=
urity=20
>>>>>> mode:open
>>>>>> 16:20:27.466535 wlan0 Set ESSID:"kjellbergaxboe"
>>>>>>
>>>>>> waiting, nothing else happens. Then run iwlist scan from another
>>>>>> terminal.
>>>>>>
>>>>>> 16:20:53.892549 wlan0 Scan request completed
>>>>>> =20
>>>>> So you only get this when you manually scan right after setting t=
he=20
>>>>> ssid
>>>>> and key?
>>>>> =20
>>>> If you look at the time stamp, I ran the iwlist scan about 26 seco=
nds
>>>> after loading the module. When the module is loaded, the networkin=
g
>>>> script sets the essid and encryption key.
>>>>
>>>> So yes, I only get that 'Scan request completed' line after runnin=
g
>>>> iwlist scan manually.
>>>>
>>>> =20
>>> Don't know whether this is related, but I was having all kinds of t=
rouble=20
>>> getting associated,
>>> iwlist eth1 scan would report no scan results, I then switched to l=
oading=20
>>> the kernel module with
>>> the option that tells iwl3945 to do software scanning and it works=
=20
>>> everytime now.
>>> =20
>>
>> Which option is that?
>>
>> =20
> In my modprobe.conf file:
> options iwl3945 disable_hw_scan=3D1
That option is already set here:
carl:/etc/modprobe.d # grep . iwlwifi=20
options iwl3945 disable_hw_scan=3D1
options iwl4965 disable_hw_scan=3D1
--=20
Jens Axboe
On Wed, Oct 17 2007, Stephen Clark wrote:
> Jens Axboe wrote:
>
>> On Wed, Oct 17 2007, Dan Williams wrote:
>> =20
>>> On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
>>> =20
>>>> On Wed, Oct 17 2007, Dan Williams wrote:
>>>> =20
>>>>> On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
>>>>> =20
>>>>>> On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
>>>>>> =20
>>>>>>> Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
>>>>>>> =20
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Seeing that iwl3945 is now merged, I decided to switch my x60 =
to use
>>>>>>>> that instead of ipw3945. That would leave me with zero kernel
>>>>>>>> dependencies.
>>>>>>>>
>>>>>>>> Unfortunately it doesn't work. Loading the module reveals the=20
>>>>>>>> device:
>>>>>>>>
>>>>>>>> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection d=
river=20
>>>>>>>> for
>>>>>>>> Linux, 1.1.17ks
>>>>>>>> iwl3945: Copyright(c) 2003-2007 Intel Corporation
>>>>>>>> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> =
IRQ 21
>>>>>>>> PCI: Setting latency timer of device 0000:03:00.0 to 64
>>>>>>>> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connectio=
n
>>>>>>>> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
>>>>>>>> phy0: Selected rate control algorithm 'iwl-3945-rs'
>>>>>>>>
>>>>>>>> # iwconfig wlan0
>>>>>>>> wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
>>>>>>>> Mode:Managed Channel:0 Access Point: Not-Associated
>>>>>>>> Tx-Power=3D0 dBm
>>>>>>>> Retry min limit:7 RTS thr:off Fragment thr=3D2346=
B
>>>>>>>> Encryption key:XXXX-XXXX-XX
>>>>>>>> Link Quality:0 Signal level:0 Noise level:0
>>>>>>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid fra=
g:0
>>>>>>>> Tx excessive retries:0 Invalid misc:0 Missed beaco=
n:0
>>>>>>>>
>>>>>>>> and iwconfig sees it, essid/enc settings are fine, but I don't=
get a
>>>>>>>> link.
>>>>>>>> =20
>>>>>>> Same issue here, try iwlist wlan0 scan first and then it should=
work.
>>>>>>> =20
>>>>>> Huh indeed, now it links fine! Thanks for the hint. Would be nic=
e to
>>>>>> have fixed, though :-)
>>>>>> =20
>>>>> Odd, doesn't the driver need to do a scan _anyway_ to find the ri=
ght
>>>>> BSSID to associate with if the cached scan results are more than =
a few
>>>>> seconds old? Can you run '/sbin/iwevent' before trying a fresh
>>>>> association, try to associate, ensure that it has failed, and rep=
ort=20
>>>>> the
>>>>> output?
>>>>>
>>>>> If you don't get something like:
>>>>>
>>>>> 10:17:05.117937 eth1 Scan request completed
>>>>>
>>>>> shown there, then there's likely a bug in the driver because it's=
=20
>>>>> either
>>>>> (a) not scanning before trying to associate, or (b) not sending o=
ut=20
>>>>> scan
>>>>> completion events after it's done a scan.
>>>>> =20
>>>> Indeed, there is now Scan request completed before I run the iwlis=
t
>>>> scan. iwevent output:
>>>> =20
>>> Hmm, the output below doesn't show the scan request completed, righ=
t?
>>>
>>> =20
>>>> Waiting for Wireless Events from interfaces...
>>>> 16:20:27.453588 wlan0 Set Mode:Managed
>>>> 16:20:27.462104 wlan0 Set Encryption key:off
>>>> 16:20:27.463940 wlan0 Set Encryption key:****-****-** Secur=
ity=20
>>>> mode:open
>>>> 16:20:27.466535 wlan0 Set ESSID:"kjellbergaxboe"
>>>>
>>>> waiting, nothing else happens. Then run iwlist scan from another
>>>> terminal.
>>>>
>>>> 16:20:53.892549 wlan0 Scan request completed
>>>> =20
>>> So you only get this when you manually scan right after setting the=
ssid
>>> and key?
>>> =20
>>
>> If you look at the time stamp, I ran the iwlist scan about 26 second=
s
>> after loading the module. When the module is loaded, the networking
>> script sets the essid and encryption key.
>>
>> So yes, I only get that 'Scan request completed' line after running
>> iwlist scan manually.
>>
>> =20
> Don't know whether this is related, but I was having all kinds of tro=
uble=20
> getting associated,
> iwlist eth1 scan would report no scan results, I then switched to loa=
ding=20
> the kernel module with
> the option that tells iwl3945 to do software scanning and it works=20
> everytime now.
Which option is that?
--=20
Jens Axboe
On Wed, Oct 17 2007, Dan Williams wrote:
> On Wed, 2007-10-17 at 15:54 +0200, Jens Axboe wrote:
> > Hi,
> >
> > Seeing that iwl3945 is now merged, I decided to switch my x60 to use
> > that instead of ipw3945. That would leave me with zero kernel
> > dependencies.
> >
> > Unfortunately it doesn't work. Loading the module reveals the device:
> >
> > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for
> > Linux, 1.1.17ks
> > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
> > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > phy0: Selected rate control algorithm 'iwl-3945-rs'
> >
> > # iwconfig wlan0
> > wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
> > Mode:Managed Channel:0 Access Point: Not-Associated
> > Tx-Power=0 dBm
> > Retry min limit:7 RTS thr:off Fragment thr=2346 B
> > Encryption key:XXXX-XXXX-XX
> > Link Quality:0 Signal level:0 Noise level:0
> > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> > Tx excessive retries:0 Invalid misc:0 Missed beacon:0
> >
> > and iwconfig sees it, essid/enc settings are fine, but I don't get a
> > link.
>
> You do have the updated firmware, right? I don't think iwl3945 would
> even load if you didn't, but it doesn't hurt to check.
I'm using the suse firmware package, it claims to be version 2.14.1.5.
> Also, what exact kernel version are you using? 2.6.23 release kernel?
> Or something from development series?
It's -git as of last night, so current 2.6.23-git.
As per the last hint, using iwlist scan wlan0 makes it work. I'd prefer
it it worked out of the box, though :-)
--
Jens Axboe
On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
> Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
> > Hi,
> >
> > Seeing that iwl3945 is now merged, I decided to switch my x60 to us=
e
> > that instead of ipw3945. That would leave me with zero kernel
> > dependencies.
> >
> > Unfortunately it doesn't work. Loading the module reveals the devic=
e:
> >
> > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver=
for
> > Linux, 1.1.17ks
> > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 2=
1
> > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > phy0: Selected rate control algorithm 'iwl-3945-rs'
> >
> > # iwconfig wlan0
> > wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
> > Mode:Managed Channel:0 Access Point: Not-Associated
> > Tx-Power=3D0 dBm
> > Retry min limit:7 RTS thr:off Fragment thr=3D2346 B
> > Encryption key:XXXX-XXXX-XX
> > Link Quality:0 Signal level:0 Noise level:0
> > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> > Tx excessive retries:0 Invalid misc:0 Missed beacon:0
> >
> > and iwconfig sees it, essid/enc settings are fine, but I don't get =
a
> > link.
>=20
> Same issue here, try iwlist wlan0 scan first and then it should work.
Huh indeed, now it links fine! Thanks for the hint. Would be nice to
have fixed, though :-)
--=20
Jens Axboe
On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
> On Wed, Oct 17 2007, Dan Williams wrote:
> > On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
> > > On Wed, Oct 17 2007, Ismail D=C3=B6nmez wrote:
> > > > Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
> > > > > Hi,
> > > > >
> > > > > Seeing that iwl3945 is now merged, I decided to switch my x60=
to use
> > > > > that instead of ipw3945. That would leave me with zero kernel
> > > > > dependencies.
> > > > >
> > > > > Unfortunately it doesn't work. Loading the module reveals the=
device:
> > > > >
> > > > > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection =
driver for
> > > > > Linux, 1.1.17ks
> > > > > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > > > > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) ->=
IRQ 21
> > > > > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > > > > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connecti=
on
> > > > > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > > > > phy0: Selected rate control algorithm 'iwl-3945-rs'
> > > > >
> > > > > # iwconfig wlan0
> > > > > wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
> > > > > Mode:Managed Channel:0 Access Point: Not-Associat=
ed
> > > > > Tx-Power=3D0 dBm
> > > > > Retry min limit:7 RTS thr:off Fragment thr=3D23=
46 B
> > > > > Encryption key:XXXX-XXXX-XX
> > > > > Link Quality:0 Signal level:0 Noise level:0
> > > > > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid f=
rag:0
> > > > > Tx excessive retries:0 Invalid misc:0 Missed bea=
con:0
> > > > >
> > > > > and iwconfig sees it, essid/enc settings are fine, but I don'=
t get a
> > > > > link.
> > > >=20
> > > > Same issue here, try iwlist wlan0 scan first and then it should=
work.
> > >=20
> > > Huh indeed, now it links fine! Thanks for the hint. Would be nice=
to
> > > have fixed, though :-)
> >=20
> > Odd, doesn't the driver need to do a scan _anyway_ to find the righ=
t
> > BSSID to associate with if the cached scan results are more than a =
few
> > seconds old? Can you run '/sbin/iwevent' before trying a fresh
> > association, try to associate, ensure that it has failed, and repor=
t the
> > output?
> >=20
> > If you don't get something like:
> >=20
> > 10:17:05.117937 eth1 Scan request completed
> >=20
> > shown there, then there's likely a bug in the driver because it's e=
ither
> > (a) not scanning before trying to associate, or (b) not sending out=
scan
> > completion events after it's done a scan.
>=20
> Indeed, there is now Scan request completed before I run the iwlist
> scan. iwevent output:
Hmm, the output below doesn't show the scan request completed, right?
> Waiting for Wireless Events from interfaces...
> 16:20:27.453588 wlan0 Set Mode:Managed
> 16:20:27.462104 wlan0 Set Encryption key:off
> 16:20:27.463940 wlan0 Set Encryption key:****-****-** Security=
mode:open
> 16:20:27.466535 wlan0 Set ESSID:"kjellbergaxboe"
>=20
> waiting, nothing else happens. Then run iwlist scan from another
> terminal.
>=20
> 16:20:53.892549 wlan0 Scan request completed
So you only get this when you manually scan right after setting the ssi=
d
and key?
Dan
> 16:20:54.025085 wlan0 Custom driver
> event:ASSOCINFO(ReqIEs=3D000e6b6a656c6c626572676178626f65010402040b16
> RespIEs=3D010482848b96dd0c00037f0201015b0002a44000)
> 16:20:54.025123 wlan0 New Access Point/Cell address:00:13:46:97:=
33:E2
>=20
> bingo, it associates and it now works.
>=20
On Wed, Oct 17 2007, Dan Williams wrote:
> On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
> > On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
> > > Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
> > > > Hi,
> > > >
> > > > Seeing that iwl3945 is now merged, I decided to switch my x60 t=
o use
> > > > that instead of ipw3945. That would leave me with zero kernel
> > > > dependencies.
> > > >
> > > > Unfortunately it doesn't work. Loading the module reveals the d=
evice:
> > > >
> > > > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection dr=
iver for
> > > > Linux, 1.1.17ks
> > > > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > > > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> I=
RQ 21
> > > > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > > > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> > > > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > > > phy0: Selected rate control algorithm 'iwl-3945-rs'
> > > >
> > > > # iwconfig wlan0
> > > > wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
> > > > Mode:Managed Channel:0 Access Point: Not-Associated
> > > > Tx-Power=3D0 dBm
> > > > Retry min limit:7 RTS thr:off Fragment thr=3D2346=
B
> > > > Encryption key:XXXX-XXXX-XX
> > > > Link Quality:0 Signal level:0 Noise level:0
> > > > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid fra=
g:0
> > > > Tx excessive retries:0 Invalid misc:0 Missed beaco=
n:0
> > > >
> > > > and iwconfig sees it, essid/enc settings are fine, but I don't =
get a
> > > > link.
> > >=20
> > > Same issue here, try iwlist wlan0 scan first and then it should w=
ork.
> >=20
> > Huh indeed, now it links fine! Thanks for the hint. Would be nice t=
o
> > have fixed, though :-)
>=20
> Odd, doesn't the driver need to do a scan _anyway_ to find the right
> BSSID to associate with if the cached scan results are more than a fe=
w
> seconds old? Can you run '/sbin/iwevent' before trying a fresh
> association, try to associate, ensure that it has failed, and report =
the
> output?
>=20
> If you don't get something like:
>=20
> 10:17:05.117937 eth1 Scan request completed
>=20
> shown there, then there's likely a bug in the driver because it's eit=
her
> (a) not scanning before trying to associate, or (b) not sending out s=
can
> completion events after it's done a scan.
Indeed, there is now Scan request completed before I run the iwlist
scan. iwevent output:
Waiting for Wireless Events from interfaces...
16:20:27.453588 wlan0 Set Mode:Managed
16:20:27.462104 wlan0 Set Encryption key:off
16:20:27.463940 wlan0 Set Encryption key:****-****-** Security m=
ode:open
16:20:27.466535 wlan0 Set ESSID:"kjellbergaxboe"
waiting, nothing else happens. Then run iwlist scan from another
terminal.
16:20:53.892549 wlan0 Scan request completed
16:20:54.025085 wlan0 Custom driver
event:ASSOCINFO(ReqIEs=3D000e6b6a656c6c626572676178626f65010402040b16
RespIEs=3D010482848b96dd0c00037f0201015b0002a44000)
16:20:54.025123 wlan0 New Access Point/Cell address:00:13:46:97:33=
:E2
bingo, it associates and it now works.
--=20
Jens Axboe
On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
> Wednesday 17 October 2007 Tarihinde 17:11:11 yazm????t??:
> > Huh indeed, now it links fine! Thanks for the hint. Would be nice t=
o
> > have fixed, though :-)
>=20
> Yeah indeed I sent a mail about this a couple of days ago, waiting fo=
r
> Intel guys to respond :-)
At least this makes my notebook usable until they get it fixed, so
thanks a lot for the hint!
--=20
Jens Axboe
On Wed, Oct 17 2007, Jens Axboe wrote:
> Hi,
>
> Seeing that iwl3945 is now merged, I decided to switch my x60 to use
> that instead of ipw3945. That would leave me with zero kernel
> dependencies.
>
> Unfortunately it doesn't work. Loading the module reveals the device:
>
> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for
> Linux, 1.1.17ks
> iwl3945: Copyright(c) 2003-2007 Intel Corporation
> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
> PCI: Setting latency timer of device 0000:03:00.0 to 64
> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> phy0: Selected rate control algorithm 'iwl-3945-rs'
>
> # iwconfig wlan0
> wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
> Mode:Managed Channel:0 Access Point: Not-Associated
> Tx-Power=0 dBm
> Retry min limit:7 RTS thr:off Fragment thr=2346 B
> Encryption key:XXXX-XXXX-XX
> Link Quality:0 Signal level:0 Noise level:0
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> and iwconfig sees it, essid/enc settings are fine, but I don't get a
> link.
I should mention that ipw3945 has always worked fine for me. And please
don't drop me from the CC list, I'm not subscribed to either of the
lists.
--
Jens Axboe
Wednesday 17 October 2007 Tarihinde 16:54:53 yazm=C4=B1=C5=9Ft=C4=B1:
> Hi,
>
> Seeing that iwl3945 is now merged, I decided to switch my x60 to use
> that instead of ipw3945. That would leave me with zero kernel
> dependencies.
>
> Unfortunately it doesn't work. Loading the module reveals the device:
>
> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver f=
or
> Linux, 1.1.17ks
> iwl3945: Copyright(c) 2003-2007 Intel Corporation
> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
> PCI: Setting latency timer of device 0000:03:00.0 to 64
> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> phy0: Selected rate control algorithm 'iwl-3945-rs'
>
> # iwconfig wlan0
> wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
> Mode:Managed Channel:0 Access Point: Not-Associated
> Tx-Power=3D0 dBm
> Retry min limit:7 RTS thr:off Fragment thr=3D2346 B
> Encryption key:XXXX-XXXX-XX
> Link Quality:0 Signal level:0 Noise level:0
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> and iwconfig sees it, essid/enc settings are fine, but I don't get a
> link.
Same issue here, try iwlist wlan0 scan first and then it should work.
Regards,
ismail
--=20
=46aith is believing what you know isn't so -- Mark Twain
On 10/18/07, Johannes Berg <[email protected]> wrote:
> On Thu, 2007-10-18 at 08:23 -0400, Stephen Clark wrote:
>
> > >>iwlist eth1 scan would report no scan results, I then switched to loading
> > >>the kernel module with
> > >>the option that tells iwl3945 to do software scanning and it works
> > >>everytime now.
>
> > In my modprobe.conf file:
> > options iwl3945 disable_hw_scan=1
>
> Hah. Told you it wasn't mac80211's problem. Can somebody remind me again
> exactly why we have hardware scan offload when we parse each received
> packet anyway and the hardware doesn't even batch them so the CPU could
> wake up less?
>
1. Tuning to each channel is done internally by fw so you don't spend
cycles and it's is faster to switch channels so overall scanning take
less time. Sending probe responses is also offloaded. Returning to
operational channel is more precisely matched to DTIM period as it is
handled by RT code.
2. There are also more advanced modes of scanning such as during voice
traffic etc.
3. Yes beacon batching will be nice, but there is a memory tradeoff.
Tomas
> johannes
>
>
On Thu, 2007-10-18 at 08:23 -0400, Stephen Clark wrote:
> >>iwlist eth1 scan would report no scan results, I then switched to loading
> >>the kernel module with
> >>the option that tells iwl3945 to do software scanning and it works
> >>everytime now.
> In my modprobe.conf file:
> options iwl3945 disable_hw_scan=1
Hah. Told you it wasn't mac80211's problem. Can somebody remind me again
exactly why we have hardware scan offload when we parse each received
packet anyway and the hardware doesn't even batch them so the CPU could
wake up less?
johannes
On Wed, 2007-10-17 at 15:54 +0200, Jens Axboe wrote:
> Hi,
>
> Seeing that iwl3945 is now merged, I decided to switch my x60 to use
> that instead of ipw3945. That would leave me with zero kernel
> dependencies.
>
> Unfortunately it doesn't work. Loading the module reveals the device:
>
> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for
> Linux, 1.1.17ks
> iwl3945: Copyright(c) 2003-2007 Intel Corporation
> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
> PCI: Setting latency timer of device 0000:03:00.0 to 64
> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> phy0: Selected rate control algorithm 'iwl-3945-rs'
>
> # iwconfig wlan0
> wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
> Mode:Managed Channel:0 Access Point: Not-Associated
> Tx-Power=0 dBm
> Retry min limit:7 RTS thr:off Fragment thr=2346 B
> Encryption key:XXXX-XXXX-XX
> Link Quality:0 Signal level:0 Noise level:0
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> and iwconfig sees it, essid/enc settings are fine, but I don't get a
> link.
You do have the updated firmware, right? I don't think iwl3945 would
even load if you didn't, but it doesn't hurt to check.
Also, what exact kernel version are you using? 2.6.23 release kernel?
Or something from development series?
Dan
Jens Axboe wrote:
>On Wed, Oct 17 2007, Stephen Clark wrote:
> =20
>
>>Jens Axboe wrote:
>>
>> =20
>>
>>>On Wed, Oct 17 2007, Dan Williams wrote:
>>>=20
>>> =20
>>>
>>>>On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
>>>> =20
>>>> =20
>>>>
>>>>>On Wed, Oct 17 2007, Dan Williams wrote:
>>>>> =20
>>>>> =20
>>>>>
>>>>>>On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
>>>>>> =20
>>>>>> =20
>>>>>>
>>>>>>>On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
>>>>>>> =20
>>>>>>> =20
>>>>>>>
>>>>>>>>Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
>>>>>>>> =20
>>>>>>>> =20
>>>>>>>>
>>>>>>>>>Hi,
>>>>>>>>>
>>>>>>>>>Seeing that iwl3945 is now merged, I decided to switch my x60 =
to use
>>>>>>>>>that instead of ipw3945. That would leave me with zero kernel
>>>>>>>>>dependencies.
>>>>>>>>>
>>>>>>>>>Unfortunately it doesn't work. Loading the module reveals the=20
>>>>>>>>>device:
>>>>>>>>>
>>>>>>>>>iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection d=
river=20
>>>>>>>>>for
>>>>>>>>>Linux, 1.1.17ks
>>>>>>>>>iwl3945: Copyright(c) 2003-2007 Intel Corporation
>>>>>>>>>ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> =
IRQ 21
>>>>>>>>>PCI: Setting latency timer of device 0000:03:00.0 to 64
>>>>>>>>>iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connectio=
n
>>>>>>>>>iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
>>>>>>>>>phy0: Selected rate control algorithm 'iwl-3945-rs'
>>>>>>>>>
>>>>>>>>># iwconfig wlan0
>>>>>>>>>wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
>>>>>>>>> Mode:Managed Channel:0 Access Point: Not-Associated
>>>>>>>>> Tx-Power=3D0 dBm
>>>>>>>>> Retry min limit:7 RTS thr:off Fragment thr=3D2346=
B
>>>>>>>>> Encryption key:XXXX-XXXX-XX
>>>>>>>>> Link Quality:0 Signal level:0 Noise level:0
>>>>>>>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid fra=
g:0
>>>>>>>>> Tx excessive retries:0 Invalid misc:0 Missed beaco=
n:0
>>>>>>>>>
>>>>>>>>>and iwconfig sees it, essid/enc settings are fine, but I don't=
get a
>>>>>>>>>link.
>>>>>>>>> =20
>>>>>>>>> =20
>>>>>>>>>
>>>>>>>>Same issue here, try iwlist wlan0 scan first and then it should=
work.
>>>>>>>> =20
>>>>>>>> =20
>>>>>>>>
>>>>>>>Huh indeed, now it links fine! Thanks for the hint. Would be nic=
e to
>>>>>>>have fixed, though :-)
>>>>>>> =20
>>>>>>> =20
>>>>>>>
>>>>>>Odd, doesn't the driver need to do a scan _anyway_ to find the ri=
ght
>>>>>>BSSID to associate with if the cached scan results are more than =
a few
>>>>>>seconds old? Can you run '/sbin/iwevent' before trying a fresh
>>>>>>association, try to associate, ensure that it has failed, and rep=
ort=20
>>>>>>the
>>>>>>output?
>>>>>>
>>>>>>If you don't get something like:
>>>>>>
>>>>>>10:17:05.117937 eth1 Scan request completed
>>>>>>
>>>>>>shown there, then there's likely a bug in the driver because it's=
=20
>>>>>>either
>>>>>>(a) not scanning before trying to associate, or (b) not sending o=
ut=20
>>>>>>scan
>>>>>>completion events after it's done a scan.
>>>>>> =20
>>>>>> =20
>>>>>>
>>>>>Indeed, there is now Scan request completed before I run the iwlis=
t
>>>>>scan. iwevent output:
>>>>> =20
>>>>> =20
>>>>>
>>>>Hmm, the output below doesn't show the scan request completed, righ=
t?
>>>>
>>>> =20
>>>> =20
>>>>
>>>>>Waiting for Wireless Events from interfaces...
>>>>>16:20:27.453588 wlan0 Set Mode:Managed
>>>>>16:20:27.462104 wlan0 Set Encryption key:off
>>>>>16:20:27.463940 wlan0 Set Encryption key:****-****-** Secur=
ity=20
>>>>>mode:open
>>>>>16:20:27.466535 wlan0 Set ESSID:"kjellbergaxboe"
>>>>>
>>>>>waiting, nothing else happens. Then run iwlist scan from another
>>>>>terminal.
>>>>>
>>>>>16:20:53.892549 wlan0 Scan request completed
>>>>> =20
>>>>> =20
>>>>>
>>>>So you only get this when you manually scan right after setting the=
ssid
>>>>and key?
>>>> =20
>>>> =20
>>>>
>>>If you look at the time stamp, I ran the iwlist scan about 26 second=
s
>>>after loading the module. When the module is loaded, the networking
>>>script sets the essid and encryption key.
>>>
>>>So yes, I only get that 'Scan request completed' line after running
>>>iwlist scan manually.
>>>
>>>=20
>>> =20
>>>
>>Don't know whether this is related, but I was having all kinds of tro=
uble=20
>>getting associated,
>>iwlist eth1 scan would report no scan results, I then switched to loa=
ding=20
>>the kernel module with
>>the option that tells iwl3945 to do software scanning and it works=20
>>everytime now.
>> =20
>>
>
>Which option is that?
>
> =20
>
In my modprobe.conf file:
options iwl3945 disable_hw_scan=3D1
HTH,
Steve
--=20
"They that give up essential liberty to obtain temporary safety,=20
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty=20
decreases." (Thomas Jefferson)
Jens Axboe wrote:
>On Wed, Oct 17 2007, Dan Williams wrote:
> =20
>
>>On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
>> =20
>>
>>>On Wed, Oct 17 2007, Dan Williams wrote:
>>> =20
>>>
>>>>On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
>>>> =20
>>>>
>>>>>On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
>>>>> =20
>>>>>
>>>>>>Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
>>>>>> =20
>>>>>>
>>>>>>>Hi,
>>>>>>>
>>>>>>>Seeing that iwl3945 is now merged, I decided to switch my x60 to=
use
>>>>>>>that instead of ipw3945. That would leave me with zero kernel
>>>>>>>dependencies.
>>>>>>>
>>>>>>>Unfortunately it doesn't work. Loading the module reveals the de=
vice:
>>>>>>>
>>>>>>>iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection dri=
ver for
>>>>>>>Linux, 1.1.17ks
>>>>>>>iwl3945: Copyright(c) 2003-2007 Intel Corporation
>>>>>>>ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IR=
Q 21
>>>>>>>PCI: Setting latency timer of device 0000:03:00.0 to 64
>>>>>>>iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
>>>>>>>iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
>>>>>>>phy0: Selected rate control algorithm 'iwl-3945-rs'
>>>>>>>
>>>>>>># iwconfig wlan0
>>>>>>>wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
>>>>>>> Mode:Managed Channel:0 Access Point: Not-Associated
>>>>>>> Tx-Power=3D0 dBm
>>>>>>> Retry min limit:7 RTS thr:off Fragment thr=3D2346 =
B
>>>>>>> Encryption key:XXXX-XXXX-XX
>>>>>>> Link Quality:0 Signal level:0 Noise level:0
>>>>>>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag=
:0
>>>>>>> Tx excessive retries:0 Invalid misc:0 Missed beacon=
:0
>>>>>>>
>>>>>>>and iwconfig sees it, essid/enc settings are fine, but I don't g=
et a
>>>>>>>link.
>>>>>>> =20
>>>>>>>
>>>>>>Same issue here, try iwlist wlan0 scan first and then it should w=
ork.
>>>>>> =20
>>>>>>
>>>>>Huh indeed, now it links fine! Thanks for the hint. Would be nice =
to
>>>>>have fixed, though :-)
>>>>> =20
>>>>>
>>>>Odd, doesn't the driver need to do a scan _anyway_ to find the righ=
t
>>>>BSSID to associate with if the cached scan results are more than a =
few
>>>>seconds old? Can you run '/sbin/iwevent' before trying a fresh
>>>>association, try to associate, ensure that it has failed, and repor=
t the
>>>>output?
>>>>
>>>>If you don't get something like:
>>>>
>>>>10:17:05.117937 eth1 Scan request completed
>>>>
>>>>shown there, then there's likely a bug in the driver because it's e=
ither
>>>>(a) not scanning before trying to associate, or (b) not sending out=
scan
>>>>completion events after it's done a scan.
>>>> =20
>>>>
>>>Indeed, there is now Scan request completed before I run the iwlist
>>>scan. iwevent output:
>>> =20
>>>
>>Hmm, the output below doesn't show the scan request completed, right?
>>
>> =20
>>
>>>Waiting for Wireless Events from interfaces...
>>>16:20:27.453588 wlan0 Set Mode:Managed
>>>16:20:27.462104 wlan0 Set Encryption key:off
>>>16:20:27.463940 wlan0 Set Encryption key:****-****-** Securit=
y mode:open
>>>16:20:27.466535 wlan0 Set ESSID:"kjellbergaxboe"
>>>
>>>waiting, nothing else happens. Then run iwlist scan from another
>>>terminal.
>>>
>>>16:20:53.892549 wlan0 Scan request completed
>>> =20
>>>
>>So you only get this when you manually scan right after setting the s=
sid
>>and key?
>> =20
>>
>
>If you look at the time stamp, I ran the iwlist scan about 26 seconds
>after loading the module. When the module is loaded, the networking
>script sets the essid and encryption key.
>
>So yes, I only get that 'Scan request completed' line after running
>iwlist scan manually.
>
> =20
>
Don't know whether this is related, but I was having all kinds of=20
trouble getting associated,
iwlist eth1 scan would report no scan results, I then switched to=20
loading the kernel module with
the option that tells iwl3945 to do software scanning and it works=20
everytime now.
Steve
--=20
"They that give up essential liberty to obtain temporary safety,=20
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty=20
decreases." (Thomas Jefferson)
On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
> On Wed, Oct 17 2007, Ismail D=C3=B6nmez wrote:
> > Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
> > > Hi,
> > >
> > > Seeing that iwl3945 is now merged, I decided to switch my x60 to =
use
> > > that instead of ipw3945. That would leave me with zero kernel
> > > dependencies.
> > >
> > > Unfortunately it doesn't work. Loading the module reveals the dev=
ice:
> > >
> > > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driv=
er for
> > > Linux, 1.1.17ks
> > > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ=
21
> > > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> > > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > > phy0: Selected rate control algorithm 'iwl-3945-rs'
> > >
> > > # iwconfig wlan0
> > > wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
> > > Mode:Managed Channel:0 Access Point: Not-Associated
> > > Tx-Power=3D0 dBm
> > > Retry min limit:7 RTS thr:off Fragment thr=3D2346 B
> > > Encryption key:XXXX-XXXX-XX
> > > Link Quality:0 Signal level:0 Noise level:0
> > > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:=
0
> > > Tx excessive retries:0 Invalid misc:0 Missed beacon:=
0
> > >
> > > and iwconfig sees it, essid/enc settings are fine, but I don't ge=
t a
> > > link.
> >=20
> > Same issue here, try iwlist wlan0 scan first and then it should wor=
k.
>=20
> Huh indeed, now it links fine! Thanks for the hint. Would be nice to
> have fixed, though :-)
Odd, doesn't the driver need to do a scan _anyway_ to find the right
BSSID to associate with if the cached scan results are more than a few
seconds old? Can you run '/sbin/iwevent' before trying a fresh
association, try to associate, ensure that it has failed, and report th=
e
output?
If you don't get something like:
10:17:05.117937 eth1 Scan request completed
shown there, then there's likely a bug in the driver because it's eithe=
r
(a) not scanning before trying to associate, or (b) not sending out sca=
n
completion events after it's done a scan.
Dan
On Wed, Oct 17, 2007 at 03:54:53PM +0200, Jens Axboe wrote:
> iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for
> Linux, 1.1.17ks
> iwl3945: Copyright(c) 2003-2007 Intel Corporation
> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
> PCI: Setting latency timer of device 0000:03:00.0 to 64
> iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> phy0: Selected rate control algorithm 'iwl-3945-rs'
>
> # iwconfig wlan0
> wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
> Mode:Managed Channel:0 Access Point: Not-Associated
> Tx-Power=0 dBm
> Retry min limit:7 RTS thr:off Fragment thr=2346 B
> Encryption key:XXXX-XXXX-XX
> Link Quality:0 Signal level:0 Noise level:0
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> and iwconfig sees it, essid/enc settings are fine, but I don't get a
> link.
Seems like "so far, so good" except for the "don't get a link"
part...what is the output of iwlist wlan0 scan?
John
--
John W. Linville
[email protected]
On Wed, Oct 17 2007, Dan Williams wrote:
> On Wed, 2007-10-17 at 16:22 +0200, Jens Axboe wrote:
> > On Wed, Oct 17 2007, Dan Williams wrote:
> > > On Wed, 2007-10-17 at 16:11 +0200, Jens Axboe wrote:
> > > > On Wed, Oct 17 2007, Ismail D=F6nmez wrote:
> > > > > Wednesday 17 October 2007 Tarihinde 16:54:53 yazm????t??:
> > > > > > Hi,
> > > > > >
> > > > > > Seeing that iwl3945 is now merged, I decided to switch my x=
60 to use
> > > > > > that instead of ipw3945. That would leave me with zero kern=
el
> > > > > > dependencies.
> > > > > >
> > > > > > Unfortunately it doesn't work. Loading the module reveals t=
he device:
> > > > > >
> > > > > > iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connectio=
n driver for
> > > > > > Linux, 1.1.17ks
> > > > > > iwl3945: Copyright(c) 2003-2007 Intel Corporation
> > > > > > ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) =
-> IRQ 21
> > > > > > PCI: Setting latency timer of device 0000:03:00.0 to 64
> > > > > > iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connec=
tion
> > > > > > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > > > > > phy0: Selected rate control algorithm 'iwl-3945-rs'
> > > > > >
> > > > > > # iwconfig wlan0
> > > > > > wlan0 IEEE 802.11g ESSID:"xxxxxxxxxxxxxx"
> > > > > > Mode:Managed Channel:0 Access Point: Not-Associ=
ated
> > > > > > Tx-Power=3D0 dBm
> > > > > > Retry min limit:7 RTS thr:off Fragment thr=3D=
2346 B
> > > > > > Encryption key:XXXX-XXXX-XX
> > > > > > Link Quality:0 Signal level:0 Noise level:0
> > > > > > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid=
frag:0
> > > > > > Tx excessive retries:0 Invalid misc:0 Missed b=
eacon:0
> > > > > >
> > > > > > and iwconfig sees it, essid/enc settings are fine, but I do=
n't get a
> > > > > > link.
> > > > >=20
> > > > > Same issue here, try iwlist wlan0 scan first and then it shou=
ld work.
> > > >=20
> > > > Huh indeed, now it links fine! Thanks for the hint. Would be ni=
ce to
> > > > have fixed, though :-)
> > >=20
> > > Odd, doesn't the driver need to do a scan _anyway_ to find the ri=
ght
> > > BSSID to associate with if the cached scan results are more than =
a few
> > > seconds old? Can you run '/sbin/iwevent' before trying a fresh
> > > association, try to associate, ensure that it has failed, and rep=
ort the
> > > output?
> > >=20
> > > If you don't get something like:
> > >=20
> > > 10:17:05.117937 eth1 Scan request completed
> > >=20
> > > shown there, then there's likely a bug in the driver because it's=
either
> > > (a) not scanning before trying to associate, or (b) not sending o=
ut scan
> > > completion events after it's done a scan.
> >=20
> > Indeed, there is now Scan request completed before I run the iwlist
> > scan. iwevent output:
>=20
> Hmm, the output below doesn't show the scan request completed, right?
>=20
> > Waiting for Wireless Events from interfaces...
> > 16:20:27.453588 wlan0 Set Mode:Managed
> > 16:20:27.462104 wlan0 Set Encryption key:off
> > 16:20:27.463940 wlan0 Set Encryption key:****-****-** Securi=
ty mode:open
> > 16:20:27.466535 wlan0 Set ESSID:"kjellbergaxboe"
> >=20
> > waiting, nothing else happens. Then run iwlist scan from another
> > terminal.
> >=20
> > 16:20:53.892549 wlan0 Scan request completed
>=20
> So you only get this when you manually scan right after setting the s=
sid
> and key?
If you look at the time stamp, I ran the iwlist scan about 26 seconds
after loading the module. When the module is loaded, the networking
script sets the essid and encryption key.
So yes, I only get that 'Scan request completed' line after running
iwlist scan manually.
--=20
Jens Axboe
On Thursday 15 November 2007 at 10:05 am, Mike Kershaw penned
about "Re: [ipw3945-devel] iwl3945 doesn't work:
> On Thu, Nov 15, 2007 at 05:30:14AM -0500, Pablo Sanchez wrote:
> > On Thursday 15 November 2007 at 5:26 am, Jens Axboe penned
> >
> > about "Re: [ipw3945-devel] iwl3945 doesn't work:
> > > I'll revert to using ipw3945, it worked flawlessly for me.
> > > Hopefully the iwl3945 driver will work sometime in the future,
> > > but as you note, not a lot of progress appears to be happening.
> > > So I wont hold my breath.
> >
> > Hmmm, will that driver work on my Intel PRO 4965 card?
>
> No, but iwl4965 from the same driver tree will.
I think you jumped into the thread. The iwl4965 driver is covered by
iwlwifi and that's the driver which I've reported a couple of issues.
So far, no word from Intel. Hence why I'm using 'blinky'
blinky - a 3COM card which blinks once a second.
Cheers,
--
Pablo
On Thu, Nov 15 2007, Pablo Sanchez wrote:
> On Thursday 15 November 2007 at 4:39 am, Jens Axboe penned
> about "Re: [ipw3945-devel] iwl3945 doesn't work:
>
> > I'll second that, using todays snap still requires me to do an
> > iwlist scan before I can use the network.
>
> Same here and for now, I've given up on using the Intel card on my
> laptop. I slapped an El Cheapo 3COM card. While less mW's and
> sensitivity, the MadWifi support is awesome for this atheros based
> card.
>
> Under stress, my ping times are within 100ms (unlike what I reported
> previously), throughput is at 5Mbps and it works well with
> KnetworkManager.
>
> I'm not complaining about the Intel support, just noting for now the
> problem isn't pressing for me. I'll happily test new drops as they
> come out and address the issues I reported.
>
> I'd appreciate even an acknowledgment though (rather than the old
> /dev/null treatment).
I'll revert to using ipw3945, it worked flawlessly for me. Hopefully the
iwl3945 driver will work sometime in the future, but as you note, not a
lot of progress appears to be happening. So I wont hold my breath.
--
Jens Axboe
On Thursday 15 November 2007 at 4:39 am, Jens Axboe penned
about "Re: [ipw3945-devel] iwl3945 doesn't work:
> I'll second that, using todays snap still requires me to do an
> iwlist scan before I can use the network.
Same here and for now, I've given up on using the Intel card on my
laptop. I slapped an El Cheapo 3COM card. While less mW's and
sensitivity, the MadWifi support is awesome for this atheros based
card.
Under stress, my ping times are within 100ms (unlike what I reported
previously), throughput is at 5Mbps and it works well with
KnetworkManager.
I'm not complaining about the Intel support, just noting for now the
problem isn't pressing for me. I'll happily test new drops as they
come out and address the issues I reported.
I'd appreciate even an acknowledgment though (rather than the old
/dev/null treatment).
Cheers,
--
Pablo
On Thu, Nov 15 2007, Pablo Sanchez wrote:
> On Thursday 15 November 2007 at 5:26 am, Jens Axboe penned
> about "Re: [ipw3945-devel] iwl3945 doesn't work:
>
> > I'll revert to using ipw3945, it worked flawlessly for me.
> > Hopefully the iwl3945 driver will work sometime in the future, but
> > as you note, not a lot of progress appears to be happening. So I
> > wont hold my breath.
>
> Hmmm, will that driver work on my Intel PRO 4965 card?
Nope, I think you are out of luck, it only covers 3945ABG only.
> Do you know whether I need to download the different microcode?
I don't know how big the differences between 3945 and 4945 are, but I'd
be surprised if that works. Others here will know more for sure.
> I'm all for junking the El Cheapo card. It's annoying have it blink
> at me every second. :p
:-)
--
Jens Axboe
I believe that a main problem is that people have trouble reproducing i=
t.
and despite my -somewhat- implicit question there is not more informati=
on
in this thread now. Other than some symptoms. It would probably help if=
you
posted system/software specifications and debug info to a (new) bug ove=
r at
bughost.org. (modprobe iwl3945 debug=3D0x43fff) to allow for it to be t=
racked better?
Because now imho we are just poking at it with a medium length stick.
With the information here, I honestly have no idea where to look, other=
s might
have the same problem.
ian
Jens Axboe wrote:
> On Thu, Nov 15 2007, John W. Linville wrote:
>> On Thu, Nov 15, 2007 at 10:39:22AM +0100, Jens Axboe wrote:
>>> On Thu, Nov 15 2007, Ismail D=F6nmez wrote:
>>>> Saturday 10 November 2007 Tarihinde 04:18:27 yazm????t??:
>>>>> I wonder if anybody knows something more about this issue by now,
>>>>> as it appears to occur to a few people.
>>>>>
>>>>> I reread the thread (rather quickly) but I do not see many specif=
ications
>>>>> of driver/mac80211/kernel. The few cases that do contain specs al=
l appear
>>>>> to be using fedora (don't want to jump to conclusions). But just =
wondering
>>>>> if anybody experienced this on any other kernel?
>>>> Btw this is still not fixed in latest git (post rc2).
>>> I'll second that, using todays snap still requires me to do an iwli=
st
>>> scan before I can use the network.
>>>
>>> Is anyone working on this at all? This was reported a month ago, ye=
t no
>>> progress or real developer interest in fixing this is apparent.
>> I don't see any pending patches that seem relevant. FWIW I'll proba=
bly
>> round-up what I do have and make them available today (and probably
>> in a Fedora kernel too).
>>
>> Does the disable_hw_scan=3D1 still work for you? Perhaps we should
>> consider making that the default...
>=20
> disable_hw_scan=3D1 never worked for me - I tried it, and it made no
> difference. I _have_ to do an iwlist wlan0 scan before it links with =
my
> access point, otherwise it doesn't work.
>=20
On Thu, Nov 15 2007, John W. Linville wrote:
> On Thu, Nov 15, 2007 at 10:39:22AM +0100, Jens Axboe wrote:
> > On Thu, Nov 15 2007, Ismail D=F6nmez wrote:
> > > Saturday 10 November 2007 Tarihinde 04:18:27 yazm????t??:
> > > > I wonder if anybody knows something more about this issue by no=
w,
> > > > as it appears to occur to a few people.
> > > >
> > > > I reread the thread (rather quickly) but I do not see many spec=
ifications
> > > > of driver/mac80211/kernel. The few cases that do contain specs =
all appear
> > > > to be using fedora (don't want to jump to conclusions). But jus=
t wondering
> > > > if anybody experienced this on any other kernel?
> > >=20
> > > Btw this is still not fixed in latest git (post rc2).
> >=20
> > I'll second that, using todays snap still requires me to do an iwli=
st
> > scan before I can use the network.
> >=20
> > Is anyone working on this at all? This was reported a month ago, ye=
t no
> > progress or real developer interest in fixing this is apparent.
>=20
> I don't see any pending patches that seem relevant. FWIW I'll probab=
ly
> round-up what I do have and make them available today (and probably
> in a Fedora kernel too).
>=20
> Does the disable_hw_scan=3D1 still work for you? Perhaps we should
> consider making that the default...
disable_hw_scan=3D1 never worked for me - I tried it, and it made no
difference. I _have_ to do an iwlist wlan0 scan before it links with my
access point, otherwise it doesn't work.
--=20
Jens Axboe
On Thu, Nov 15, 2007 at 10:39:22AM +0100, Jens Axboe wrote:
> On Thu, Nov 15 2007, Ismail D=F6nmez wrote:
> > Saturday 10 November 2007 Tarihinde 04:18:27 yazm????t??:
> > > I wonder if anybody knows something more about this issue by now,
> > > as it appears to occur to a few people.
> > >
> > > I reread the thread (rather quickly) but I do not see many specif=
ications
> > > of driver/mac80211/kernel. The few cases that do contain specs al=
l appear
> > > to be using fedora (don't want to jump to conclusions). But just =
wondering
> > > if anybody experienced this on any other kernel?
> >=20
> > Btw this is still not fixed in latest git (post rc2).
>=20
> I'll second that, using todays snap still requires me to do an iwlist
> scan before I can use the network.
>=20
> Is anyone working on this at all? This was reported a month ago, yet =
no
> progress or real developer interest in fixing this is apparent.
I don't see any pending patches that seem relevant. FWIW I'll probably
round-up what I do have and make them available today (and probably
in a Fedora kernel too).
Does the disable_hw_scan=3D1 still work for you? Perhaps we should
consider making that the default...
John
--=20
John W. Linville
[email protected]
I wonder if anybody knows something more about this issue by now,
as it appears to occur to a few people.
I reread the thread (rather quickly) but I do not see many specifications
of driver/mac80211/kernel. The few cases that do contain specs all appear
to be using fedora (don't want to jump to conclusions). But just wondering if
anybody experienced this on any other kernel?
The log that I saw from a person with these symptoms, showed a perfectly normal
booting driver, doing all the initialization identical to my functional card,
except that apparently iwl_mac_open() (which is currently known as iwl3945_mac_start iirc)
is never called.
this callback is conditionally called from mac80211, in on it's turn a callback from
even higher up the kernel stack. Hence my best (uneducated) guess would be that
for some reason mac80211 doesn't call the ops->start(), but the scan (completion)
somehow manages to rectify this
I believe this bug is similar though with older versions of the code
http://bughost.org/bugzilla/show_bug.cgi?id=1452
although back then the scan didn't magically fix it.
Seeing as the driver appears to be functioning normally (it's receiving! and dropping
packages because not open). and my knowledge of mac80211 is very limited i'm hoping
someone here knows:
What could sensibly be causing ops->start() not to be called?
Tomas Winkler wrote:
> On 10/18/07, Johannes Berg <[email protected]> wrote:
>> On Thu, 2007-10-18 at 08:23 -0400, Stephen Clark wrote:
>>
>>>>> iwlist eth1 scan would report no scan results, I then switched to loading
>>>>> the kernel module with
>>>>> the option that tells iwl3945 to do software scanning and it works
>>>>> everytime now.
>>> In my modprobe.conf file:
>>> options iwl3945 disable_hw_scan=1
>> Hah. Told you it wasn't mac80211's problem. Can somebody remind me again
>> exactly why we have hardware scan offload when we parse each received
>> packet anyway and the hardware doesn't even batch them so the CPU could
>> wake up less?
>>
> 1. Tuning to each channel is done internally by fw so you don't spend
> cycles and it's is faster to switch channels so overall scanning take
> less time. Sending probe responses is also offloaded. Returning to
> operational channel is more precisely matched to DTIM period as it is
> handled by RT code.
> 2. There are also more advanced modes of scanning such as during voice
> traffic etc.
> 3. Yes beacon batching will be nice, but there is a memory tradeoff.
> Tomas
>
>> johannes
>>
>>
>
On Thu, Nov 15 2007, Ismail D=F6nmez wrote:
> Saturday 10 November 2007 Tarihinde 04:18:27 yazm????t??:
> > I wonder if anybody knows something more about this issue by now,
> > as it appears to occur to a few people.
> >
> > I reread the thread (rather quickly) but I do not see many specific=
ations
> > of driver/mac80211/kernel. The few cases that do contain specs all =
appear
> > to be using fedora (don't want to jump to conclusions). But just wo=
ndering
> > if anybody experienced this on any other kernel?
>=20
> Btw this is still not fixed in latest git (post rc2).
I'll second that, using todays snap still requires me to do an iwlist
scan before I can use the network.
Is anyone working on this at all? This was reported a month ago, yet no
progress or real developer interest in fixing this is apparent.
--=20
Jens Axboe
On Thursday 15 November 2007 at 5:26 am, Jens Axboe penned
about "Re: [ipw3945-devel] iwl3945 doesn't work:
> I'll revert to using ipw3945, it worked flawlessly for me.
> Hopefully the iwl3945 driver will work sometime in the future, but
> as you note, not a lot of progress appears to be happening. So I
> wont hold my breath.
Hmmm, will that driver work on my Intel PRO 4965 card?
Do you know whether I need to download the different microcode?
I'm all for junking the El Cheapo card. It's annoying have it blink
at me every second. :p
Cheers,
--
Pablo
On Thu, Nov 15 2007, Mike Kershaw wrote:
> On Thu, Nov 15, 2007 at 05:30:14AM -0500, Pablo Sanchez wrote:
> > On Thursday 15 November 2007 at 5:26 am, Jens Axboe penned
> > about "Re: [ipw3945-devel] iwl3945 doesn't work:
> >
> > > I'll revert to using ipw3945, it worked flawlessly for me.
> > > Hopefully the iwl3945 driver will work sometime in the future, but
> > > as you note, not a lot of progress appears to be happening. So I
> > > wont hold my breath.
> >
> > Hmmm, will that driver work on my Intel PRO 4965 card?
>
> No, but iwl4965 from the same driver tree will.
Ehm, I'd be surprised if Pablo didn't mean if ipw3945 would work with
his card, not iwl3945.
--
Jens Axboe
Saturday 10 November 2007 Tarihinde 04:18:27 yazm=C4=B1=C5=9Ft=C4=B1:
> I wonder if anybody knows something more about this issue by now,
> as it appears to occur to a few people.
>
> I reread the thread (rather quickly) but I do not see many specificat=
ions
> of driver/mac80211/kernel. The few cases that do contain specs all ap=
pear
> to be using fedora (don't want to jump to conclusions). But just wond=
ering
> if anybody experienced this on any other kernel?
Btw this is still not fixed in latest git (post rc2).
Regards,
ismail
--=20
=46aith is believing what you know isn't so -- Mark Twain
On Thu, Nov 15, 2007 at 05:30:14AM -0500, Pablo Sanchez wrote:
> On Thursday 15 November 2007 at 5:26 am, Jens Axboe penned
> about "Re: [ipw3945-devel] iwl3945 doesn't work:
>
> > I'll revert to using ipw3945, it worked flawlessly for me.
> > Hopefully the iwl3945 driver will work sometime in the future, but
> > as you note, not a lot of progress appears to be happening. So I
> > wont hold my breath.
>
> Hmmm, will that driver work on my Intel PRO 4965 card?
No, but iwl4965 from the same driver tree will.
> Do you know whether I need to download the different microcode?
Yes.
http://intellinuxwireless.org
-m
--
Mike Kershaw/Dragorn <[email protected]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
Todays lesson is always to ignore your feelings and listen to the robot head.