On Tue, 28 Oct 2008 09:33:37 +0800, Zhu Yi wrote:
>
> Looks good so far. But I failed to see what are you trying to connect?
> Can you try "iwconfig wlan0 channnel <> essid <>"?
Sorry. I should have supplied that information on the first try. The network is
a standard WPA-protected G-band network at 2.437Ghz (channel 6).
That command seems to help a bit. At least I was able to connect more often
after executing it. I will observe that in detail tomorrow though.
>
> Does your AP work on A band?
>
> Thanks,
> -yi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkGciAACgkQz+diZ7c2xfiRfgCfT4HzEHYqup PRtNrlZay135VQ
WSgAn0ULlFWKRyt6gAD9yjfE16KDrZH9
=bl3v
-----END PGP SIGNATURE-----

On Mon, 2008-10-27 at 18:59 -0700, Mirco Tischler wrote:
> > Looks good so far. But I failed to see what are you trying to
> connect?
> > Can you try "iwconfig wlan0 channnel <> essid <>"?
> Sorry. I should have supplied that information on the first try. The
> network is
> a standard WPA-protected G-band network at 2.437Ghz (channel 6).
> That command seems to help a bit. At least I was able to connect more
> often after executing it.

You don't need this command if wpa_supplicant works correctly. Is it a
hidden SSID AP?

Thanks,
-yi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 28 Oct 2008 10:19:50 +0800, Zhu Yi wrote:
> You don't need this command if wpa_supplicant works correctly. Is it a
> hidden SSID AP?
No it isn't. Did I mention it worked well with 2.6.27?
> Thanks,
> -yi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkGhNcACgkQz+diZ7c2xfhatgCfRh5RF0kGlE owz2guEhsp72dk
EZ4AoIY6LE/GQ5a6AgoUWKkwS3hw/gMX
=QzL9
-----END PGP SIGNATURE-----

On Tue, 28 Oct 2008 09:33:37 +0800
Zhu Yi wrote:

> On Mon, 2008-10-27 at 18:02 -0700, Mirco Tischler wrote:
> > Hi
> >
> > I have problems connecting to wlan with my iwl4965 chip and
> > 2.6.28-rc2 (didn't test -rc1). Networkmanager just times out every
> > time. Only after playing around with rmmod/modprobe and killswitch
> > I am sometimes able to connect. But I cannot reproduce this
> > reliably yet.
> >
> > This is what I get in dmesg (from modprobe iwlagn to connection
> > failure):
> >
> > [ 1881.884690] iwlagn: Intel(R) Wireless WiFi Link AGN driver for
> > Linux,1.3.27kds
> > [ 1881.884692] iwlagn: Copyright(c) 2003-2008 Intel Corporation
> > [ 1881.884809] iwlagn 0000:06:00.0: PCI INT A -> GSI 18 (level,
> > low) -> IRQ 18 [ 1881.884836] iwlagn 0000:06:00.0: setting latency
> > timer to 64 [ 1881.884952] iwlagn: Detected Intel Wireless WiFi
> > Link 4965AGN REV=0x4 [ 1881.935149] iwlagn: Tunable channels: 13
> > 802.11bg, 19 802.11a channels [ 1881.936327] phy4: Selected rate
> > control algorithm 'iwl-agn-rs' [ 1885.965591] iwlagn 0000:06:00.0:
> > PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 1885.965874] iwlagn
> > 0000:06:00.0: irq 41 for MSI/MSI-X [ 1885.965974] iwlagn
> > 0000:06:00.0: firmware: requesting iwlwifi-4965-2.ucode
> > [ 1886.181600] Registered led device: iwl-phy4:radio [ 1886.181618]
> > Registered led device: iwl-phy4:assoc [ 1886.181635] Registered led
> > device: iwl-phy4:RX [ 1886.181654] Registered led device:
> > iwl-phy4:TX [ 1886.213631] ADDRCONF(NETDEV_UP): wlan0: link is not
> > ready [ 1887.572768] iwlagn: TX Power requested while scanning!
>
> Looks good so far. But I failed to see what are you trying to connect?
> Can you try "iwconfig wlan0 channnel <> essid <>"?
>

I had this same issue

turning on CONFIG_WIRELESS_OLD_REGULATORY fixed it for me....

--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon, 2008-10-27 at 22:32 -0600, Arjan van de Ven wrote:
> I had this same issue
>
> turning on CONFIG_WIRELESS_OLD_REGULATORY fixed it for me....

Arjan,

This is a different bug. He has the wireless worked sometimes.

I think your problem relates to 5GHz channel usage. We have already a
patch queued to resolve the problem. We will have regulatory framework
reworked to better solve the problem. But I guess it will be in .29 time
frame.

Thanks,
-yi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 28 Oct 2008 13:23:34 +0800, Zhu Yi wrote:
> On Mon, 2008-10-27 at 22:32 -0600, Arjan van de Ven wrote:
> > I had this same issue
> >
> > turning on CONFIG_WIRELESS_OLD_REGULATORY fixed it for me....
>
> Arjan,
>
> This is a different bug. He has the wireless worked sometimes.
>
> I think your problem relates to 5GHz channel usage. We have already a
> patch queued to resolve the problem. We will have regulatory framework
> reworked to better solve the problem. But I guess it will be in .29 time
> frame.
>
> Thanks,
> -yi
I tested Arjan's solution nevertheless and it seems to do the job. I can't find
the "TX Power requested" line anymore on dmesg output with that config option
enabled anymore and it connects without problems.
This is how it looks now:
[ 777.680750] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux,1.3..27kds
[ 777.680753] iwlagn: Copyright(c) 2003-2008 Intel Corporation
[ 777.680878] iwlagn 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ18
[ 777.680908] iwlagn 0000:06:00.0: setting latency timer to 64
[ 777.680977] iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
[ 777.731255] iwlagn: Tunable channels: 13 802.11bg, 19 802.11a channels
[ 777.732432] phy1: Selected rate control algorithm 'iwl-agn-rs'
[ 781.764539] iwlagn 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ18
[ 781.764821] iwlagn 0000:06:00.0: irq 41 for MSI/MSI-X
[ 781.764919] iwlagn 0000:06:00.0: firmware: requesting iwlwifi-4965-2.ucode
[ 781.980719] Registered led device: iwl-phy1:radio
[ 781.980764] Registered led device: iwl-phy1:assoc
[ 781.980808] Registered led device: iwl-phy1:RX
[ 781.980856] Registered led device: iwl-phy1:TX
[ 782.014001] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 783.633713] wlan0: authenticate with AP 00:c0:a8:e5:e5:a5
[ 783.635637] wlan0: authenticated
[ 783.635644] wlan0: associate with AP 00:c0:a8:e5:e5:a5
[ 783.642770] wlan0: RX AssocResp from 00:c0:a8:e5:e5:a5 (capab=0x431 status=0
aid=1)
[ 783.642776] wlan0: associated [ 783.669684] ADDRCONF(NETDEV_CHANGE): wlan0:
link becomes ready

I tested it quickly and not very thoroughly on the wpa-eap encrypted network at
university and it showed the same behaviour: no connection without
CONFIG_WIRELESS_OLD_REGULATORY and no problems with it enabled.

Thanks
Mirco

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkHPL4ACgkQz+diZ7c2xfjQnACeMmJUXCPSWQ KkVDfR80db4Rwj
7k4An1TJLd7OuByRyuO02uRpSkWVdDH+
=ODct
-----END PGP SIGNATURE-----

On Tue, 2008-10-28 at 17:24 +0100, Mirco Tischler wrote:

> > This is a different bug. He has the wireless worked sometimes.
> >
> > I think your problem relates to 5GHz channel usage. We have already a
> > patch queued to resolve the problem. We will have regulatory framework
> > reworked to better solve the problem. But I guess it will be in .29 time
> > frame.
> >
> > Thanks,
> > -yi
> I tested Arjan's solution nevertheless and it seems to do the job. I can't find
> the "TX Power requested" line anymore on dmesg output with that config option
> enabled anymore and it connects without problems.

Can we have a dmesg output with the "TX power requested" line posted
here?

johannes

-----BEGIN PGP SIGNATURE-----
Comment: Johannes Berg (powerbook)

iQIcBAABAgAGBQJJB1uvAAoJEKVg1VMiehFY6ZwP/RHbu4/+BODKzryx9FYmvcW8
5Mo/3uFmFYbcvRJ1nr+GVnTcK93dGkJSnFh3lx6e6blcZvJEij3YHc etZmByM4+p
tbVX4KyqmxTmYB0h0gWX5uWp834tT9M1eOJgrVEHH00OM+zo8C co43VqrAoipTN2
Nw1VYljVWOwUSiSAExCyocxAVACE78tAlVqG1B6i+gPxyGKX9c kgmjuNypkFUHH5
nMPAHREznHwdhFoG2tRKxpmAGL19vjhJx2iulLlooX1IJ25Cwr L1ajvgW+TCbY7y
yb4xF7cki8MdeQSIjKFPfFiR0UEwzFESpZk6qunTyVLHML08ZL to2SZrkOy2eXop
u4xKXq3dbypHneUHcASJ7ohX7DcL+X+I1StXHaawYfQTncyuEj DTSSLd9cEgTDiy
7SEiUxIskwmTu8fxuIKUePrttFP+1bTuHsXba+K20uJ0IEufML Rd3W0bT1l+i5IW
du9wmM4bsyYt+ac8sABpvQ26DO+NdlhqXReeMV+dCDvkBOw7IA HKoSeFXpGwSglf
JQgI/Ht6PrcwhdpTK1FVQ+qcZegD3kcDRHP1pxePDq/AgO9as3jLxJqUzE4Rey7d
uuSRXMH1vTg17/ueg8fRxloRAg6bMnQupTS7xrGdKZA0wgNJckcc/yRVw5/dw+SE
BUt/D+jnaj6DCjIA5D1U
=CMEv
-----END PGP SIGNATURE-----

On Tue, 2008-10-28 at 23:58 +0100, Mirco Tischler wrote:
> On Tue, 28 Oct 2008 19:36:34 +0100, Johannes Berg wrote:
> > Can we have a dmesg output with the "TX power requested" line posted
> > here?

> You mean the hole output? Cause I posted the wireless part in my initial mail.

Sorry, I got confused, the initial mail is fine.

johannes

-----BEGIN PGP SIGNATURE-----
Comment: Johannes Berg (powerbook)

iQIcBAABAgAGBQJJB5rmAAoJEKVg1VMiehFYLRwP/0vpdoOSco4sADMGjczQVLk1
hosskmojSTVOhxHJktp3pxLW+RVP4cyqOp+/+m/Zu6MyIaOLeYUPoVau1inrmrWs
jEuzbud6KIQPvBIUUcSBGhoEqF+0S966CNDFbqsMeGunaBnIKl Kb0QBgKS+vufS4
8mgHVzzNqRDVlDEXL8gnRfldh+kUwxt4wzLFsBlILtLUJd8yia B/AIDxul/ecSIq
GYk46y0xZtyyhKwOEu9TXnHs7PYNtdhs6jTt+R4MyXXhJMsjsv Oe15C1rGiPCxl5
IelHJWtlfP6wYttk/qYNoRQ44Ot+tOsP0M4M3oHmAWM9gaat//c8dxUxoXgac6x5
Mxzj1g/xy65miZjwaHI9kwWL3cwEj1TSIigHVG6PSkQEYuwAmHkWFv8qm rt242ps
nMGYSojzNrmPTYzxGvVSGoOCqgvjgKWPtgmIECDXKV1CLjjPGq A20MSOtM+v9Vti
gpZ6Qh4vccvjIfpAvfkgMwU8gksY1B80s3iajuEEIWcQ6JWzOt n4ywt+mUGVQ+6g
sdNHidYux2GG4fNmjCNjq70nunV8qeSCKz3TWfJ1gQJG4FXSCd 1Yj9Jp2+kPjJbi
/+daadcz6HCr56VcYPwcq9N9LNQwBVLYPSfS4tqtUPoVxJf/yCsq28sXtrzKKDD1
lLXqgUycfqqxco/LOBPD
=3ub8
-----END PGP SIGNATURE-----

In between I found out that suspend and hibernation are broken too. I would
open a new thread but in the "Suspend to RAM regression in 2.6.28-rc2
(bisected)" thread that handled a similar problem iwlwifi was blamed, at least
in the mails I read. So maybe this is related here too.

The machine suspends and hibernates fine, but doesn't wake up anymore correctly.
On hibernation I end up with a black screen and only the mouse which I can
still move. But anything else is locked up. I can't switch to virtual console
with ctrl+alt+f? nor can I restart the xserver. I can't even connect on
network. The only thing I can do is move the mouse on a black screen or push
the power button.

On suspend it is a little better. After wakeup I see the frames of the windows
but not the content, and the gnome panel. And again I can move the mouse but I
can't interact with anything. At least I can connect over network using ssh.
But processes like compiz don't respond to kill -9 PID and when I try to kill
Xorg the machine completely locks up.

Another thing that I just noticed is very slow boot. From startup of udev until
short before X starts the boot lasts minutes. What I noticed is that there are
long phases of no hard disk activity. And I don't really have the heart to
write this but I have the impression that keyboard activity (i.e. pressing
random keys) causes the harddisk to read again and the hole boot to go on.

Sorry for this long subjective description of symptoms only without any
kernel messages or anything but that's all I can deliver at the moment. Maybe
tomorrow I find more than only half an hour to dig into this.

Thanks again

Mirco

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkHodcACgkQz+diZ7c2xfhhYgCfTFHzHbvSfF DBa5Ft3Z0rDKix
kMAAn2A6QNjIFWRZlOgcp28Zj4ZCvKoB
=7sfz
-----END PGP SIGNATURE-----

On Wed, 2008-10-29 at 00:24 +0800, Mirco Tischler wrote:
>
> I tested it quickly and not very thoroughly on the wpa-eap encrypted
> network at
> university and it showed the same behaviour: no connection without
> CONFIG_WIRELESS_OLD_REGULATORY and no problems with it enabled.

Interesting. The only difference between without and with
CONFIG_WIRELESS_OLD_REGULATORY is the txpower is lower and you can only
do passive scan. Can you try attached patch?

Thanks,
-yi

On Wed, 29 Oct 2008 14:18:04 +0800, Zhu Yi wrote:
> Can you try attached patch?
>
> Thanks,
> -yi
I did. Didn't solve the problems but here's the output:
[ 880.195147] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux,1.3..27kds
[ 880.195150] iwlagn: Copyright(c) 2003-2008 Intel Corporation
[ 880.195300] iwlagn 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ18
[ 880.195327] iwlagn 0000:06:00.0: setting latency timer to 64
[ 880.195444] iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
[ 880.245264] iwlagn: Tunable channels: 13 802.11bg, 19 802.11a channels
[ 880.247969] phy3: Selected rate control algorithm 'iwl-agn-rs'
[ 884.274477] iwlagn 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ18
[ 884.275247] iwlagn 0000:06:00.0: irq 41 for MSI/MSI-X
[ 884.275361] iwlagn 0000:06:00.0: firmware: requesting iwlwifi-4965-2.ucode
[ 884.489886] Registered led device: iwl-phy3:radio
[ 884.489933] Registered led device: iwl-phy3:assoc
[ 884.489973] Registered led device: iwl-phy3:RX
[ 884.490012] Registered led device: iwl-phy3:TX
[ 884.526082] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 884.784601] iwlagn: TX Power requested while scanning!
[ 884.784611] Pid: 9839, comm: iwlagn/1 Not tainted 2.6.28-rc2-oldreg-debug #27
[ 884.784617] Call Trace:
[ 884.784632] [] ? native_smp_send_reschedule+0x4d/0x4f
[ 884.784658] [] iwl4965_send_tx_power+0x5a/0xf2f [iwlagn]
[ 884.784668] [] ? _spin_unlock_irqrestore+0x31/0x3c
[ 884.784677] [] ? try_to_wake_up+0x222/0x234
[ 884.784685] [] ? default_wake_function+0xd/0xf
[ 884.784693] [] ? autoremove_wake_function+0x11/0x38
[ 884.784703] [] ? __wake_up_common+0x46/0x76
[ 884.784710] [] ? _spin_unlock_irqrestore+0x31/0x3c
[ 884.784717] [] ? __wake_up+0x43/0x4f
[ 884.784725] [] ? queue_work+0x59/0x68
[ 884.784735] [] ?ieee80211_mlme_notify_scan_completed+0xc7/0xd9
[ 884.784743] [] ? ieee80211_scan_completed+0x2e8/0x32c
[ 884.784770] [] ? iwl_rx_queue_restock+0xc6/0x143 [iwlcore]
[ 884.784790] [] iwl_set_tx_power+0x6b/0x71 [iwlcore]
[ 884.784812] [] iwl_bg_scan_completed+0xbc/0xcd [iwlcore]
[ 884.784834] [] ? iwl_bg_scan_completed+0x0/0xcd [iwlcore]
[ 884.784842] [] run_workqueue+0x95/0x138
[ 884.784849] [] worker_thread+0xf5/0x109
[ 884.784856] [] ? autoremove_wake_function+0x0/0x38
[ 884.784864] [] ? worker_thread+0x0/0x109
[ 884.784871] [] kthread+0x49/0x76
[ 884.784879] [] child_rip+0xa/0x11
[ 884.784886] [] ? kthread+0x0/0x76
[ 884.784892] [] ? child_rip+0x0/0x11

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkJ7dgACgkQz+diZ7c2xfjNaQCfb6wFB9Fqf+ edf0RAJduuuPP4
8Z0AnRp8TH3oKdZlIJSiSpme/gN+noI8
=EDpY
-----END PGP SIGNATURE-----

On Thu, 2008-10-30 at 10:24 -0700, Mirco Tischler wrote:
> On Wed, 29 Oct 2008 14:18:04 +0800, Zhu Yi wrote:
> > Can you try attached patch?
> >
> > Thanks,
> > -yi
> I did. Didn't solve the problems but here's the output:

That helped us to obtain more information. Could you please try commit
9685e33a2c919c1e95cb7072988fc1e0f0bad3d9 ?

Reproduced here for convenience:

commit 9685e33a2c919c1e95cb7072988fc1e0f0bad3d9
Author: Mohamed Abbas
Date: Thu Oct 23 23:48:54 2008 -0700

iwlwifi: clear scanning bits upon failure

In iwl_bg_request_scan function, if we could not send a
scan command it will go to done.
In done it does the right thing to call mac80211 with
scan complete, but the problem is STATUS_SCAN_HW is still
set causing any future scan to fail. Fix by clearing the scanning status
bits if scan fails.

Signed-off-by: Mohamed Abbas
Signed-off-by: Reinette Chatre
Signed-off-by: John W. Linville

diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index 3379b41..b0abf89 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -834,6 +834,13 @@ static void iwl_bg_request_scan(struct work_struct *data)
return;

done:
+ /* Cannot perform scan. Make sure we clear scanning
+ * bits from status so next scan request can be performed.
+ * If we don't clear scanning status bit here all next scan
+ * will fail
+ */
+ clear_bit(STATUS_SCAN_HW, &priv->status);
+ clear_bit(STATUS_SCANNING, &priv->status);
/* inform mac80211 scan aborted */
queue_work(priv->workqueue, &priv->scan_completed);
mutex_unlock(&priv->mutex);



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 30 Oct 2008 10:55:38 -0700, reinette chatre wrote:
>
> That helped us to obtain more information. Could you please try commit
> 9685e33a2c919c1e95cb7072988fc1e0f0bad3d9 ?
>
Solves the problem for me.

Thanks

Mirco

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkLhcwACgkQz+diZ7c2xfg7ZQCfSA0w44IWHa fd6/I/1DvtbRIf
TS0An3RYQRc0l47+YChmNL9RoLx5WBf5
=29jl
-----END PGP SIGNATURE-----