headers
Pavel Machek | 1 Nov 01:12
Picon

Re: iwl3945 in 2.6.24-rc1 dies under load

Hi!

> > tcpspray -n 1 -b 10000000 10.0.0.2
> > 
> > Oct 31 01:42:56 amd kernel: iwl3945: Microcode SW error detected.
> > Restarting 0x82000008.
> > Oct 31 01:42:56 amd kernel: iwl3945: Error Reply type 0x00000005 cmd
> > REPLY_TX (0x1C) seq 0x02C7 ser 0x0000004B
> > Oct 31 01:42:58 amd kernel: iwl3945: Can't stop Rx DMA.
> 
> Please attach the dmesg with module param debug=0x43fff (make sure
> CONFIG_IWLWIFI_DEBUG is selected). This will dump the firmware event log
> for debug.

I could reproduce it with reduced deubgging... after 2 hours or so,
and I did 2x tcpspray + ping -f.

Is it useful, or is full dump needed?
								Pavel

iwl3945: I iwl_rx_handle r = 124, i = 123, REPLY_3945_RX, 0x1b
iwl3945: I iwl_rx_handle r = 125, i = 124, STATISTICS_NOTIFICATION, 0x9d
iwl3945: U iwl_pci_remove *** UNLOAD DRIVER ***
iwl3945: U __iwl_down iwl3945 is going down
iwl3945: U iwl_hw_nic_stop_master stop master
iwl3945: U iwl_clear_free_frames 0 frames on pre-allocated heap on clear.
iwl3945: U iwl_mac_remove_interface enter
iwl3945: U iwl_mac_remove_interface leave
iwl3945: U iwl_mac_stop enter
iwl3945: U iwl_mac_stop leave
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luis Carlos Cobo | 1 Nov 01:21

Re: [PATCH 4/7] o80211s: (mac80211s) basic mesh interface support

On 10/31/07, Dan Williams <dcbw@...> wrote:
> I'm not sure where this would go (and therefore don't know if you've
> done it or not), but we need to make sure that mesh devices have some
> sort of differentiating attribute in sysfs.  For example, the mac80211
> master device has a "type" of 803 (or something like that) and and the
> STA device has a type of 1.  That probably can't be used here, because
> mesh devices are the same as STA devices from the perspective of an
> application trying to push data to it.  But something else needs to be
> there.  More comments below...

I do not know either what would be the best place (Johannes?) but I am
going to implement specific mesh statistics in sysfs so you could use
that or I could add a specific mesh_iface flag in sysfs.

> > +             IEEE80211_MESH
>
> Just "MESH" doesn't seem quite descriptive enough here...  what exactly
> is this state supposed to mean, that the interface is currently in a
> mesh?

Right. As soon as the interface comes up, it is in a mesh, even if it
is the only node. The mesh id will be the one specified or the
wildcard zero-length mesh id if none was specified. There is no
association or authentication process (actually there is, but in a
per-link basis), so only one mesh state is required. If you prefer
MESH_ON, MESH_ACTIVE or something like that I do not mind changing it.

> /proc/net/wireless was a colossal mistake from a userspace perspective
> since people started screenscraping it, and that's almost _always_ the
> wrong wrong wrong thing to do.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luis Carlos Cobo | 1 Nov 01:36

Re: [PATCH 4/7] o80211s: (mac80211s) basic mesh interface support

Hi Johannes,

thanks for the comments. I will incorporate the suggestions I don't
discuss about below (get rid of /proc/net/mesh, ieee80211s.c, etc).

On 10/31/07, Johannes Berg <johannes@...> wrote:
> > +ieee80211s-objs = ieee80211s.o ieee80211s_stats.o ieee80211s_pathtable.o
>
> I think I'd prefer shorter filenames. Maybe mesh networking should also
> be made configurable in Kconfig?

Agreed about filename length. I would prefer not to make mesh
networking configurable, as STA, IBSS, etc modes aren't configurable
either. I prefer to avoid polluting the data path with ifdefs.

> There are mesh APs too, that is not supported yet I take it? How do you
> plan to support this when you're essentially hard-coding MESH == STA
> here and in many other places?

Mesh APs are not supported yet, but we plan to support them through a
different interface type (e.g.  ..._TYPE_MAP) or extending the AP
interface type. Mesh STAs and APs will share all the mesh-specific
stuff (peer link discovery, path discovery, etc) but they have little
in common in the data path, so I do not think it makes sense to use
the same interface type for both. Maybe I should rename ..IF_TYPE_MESH
to ..IF_TYPE_MESH_STA?

> > +static void ieee80211_mesh(struct net_device *dev,
> > +                        struct ieee80211_if_sta *ifsta)
> > +{
(Continue reading)

Permalink | Reply | 3 comments |
headers
Rafael J. Wysocki | 1 Nov 02:59
Picon
Gravatar

Re: iwl3945 in 2.6.24-rc1 dies under load

On Wednesday, 31 October 2007 01:52, Pavel Machek wrote:
> 
> Hi!
> 
> ...does not seem to work too well :-(. It connects with the AP
> (good!), and survives some "normal" use, but it died at first big
> tcpspray (baaaad!).

Is this a regression from 2.6.23?

> Oct 31 01:03:57 amd log1n[1411]: ROOT LOGIN on `tty6'
> Oct 31 01:05:06 amd kernel: iwl3945: Intel(R) PRO/Wireless 3945ABG/BG
> Network Connection driver for Linux, 1.1.17kds
> Oct 31 01:05:06 amd kernel: iwl3945: Copyright(c) 2003-2007 Intel
> Corporation
> Oct 31 01:05:06 amd kernel: PCI: Setting latency timer of device
> 0000:03:00.0 to 64
> Oct 31 01:05:06 amd kernel: iwl3945: Detected Intel PRO/Wireless
> 3945ABG Network Connection
> Oct 31 01:05:07 amd kernel: iwl3945: Tunable channels: 11 802.11bg, 13
> 802.11a channels
> Oct 31 01:05:07 amd kernel: phy4: Selected rate control algorithm
> 'simple'
> Oct 31 01:06:05 amd kernel: wlan0: Initial auth_alg=0
> Oct 31 01:06:05 amd kernel: wlan0: authenticate with AP
> 00:11:2f:0e:95:a0
> Oct 31 01:06:05 amd kernel: wlan0: RX authentication from
> 00:11:2f:0e:95:a0 (alg=0 transaction=2 status=0)
> Oct 31 01:06:05 amd kernel: wlan0: authenticated
> Oct 31 01:06:05 amd kernel: wlan0: associate with AP 00:11:2f:0e:95:a0
(Continue reading)

Permalink | Reply | 0 comments |
headers
bruno randolf | 1 Nov 02:42

Re: ilog2 overkill in ieee80211_get_hdrlen?

johannes,

thanks for the explanation!

bruno

On Wednesday 31 October 2007 21:20:35 Johannes Berg wrote:
> > in 'net/mac80211/util.c', in ieee80211_get_hdrlen (line 175), a function
> > ilog2 is used to determine the number of bits to shift for
> > IEEE80211_STYPE_QOS_DATA. isn't that a bit of an overkill when we could
> > just do >> 6? i mean IEEE80211_STYPE_QOS_DATA isn't going to change after
> > all...
>
> Yeah but ilog2() evaluates to a constant here so it doesn't matter, and
> I think this is more readable.
>
> > if (fc & IEEE80211_STYPE_QOS_DATA)
> > 	hdrlen += 2;
> >
> > would be a bit more readable.
>
> It used to be that but that's a branch and the generated code is better
> the other way.
>
> johannes
Permalink | Reply | 0 comments |
headers
Zhu Yi | 1 Nov 02:37
Picon
Favicon

Re: iwl3945 in 2.6.24-rc1 dies under load


On Thu, 2007-11-01 at 01:12 +0100, Pavel Machek wrote:
> iwl3945: Microcode SW error detected.  Restarting 0x82000008.
> iwl3945: Start IWL Error Log Dump:
> iwl3945: Status: 0x00010172, Config: 00000000 count: 1
> iwl3945: Desc       Time       asrtPC  blink2 ilink1  nmiPC   Line
> iwl3945: SYSASSERT     (#5) 0403761131 0x0089A 0x0025E 0x00300 0x073C2
> 75
> 
> iwl3945: Start IWL Event Log Dump: display count 256, wraps 86422
> iwl3945: 0000000256     0x0000006a      403761132
> iwl3945: 0000000217     0x0000012d      403755413
> iwl3945: 0000000047     0x00000161      8394228
> iwl3945: 0000228273     0x00000160      403755488
> iwl3945: 0000000000     0x0000006a      403755497
> iwl3945: 0000000217     0x0000012d      403755504
> iwl3945: 0000000000     0x00000161      403755506
> iwl3945: 0000228274     0x00000160      403755577
> iwl3945: 0000000000     0x0000006a      403755586
> iwl3945: 0000000217     0x0000012d      403755593
> iwl3945: 0000000000     0x00000161      403755595
> iwl3945: 0000228275     0x00000160      403755668
> iwl3945: 0000000000     0x0000006a      403755677
> iwl3945: 0000000217     0x0000012d      403755684
> iwl3945: 0000000000     0x00000161      403755686
> iwl3945: 0000228276     0x00000160      403755757
> iwl3945: 0000000000     0x0000006a      403755766
> iwl3945: 0000000217     0x0000012d      403755773
> iwl3945: 0000000000     0x00000161      403755775
> iwl3945: 0000228277     0x00000160      403755849
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luis R. Rodriguez | 1 Nov 05:31
Picon
Gravatar

[PATCH 0/7] ath5k: Few patches which start fixing G mode

Here are a few patches which start fixing G mode settings.

  Luis
Permalink | Reply | 3 comments |
headers
Luis R. Rodriguez | 1 Nov 05:34
Picon
Gravatar

[PATCH 1/7] ath5k: Fix initval/eeprom/IQ calibration for G mode

ath5k_hw_reset() was always setting initval and eeprom settings for B mode
when using G mode. This is because a B channel was being picked up first. We
should first instead check for G channel. This patch also introduces a
driver_mode variable which should be used instead for determing
more reliably the mode we're in.

This fixing another bug where IQ calibration was not being run for
G mode as CHANNEL_B was always being picked up first. We now instead
check for driver_mode.

Similar problem was occurring in ath5k_hw_rf5112_rfregs(), we fix this
there too.

Changes to phy.c, hw.c
Changes-licensed-under: ISC

Signed-off-by: Luis R. Rodriguez <mcgrof@...>
---
 drivers/net/wireless/ath5k/hw.c  |   27 +++++++++++++++++----------
 drivers/net/wireless/ath5k/phy.c |    6 +++---
 2 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/ath5k/hw.c b/drivers/net/wireless/ath5k/hw.c
index 50ceab0..8ac88e7 100644
--- a/drivers/net/wireless/ath5k/hw.c
+++ b/drivers/net/wireless/ath5k/hw.c
@@ -538,7 +538,7 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
 	struct ath5k_eeprom_info *ee = &ah->ah_capabilities.cap_eeprom;
 	u32 data, s_seq, s_ant, s_led[3];
 	s32 noise_floor;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luis R. Rodriguez | 1 Nov 05:35
Picon
Gravatar

[PATCH 2/7] ath5k: Remove opaque pointers from ath5k_hw_attach()

Since we don't have a HAL anymore there is no point to use opaque pointers
in ath5k_hw_attach(). This will also give hw.c access to ath5k_softc
structure now when needed. While we're at it, lets also give some ah_sh
a reasonable name, ah_sh --> ah_iobase.

Changes to base.c
Changes-licensed-under: 3-clause-BSD

Changes to ath5k.h, hw.c
Changes-licensed-under: ISC

Signed-off-by: Luis R. Rodriguez <mcgrof@...>
---
 drivers/net/wireless/ath5k/ath5k.h |   10 +++++-----
 drivers/net/wireless/ath5k/base.c  |    2 +-
 drivers/net/wireless/ath5k/hw.c    |   11 +++++------
 3 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/ath5k/ath5k.h b/drivers/net/wireless/ath5k/ath5k.h
index 4122466..20567b1 100644
--- a/drivers/net/wireless/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath5k/ath5k.h
@@ -943,8 +943,8 @@ struct ath5k_capabilities {
 struct ath5k_hw {
 	u32			ah_magic;

-	void			*ah_sc;
-	void __iomem		*ah_sh;
+	struct ath5k_softc	*ah_sc;
+	void __iomem		*ah_iobase;
(Continue reading)

Permalink | Reply | 22 comments |
headers
Luis R. Rodriguez | 1 Nov 05:37
Picon
Gravatar

[PATCH 3/7] ath5k: Clean up ath5k rate duration settings

Replace ath5k's rate duration computations for one using
mac80211's internals. Another consideration here is to simply
remove these and put them into initval values. They seem to be
static values based only on mode. We can do this later though once
we can physically confirm by trial and error these are indeed just
used for ACK timeout. The next puzzle is figuring out which registers
are actually setting the control rates.

Changes to ath5k.h, hw.c
Changes-licensed-under: ISC

Signed-off-by: Luis R. Rodriguez <mcgrof@...>
---
 drivers/net/wireless/ath5k/ath5k.h |   80 --------------
 drivers/net/wireless/ath5k/hw.c    |  201 ++++++++++++++----------------------
 2 files changed, 76 insertions(+), 205 deletions(-)

diff --git a/drivers/net/wireless/ath5k/ath5k.h b/drivers/net/wireless/ath5k/ath5k.h
index 20567b1..3354b37 100644
--- a/drivers/net/wireless/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath5k/ath5k.h
@@ -374,86 +374,6 @@ enum ath5k_pkt_type {
 )

 /*
- * Used to compute TX times
- */
-#define AR5K_CCK_SIFS_TIME		10
-#define AR5K_CCK_PREAMBLE_BITS		144
-#define AR5K_CCK_PLCP_BITS		48
(Continue reading)

Permalink | Reply | 18 comments |

Gmane