Recent linux-wireless git changes have broken my prism54pci card

Recent linux-wireless git changes have broken my prism54pci card

[Hans de Goede]

Hi All,

I first reported this in Fedora bugzilla, as I'm using Fedora with a Fedora 
kernel (which includes recent  linux-wireless git snapshots), see here for the 
Fedora bugreport:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249823

Updating from the Fedora 7 test kernel to the final results in very poor 
performance, and going to even newer versions of the Fedora kernel totally 
breaks connectivity. Linville thought it would be best to further discuss this 
here, so here I am.

I've looked at recent git commits to the prism54 / p54pci driver and have been 
trying it revision by revision, eventually I've managed to pin the cause down 
to 2 patches, below is a verbatim cut and paste from the bugzilla entry, 
containing my analysis:

---

I've been busy researching this and I have come to the
following conclusions.

1) with the 2.6.20-2something F7-test kernel everything works fine build date
    3 march, I can give you the exact revision if you want.

2) with the fc release kerkel (3194) things work, but the connection is often lost.

3) with the 2.6.23-0.49.rc1.git3.fc8, the card asociates and thats it.

Using wireless git and out of tree driver building I've found that the following
2 patches are the culprits:

Patch causing loose off connection within seconds when fully loading the link
with a local file transfer:
http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=62ee473d67b7ae353d210b186abaadc37a642237

Only associating and nothing else:
http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=7d59453a9dbe50dc9bab846c410e39f8d5b10c83
And then specifically the changes to prism54common.c

This is with an isl3886 cardbus card, using the p54pci driver.

----

I would be more then happy to test any changes.

Thanks & Regards,

Hans


p.s.

Please keep my CC-ed I'm not on the list.

Re: Recent linux-wireless git changes have broken my prism54pci card

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

On Sunday 12 August 2007 22:50, Hans de Goede wrote:
> Patch causing loose off connection within seconds when fully loading the
> link with a local file transfer:
> http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=62ee473d67b7ae353
>d210b186abaadc37a642237
>
> Only associating and nothing else:
> http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=7d59453a9dbe50dc9
>bab846c410e39f8d5b10c83 And then specifically the changes to prism54common.c
>
Links not working.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Recent linux-wireless git changes have broken my prism54pci card

[Hans de Goede]

Michael Wu wrote:
> On Sunday 12 August 2007 22:50, Hans de Goede wrote:
>> Patch causing loose off connection within seconds when fully loading the
>> link with a local file transfer:
>> http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=62ee473d67b7ae353
>> d210b186abaadc37a642237
>>
>> Only associating and nothing else:
>> http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=7d59453a9dbe50dc9
>> bab846c410e39f8d5b10c83 And then specifically the changes to prism54common.c
>>
> Links not working.
> 

Darn, is there a gitweb of the wireless-dev git anywhere else, I'm pretty sure 
I can find those patches pretty quick again.

Regards,

Hans

Re: Recent linux-wireless git changes have broken my prism54pci card

[Andy Green]

Somebody in the thread at some point said:

> Darn, is there a gitweb of the wireless-dev git anywhere else, I'm
> pretty sure I can find those patches pretty quick again.

http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=summary

-Andy

Re: Recent linux-wireless git changes have broken my prism54pci card

[Hans de Goede]

Andy Green wrote:
> Somebody in the thread at some point said:
> 
>> Darn, is there a gitweb of the wireless-dev git anywhere else, I'm
>> pretty sure I can find those patches pretty quick again.
> 
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=summary
> 

Erm,

I already found that one, but there is no drivers/net/wireless/mac80211 dir 
there. What am I missing?

Regards,

Hans

Re: Recent linux-wireless git changes have broken my prism54pci card

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

On Monday 13 August 2007 00:49, Hans de Goede wrote:
> I already found that one, but there is no drivers/net/wireless/mac80211 dir
> there. What am I missing?
>
John Linville recently collapsed that directory into driver/net/wireless.

If you can just find the title of the patches/commits or describe them, that's 
probably enough for me to find them.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Recent linux-wireless git changes have broken my prism54pci card

[Andy Green]

Somebody in the thread at some point said:
> On Monday 13 August 2007 00:49, Hans de Goede wrote:
>> I already found that one, but there is no drivers/net/wireless/mac80211 dir
>> there. What am I missing?
>>
> John Linville recently collapsed that directory into driver/net/wireless.

Looking through that gitweb HEAD, the mac80211 stuff appears to be just
plain absent at the moment as Hans says:

http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=blob;f=drivers/net/wireless/Kconfig;h=ae27af0141c02ee5b6100aa7f512dfdd77c4e703;hb=HEAD

-Andy

Re: Recent linux-wireless git changes have broken my prism54pci card

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

Michael Wu wrote:
> On Monday 13 August 2007 00:49, Hans de Goede wrote:
>> I already found that one, but there is no drivers/net/wireless/mac80211 dir
>> there. What am I missing?
>>
> John Linville recently collapsed that directory into driver/net/wireless.
> 
> If you can just find the title of the patches/commits or describe them, that's 
> probably enough for me to find them.
> 

Okay, I still had copies of various git revisions of prism54common.c and .h 
(aka the culprits) on my laptop. I've run some tests again to make sure I had 
the right revisions in mind for the breakage (which I had). I've attached 2 
patches:
diff: with this reversed my speed increases 10x and more importantly when fully
   loading the link (using scp from a local non wireless ethernet machine) it no
   longer looses the connection in a couple of seconds

diff2, when I do not reverse this one, it still associates, but it no longer
   receives / or transmits packages. (no dhcp, no ping when manually assigning
   IP's, etc).

Regards,

Hans

[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 1387 bytes --]

--- prism54common.h.orig	2007-07-27 20:47:47.000000000 +0200
+++ prism54common.h	2007-07-27 20:47:46.000000000 +0200
@@ -232,40 +232,44 @@
 
 static const struct ieee80211_rate p54_rates[] = {
 	{ .rate = 10,
-	  .val = 1,
-	  .flags = IEEE80211_RATE_CCK },
+	  .val = 0,
+	  .val2 = 0x10,
+	  .flags = IEEE80211_RATE_CCK_2 },
 	{ .rate = 20,
-	  .val = 2,
-	  .flags = IEEE80211_RATE_CCK },
+	  .val = 1,
+	  .val2 = 0x11,
+	  .flags = IEEE80211_RATE_CCK_2 },
 	{ .rate = 55,
-	  .val = 3,
-	  .flags = IEEE80211_RATE_CCK },
+	  .val = 2,
+	  .val2 = 0x12,
+	  .flags = IEEE80211_RATE_CCK_2 },
 	{ .rate = 110,
-	  .val = 4,
-	  .flags = IEEE80211_RATE_CCK },
+	  .val = 3,
+	  .val2 = 0x13,
+	  .flags = IEEE80211_RATE_CCK_2 },
 	{ .rate = 60,
-	  .val = 5,
+	  .val = 4,
 	  .flags = IEEE80211_RATE_OFDM },
 	{ .rate = 90,
-	  .val = 6,
+	  .val = 5,
 	  .flags = IEEE80211_RATE_OFDM },
 	{ .rate = 120,
-	  .val = 7,
+	  .val = 6,
 	  .flags = IEEE80211_RATE_OFDM },
 	{ .rate = 180,
-	  .val = 8,
+	  .val = 7,
 	  .flags = IEEE80211_RATE_OFDM },
 	{ .rate = 240,
-	  .val = 9,
+	  .val = 8,
 	  .flags = IEEE80211_RATE_OFDM },
 	{ .rate = 360,
-	  .val = 10,
+	  .val = 9,
 	  .flags = IEEE80211_RATE_OFDM },
 	{ .rate = 480,
-	  .val = 11,
+	  .val = 10,
 	  .flags = IEEE80211_RATE_OFDM },
 	{ .rate = 540,
-	  .val = 12,
+	  .val = 11,
 	  .flags = IEEE80211_RATE_OFDM },
 };
 

[-- Attachment #3: diff2 --]
[-- Type: text/plain, Size: 8525 bytes --]

--- prism54common-11-4.c	2007-07-27 20:47:47.000000000 +0200
+++ prism54common-13-6.c	2007-07-27 20:47:47.000000000 +0200
@@ -3,6 +3,7 @@
  * Common code for mac80211 Prism54 drivers
  *
  * Copyright (c) 2006, Michael Wu <flamingice@sourmilk.net>
+ * Copyright (c) 2007, Christian Lamparter <chunkeey@web.de>
  *
  * Based on the islsm (softmac prism54) driver, which is:
  * Copyright 2004-2006 Jean-Baptiste Note <jbnote@gmail.com>, et al.
@@ -283,10 +284,11 @@
 	u16 freq = le16_to_cpu(hdr->freq);
 
 	rx_status.ssi = hdr->rssi;	/* TODO: check this */
-	rx_status.rate = hdr->rate & 0x0f;
+	rx_status.rate = hdr->rate & 0x1f; /* report short preambles & CCK too */
 	rx_status.channel = freq == 2484 ? 14 : (freq - 2407)/5;
 	rx_status.freq = freq;
 	rx_status.phymode = MODE_IEEE80211G;
+	rx_status.antenna = hdr->antenna;
 
 	skb_pull(skb, sizeof(*hdr));
 	skb_trim(skb, le16_to_cpu(hdr->len));
@@ -294,6 +296,19 @@
 	ieee80211_rx_irqsafe(dev, skb, &rx_status);
 }
 
+static void inline p54_wake_free_queues(struct ieee80211_hw *dev)
+{
+	struct p54_common *priv = dev->priv;
+	int i;
+
+	/* ieee80211_start_queues is great if all queues are really empty.
+	 * But, what if some are full? */
+
+	for (i = 0; i < dev->queues; i++)
+		if (priv->tx_stats.data[i].len < priv->tx_stats.data[i].limit)
+			ieee80211_wake_queue(dev, i);
+}
+
 static void p54_rx_frame_sent(struct ieee80211_hw *dev, struct sk_buff *skb)
 {
 	struct p54_common *priv = dev->priv;
@@ -331,6 +346,7 @@
 			status.retry_count = payload->retries - 1;
 			status.ack_signal = le16_to_cpu(payload->ack_rssi);
 			skb_pull(entry, sizeof(*hdr) + sizeof(struct p54_tx_control_allocdata));
+			priv->tx_stats.data[status.control.queue].len--;
 			ieee80211_tx_status_irqsafe(dev, entry, &status);
 			break;
 		} else
@@ -340,7 +356,7 @@
 
 	if (freed >= IEEE80211_MAX_RTS_THRESHOLD + 0x170 +
 	    sizeof(struct p54_control_hdr))
-		ieee80211_wake_queue(dev, 0);
+		p54_wake_free_queues(dev);
 }
 
 static void p54_rx_control(struct ieee80211_hw *dev, struct sk_buff *skb)
@@ -443,7 +459,7 @@
 		__skb_queue_after(&priv->tx_queue, target_skb, skb);
 		if (largest_hole < IEEE80211_MAX_RTS_THRESHOLD + 0x170 +
 				   sizeof(struct p54_control_hdr))
-			ieee80211_stop_queue(dev, 0);
+			ieee80211_stop_queues(dev);
 	}
 	spin_unlock_irqrestore(&priv->tx_queue.lock, flags);
 
@@ -453,6 +469,7 @@
 static int p54_tx(struct ieee80211_hw *dev, struct sk_buff *skb,
 		  struct ieee80211_tx_control *control)
 {
+	struct ieee80211_tx_queue_stats_data *current_queue;
 	struct p54_common *priv = dev->priv;
 	struct p54_control_hdr *hdr;
 	struct p54_tx_control_allocdata *txhdr;
@@ -460,6 +477,14 @@
 	size_t padding, len;
 	u8 rate;
 
+	current_queue = &priv->tx_stats.data[control->queue];
+	if (unlikely(current_queue->len > current_queue->limit))
+		return NETDEV_TX_BUSY;
+	current_queue->len++;
+	current_queue->count++;
+	if (current_queue->len == current_queue->limit)
+		ieee80211_stop_queue(dev, control->queue);
+
 	padding = (unsigned long)(skb->data - (sizeof(*hdr) + sizeof(*txhdr))) & 3;
 	len = skb->len;
 
@@ -493,12 +518,13 @@
 	memset(txhdr->rateset, rate, 8);
 	txhdr->wep_key_present = 0;
 	txhdr->wep_key_len = 0;
-	txhdr->frame_type = cpu_to_le32(0x4);
+	txhdr->frame_type = cpu_to_le32(control->queue + 4);
 	txhdr->magic4 = 0;
-	txhdr->antenna = control->antenna_sel_tx;
+	txhdr->antenna = (control->antenna_sel_tx == 0) ?
+		2 : control->antenna_sel_tx - 1;
 	txhdr->output_power = 0x7f; // HW Maximum
 	txhdr->magic5 = (control->flags & IEEE80211_TXCTL_NO_ACK) ?
-			 0 : cpu_to_le32(0x23);
+		0 : ((rate > 0x3) ? cpu_to_le32(0x33) : cpu_to_le32(0x23));
 	if (padding)
 		txhdr->align[0] = padding;
 
@@ -654,6 +680,64 @@
 	return 0;
 }
 
+#define P54_SET_QUEUE(queue, ai_fs, cw_min, cw_max, burst)	\
+do {	 							\
+	queue.aifs = cpu_to_le16(ai_fs);			\
+	queue.cwmin = cpu_to_le16(cw_min);			\
+	queue.cwmax = cpu_to_le16(cw_max);			\
+	queue.txop = (burst == 0) ? 				\
+		0 : cpu_to_le16((burst * 100) / 32 + 1);	\
+} while(0)
+
+static void p54_init_vdcf(struct ieee80211_hw *dev)
+{
+	struct p54_common *priv = dev->priv;
+	struct p54_control_hdr *hdr;
+	struct p54_tx_control_vdcf *vdcf;
+
+	/* all USB V1 adapters need a extra headroom */
+	hdr = (void *)priv->cached_vdcf + priv->tx_hdr_len;
+	hdr->magic1 = cpu_to_le16(0x8001);
+	hdr->len = cpu_to_le16(sizeof(*vdcf));
+	hdr->type = cpu_to_le16(P54_CONTROL_TYPE_DCFINIT);
+	hdr->req_id = cpu_to_le32(priv->rx_start);
+
+	vdcf = (struct p54_tx_control_vdcf *) hdr->data;
+
+	P54_SET_QUEUE(vdcf->queue[0], 0x0002, 0x0003, 0x0007, 0x000f);
+	P54_SET_QUEUE(vdcf->queue[1], 0x0002, 0x0007, 0x000f, 0x001e);
+	P54_SET_QUEUE(vdcf->queue[2], 0x0002, 0x000f, 0x03ff, 0x0014);
+	P54_SET_QUEUE(vdcf->queue[3], 0x0007, 0x000f, 0x03ff, 0x0000);
+}
+
+static void p54_set_vdcf(struct ieee80211_hw *dev)
+{
+	struct p54_common *priv = dev->priv;
+	struct p54_control_hdr *hdr;
+	struct p54_tx_control_vdcf *vdcf;
+
+	hdr = (void *)priv->cached_vdcf + priv->tx_hdr_len;
+
+	p54_assign_address(dev, NULL, hdr, sizeof(*hdr) + sizeof(*vdcf), NULL);
+
+	vdcf = (struct p54_tx_control_vdcf *) hdr->data;
+
+	if (dev->conf.flags & IEEE80211_CONF_SHORT_SLOT_TIME) {
+		vdcf->slottime = 9;
+		vdcf->magic1 = 0x00;
+		vdcf->magic2 = 0x10;
+	} else {
+		vdcf->slottime = 20;
+		vdcf->magic1 = 0x0a;
+		vdcf->magic2 = 0x06;
+	}
+
+	/* (see prism54/isl_oid.h for further details) */
+	vdcf->frameburst = cpu_to_le16(0);
+
+	priv->tx(dev, hdr, sizeof(*hdr) + sizeof(*vdcf), 0);
+}
+
 static int p54_add_interface(struct ieee80211_hw *dev,
 			     struct ieee80211_if_init_conf *conf)
 {
@@ -683,6 +767,7 @@
 
 	p54_set_filter(dev, 0, priv->mac_addr, NULL, 0, 1, 0, 0xF642);
 	p54_set_filter(dev, 0, priv->mac_addr, NULL, 1, 0, 0, 0xF642);
+	p54_set_vdcf(dev);
 
 	switch (conf->type) {
 	case IEEE80211_IF_TYPE_STA:
@@ -712,8 +797,11 @@
 
 static int p54_config(struct ieee80211_hw *dev, struct ieee80211_conf *conf)
 {
-	p54_set_freq(dev, cpu_to_le16(conf->freq));
-	return 0;
+	int ret;
+
+	ret = p54_set_freq(dev, cpu_to_le16(conf->freq));
+	p54_set_vdcf(dev);
+	return ret;
 }
 
 static int p54_config_interface(struct ieee80211_hw *dev, int if_id,
@@ -727,6 +815,26 @@
 	return 0;
 }
 
+static int p54_conf_tx(struct ieee80211_hw *dev, int queue,
+		       const struct ieee80211_tx_queue_params *params)
+{
+	struct p54_common *priv = dev->priv;
+	struct p54_tx_control_vdcf *vdcf;
+
+	vdcf = (struct p54_tx_control_vdcf *)(((struct p54_control_hdr *)
+		((void *)priv->cached_vdcf + priv->tx_hdr_len))->data);
+
+	if ((params) && !((queue < 0) || (queue > 4))) {
+		P54_SET_QUEUE(vdcf->queue[queue], params->aifs,
+			params->cw_min, params->cw_max, params->burst_time);
+	} else
+		return -EINVAL;
+
+	p54_set_vdcf(dev);
+
+	return 0;
+}
+
 static int p54_get_stats(struct ieee80211_hw *dev,
 			 struct ieee80211_low_level_stats *stats)
 {
@@ -737,7 +845,13 @@
 static int p54_get_tx_stats(struct ieee80211_hw *dev,
 			    struct ieee80211_tx_queue_stats *stats)
 {
-	/* TODO.. probably should let lower level deal with this */
+	struct p54_common *priv = dev->priv;
+	unsigned int i;
+
+	for (i = 0; i < dev->queues; i++)
+		memcpy(&stats->data[i], &priv->tx_stats.data[i],
+			sizeof(stats->data[i]));
+
 	return 0;
 }
 
@@ -747,6 +861,7 @@
 	.remove_interface	= p54_remove_interface,
 	.config			= p54_config,
 	.config_interface	= p54_config_interface,
+	.conf_tx		= p54_conf_tx,
 	.get_stats		= p54_get_stats,
 	.get_tx_stats		= p54_get_tx_stats
 };
@@ -784,12 +899,29 @@
 	dev->channel_change_time = 1000;	/* TODO: find actual value */
 	dev->max_rssi = 100;
 
-	dev->queues = 1;
+	/* (hard) queue limits */
+	priv->tx_stats.data[0].limit = 3;
+	priv->tx_stats.data[1].limit = 4;
+	priv->tx_stats.data[2].limit = 3;
+	priv->tx_stats.data[3].limit = 1;
+
+	dev->queues = 4;
 	dev->extra_tx_headroom = sizeof(struct p54_control_hdr) + 4 +
 				 sizeof(struct p54_tx_control_allocdata);
 
+        priv->cached_vdcf = kzalloc(sizeof(struct p54_tx_control_vdcf) +
+              priv->tx_hdr_len + sizeof(struct p54_control_hdr), GFP_KERNEL);
+
+	if (!priv->cached_vdcf) {
+		ieee80211_free_hw(dev);
+		return NULL;
+	}
+
+	p54_init_vdcf(dev);
+
 	for (i = 0; i < 2; i++) {
 		if (ieee80211_register_hwmode(dev, &priv->modes[i])) {
+			kfree(priv->cached_vdcf);
 			ieee80211_free_hw(dev);
 			return NULL;
 		}
@@ -805,6 +937,7 @@
 	kfree(priv->iq_autocal);
 	kfree(priv->output_limit);
 	kfree(priv->curve_data);
+	kfree(priv->cached_vdcf);
 }
 EXPORT_SYMBOL_GPL(p54_free_common);
 

Re: Recent linux-wireless git changes have broken my prism54pci card

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

On Monday 13 August 2007 04:58, Hans de Goede wrote:
> Okay, I still had copies of various git revisions of prism54common.c and .h
> (aka the culprits) on my laptop. I've run some tests again to make sure I
> had the right revisions in mind for the breakage (which I had). I've
> attached 2 patches:
> diff: with this reversed my speed increases 10x and more importantly when
> fully loading the link (using scp from a local non wireless ethernet
> machine) it no longer looses the connection in a couple of seconds
>
Hm, I guess either these changes were wrong or exposed some bugs. Can you 
check what sort of tx rates are being reported in iwconfig before and after 
that change?

> diff2, when I do not reverse this one, it still associates, but it no
> longer receives / or transmits packages. (no dhcp, no ping when manually
> assigning IP's, etc).
>
Not sure.. this patch generally helped things on my hardware. Christian 
Lamparter might have an idea.

Thanks,
-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Recent linux-wireless git changes have broken my prism54pci card

[Chr]

On Monday, 13. August 2007, Michael Wu wrote:
> On Monday 13 August 2007 04:58, Hans de Goede wrote:
> > Okay, I still had copies of various git revisions of prism54common.c and .h
> > (aka the culprits) on my laptop. I've run some tests again to make sure I
> > had the right revisions in mind for the breakage (which I had). I've
> > attached 2 patches:
> > diff: with this reversed my speed increases 10x and more importantly when
> > fully loading the link (using scp from a local non wireless ethernet
> > machine) it no longer looses the connection in a couple of seconds
> >
> Hm, I guess either these changes were wrong or exposed some bugs. Can you 
> check what sort of tx rates are being reported in iwconfig before and after 
> that change?
> 
> > diff2, when I do not reverse this one, it still associates, but it no
> > longer receives / or transmits packages. (no dhcp, no ping when manually
> > assigning IP's, etc).
> >
> Not sure.. this patch generally helped things on my hardware. Christian 
> Lamparter might have an idea.
> 

Well not really, It is "fast" as usual here: 
 
scp user@p54pci-pc:/usr/src/dummyzero ./
dummyzero                                                                                                               100%  236MB   1.8MB/s   02:09

iperf:
[  5] local 192.168.1.247 port 5001 connected with 192.168.1.1 port 56253
[  5]  0.0-240.7 sec    597 MBytes  20.8 Mbits/sec


=> need more data...
 
1. Which p54 firmware do you use? (It "must" be 2.7.0.0 for pci/cardbus)
2. What's your "average" txrate and Link Signal Level / Link Quality with and without the patches.
   (see iwconfig)
3. what brand/type of AP do you have? 
-> what does the beacon frame look like? (or: if you don't have a
wlan sniffer / monitor, just run: iwlist wlanX scan )
4. Can you recompile the mac80211 layer with debug options and look for
something like ethX: STA XX:YY:ZZ:AA:BB:CC Average rate: VVV ... in your syslogs?
5. are they any suspicious dmesg outputs when the "network" stops/dies?

Thanks,
	Chr.

Re: Recent linux-wireless git changes have broken my prism54pci card

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]

Chr wrote:
> On Monday, 13. August 2007, Michael Wu wrote:
>> On Monday 13 August 2007 04:58, Hans de Goede wrote:
>>> Okay, I still had copies of various git revisions of prism54common.c and .h
>>> (aka the culprits) on my laptop. I've run some tests again to make sure I
>>> had the right revisions in mind for the breakage (which I had). I've
>>> attached 2 patches:
>>> diff: with this reversed my speed increases 10x and more importantly when
>>> fully loading the link (using scp from a local non wireless ethernet
>>> machine) it no longer looses the connection in a couple of seconds
>>>
>> Hm, I guess either these changes were wrong or exposed some bugs. Can you 
>> check what sort of tx rates are being reported in iwconfig before and after 
>> that change?
>>
>>> diff2, when I do not reverse this one, it still associates, but it no
>>> longer receives / or transmits packages. (no dhcp, no ping when manually
>>> assigning IP's, etc).
>>>
>> Not sure.. this patch generally helped things on my hardware. Christian 
>> Lamparter might have an idea.
>>
> 
> Well not really, It is "fast" as usual here: 
>  
> scp user@p54pci-pc:/usr/src/dummyzero ./
> dummyzero                                                                                                               100%  236MB   1.8MB/s   02:09
> 
> iperf:
> [  5] local 192.168.1.247 port 5001 connected with 192.168.1.1 port 56253
> [  5]  0.0-240.7 sec    597 MBytes  20.8 Mbits/sec
> 
> 
> => need more data...
>  
> 1. Which p54 firmware do you use? (It "must" be 2.7.0.0 for pci/cardbus)
2.4.12.0, extracted from the window driver for my card, any later version will 
cause the driver to fail to load with: "Error cannot read eeprom!"

> 2. What's your "average" txrate and Link Signal Level / Link Quality with and without the patches.
>    (see iwconfig)
See attached logs

> 3. what brand/type of AP do you have? 
A davolink DV-201AMR its an embedded Linux device using the BCM6348 chipset,

> -> what does the beacon frame look like? (or: if you don't have a
> wlan sniffer / monitor, just run: iwlist wlanX scan )
See logs

> 4. Can you recompile the mac80211 layer with debug options and look for
> something like ethX: STA XX:YY:ZZ:AA:BB:CC Average rate: VVV ... in your syslogs?

See logs

> 5. are they any suspicious dmesg outputs when the "network" stops/dies?
> 

Nope.


I've attached a tarbal with logs the FC7test logs are the logs from the Fedora 
7 test kernel which I normally use, as that works well.

The rest is based on a F-8 test kernel which contains a wireless-dev snapshot 
from 26 jul 2007. The dates are dates of git checkouts from prism54common.{c,h}
the -common one has the speed changes to prism54common.h reversed, because 
otherwise connectivity is lost as explained.

I hope this helps.

Regards,

Hans

[-- Attachment #2: logs.tar.gz --]
[-- Type: application/x-gzip, Size: 1804 bytes --]

Re: Recent linux-wireless git changes have broken my prism54pci card

[Chr]

On Tuesday, 14. August 2007, Hans de Goede wrote:
> >  
> > 1. Which p54 firmware do you use? (It "must" be 2.7.0.0 for pci/cardbus)
> 2.4.12.0, extracted from the window driver for my card, any later version will 
> cause the driver to fail to load with: "Error cannot read eeprom!"

uhh, that's a pity... Well, I'm thinking about to get the FW then. The problem is that I don't have the
necessary equipment "here" for debugging (I am abroad with my old laptop and a minipci prism54 card...)

Anyway, could you please verify that the firmware at 
http://daemonizer.de/prism54/prism54-fw/fw-softmac/2.4.12.0.arm is the same one you have?
Or does it "differ"? 

> 
> > 2. What's your "average" txrate and Link Signal Level / Link Quality with and without the patches.
> >    (see iwconfig)
> See attached logs
> 
Your average speed is in the very low MBit/s and your normal Link Signal Level is only about 
40/100 (~ -80 dbm! ) ?! (The equation is roughly (rssi / 2) - 100 = dbm)

Something is fishy: take a look at the "not working" scan-13-6.  Signal level is about 62/100 
(~ -69 dbm! => much better! Did you move the laptop, or is this high value really reproducible?)

> > 3. what brand/type of AP do you have? 
> A davolink DV-201AMR its an embedded Linux device using the BCM6348 chipset,

hmm, a embedded linux? do you have a ssh/telnet access to the router? Maybe the
syslogs / dmesg gives us a "hint" why it won't connect.  
(BTW: does your router really only support the weak WEP encryptions?)

> 
> > -> what does the beacon frame look like? (or: if you don't have a
> > wlan sniffer / monitor, just run: iwlist wlanX scan )
> See logs
> 
> > 4. Can you recompile the mac80211 layer with debug options and look for
> > something like ethX: STA XX:YY:ZZ:AA:BB:CC Average rate: VVV ... in your syslogs?
> 
> See logs

phy4: not handling 0x02 type control frame.
=> It's a bit strange that you got one, it's probably because of the 2.4.12.0 Firmware.

wlan0: switched to short barker preamble.
Well, that's probably the reason why your connection always "dropped".
could you please replace all "IEEE80211_RATE_CCK_2" in p54common.h
with "IEEE80211_RATE_CCK" and report back?

> 
> > 5. are they any suspicious dmesg outputs when the "network" stops/dies?
> > 
> 
> Nope.
Yep, none!


I'll see if I can post you a "debug" driver, when I'm back at home. I'm afraid it's not
possible right now...

> 
> I've attached a tarbal with logs the FC7test logs are the logs from the Fedora 
> 7 test kernel which I normally use, as that works well.
> 
> The rest is based on a F-8 test kernel which contains a wireless-dev snapshot 
> from 26 jul 2007. The dates are dates of git checkouts from prism54common.{c,h}
> the -common one has the speed changes to prism54common.h reversed, because 
> otherwise connectivity is lost as explained.
> 
k. Do you have another wifi card that can perform wifi sniffs? (just as an option)

> I hope this helps.
> 
> Regards,
> 
> Hans
> 

Thanks,
	Chr

Re: Recent linux-wireless git changes have broken my prism54pci card

[Chr]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Tuesday, 14. August 2007, Hans de Goede wrote:

Hans,

Any updates? Or are you on holiday?

I've prepared a patch, which should theoretically lower the excessive retry count.

however I don't think it will magically solve anything...


OT: Michael/anyone else:

1. Do you know why the rate algorithm (rc80211_simple) starts with the lowest speed?
  or is this really only a p54 bug?
 
2. Is there any way to get a station aid (in ap mode) and dtim period
 without lots of castings or "new variables" in struct ieee80211_tx_control?
 I really need them for AP mode (yes, I have a "proof of concept" for it,
 the hardest thing was to compile hostapd ;-) ).

Thanks,
	Chr.



[-- Attachment #2: p54-tx-status-is-not-always-necessary.diff --]
[-- Type: text/x-diff, Size: 2156 bytes --]

diff -Nurp a/drivers/net/wireless/p54common.c b/drivers/net/wireless/p54common.c
--- a/drivers/net/wireless/p54common.c	2007-08-18 20:44:04.000000000 +0200
+++ b/drivers/net/wireless/p54common.c	2007-08-20 02:20:53.000000000 +0200
@@ -315,9 +315,11 @@ static void p54_rx_frame_sent(struct iee
 	struct p54_control_hdr *hdr = (struct p54_control_hdr *) skb->data;
 	struct p54_frame_sent_hdr *payload = (struct p54_frame_sent_hdr *) hdr->data;
 	struct sk_buff *entry = (struct sk_buff *) priv->tx_queue.next;
+	struct p54_control_hdr *entry_hdr;
+	struct p54_tx_control_allocdata *entry_data;
 	u32 addr = le32_to_cpu(hdr->req_id) - 0x70;
 	struct memrecord *range = NULL;
-	u32 freed = 0;
+	u32 freed = 0, pad = 0;
 	u32 last_addr = priv->rx_start;
 
 	while (entry != (struct sk_buff *)&priv->tx_queue) {
@@ -339,15 +341,27 @@ static void p54_rx_frame_sent(struct iee
 			memcpy(&status.control, range->control,
 			       sizeof(status.control));
 			kfree(range->control);
-			if (!payload->status)
-				status.flags |= IEEE80211_TX_STATUS_ACK;
-			else
-				status.excessive_retries = 1;
-			status.retry_count = payload->retries - 1;
-			status.ack_signal = le16_to_cpu(payload->ack_rssi);
-			skb_pull(entry, sizeof(*hdr) + sizeof(struct p54_tx_control_allocdata));
 			priv->tx_stats.data[status.control.queue].len--;
-			ieee80211_tx_status_irqsafe(dev, entry, &status);
+
+			if (status.control.flags & IEEE80211_TXCTL_REQ_TX_STATUS) {
+				entry_hdr = (struct p54_control_hdr *) entry->data;
+				entry_data = (struct p54_tx_control_allocdata *) entry_hdr->data;
+				if (entry_hdr->magic1 == cpu_to_le16(0x4010))
+					pad = entry_data->align[0];
+				else
+					pad = 0;
+
+				if (!payload->status)
+					status.flags |= IEEE80211_TX_STATUS_ACK;
+				else
+					status.excessive_retries = 1;
+				status.retry_count = payload->retries - 1;
+				status.ack_signal = le16_to_cpu(payload->ack_rssi);
+				skb_pull(entry, sizeof(*hdr) + pad + sizeof(*entry_data));
+				ieee80211_tx_status_irqsafe(dev, entry, &status);
+			} else
+                                dev_kfree_skb_irq(entry);
+
 			break;
 		} else
 			last_addr = range->end_addr;

Re: Recent linux-wireless git changes have broken my prism54pci card

[Larry Finger]

Chr wrote:
> On Tuesday, 14. August 2007, Hans de Goede wrote:
> 
> Hans,
> 
> Any updates? Or are you on holiday?
> 
> I've prepared a patch, which should theoretically lower the excessive retry count.
> 
> however I don't think it will magically solve anything...
> 
> 
> OT: Michael/anyone else:
> 
> 1. Do you know why the rate algorithm (rc80211_simple) starts with the lowest speed?
>   or is this really only a p54 bug?

I cannot answer any other of your questions, but rc80211_simple starting at 1 Mbs is not a bug, it 
is a feature. The reason is that particular speed offers the greatest chance of authenticating and 
associating. It used to start at the highest rate and many systems would give up trying to connect 
before the rate was dropped to a point at which they could communicate. If the connection is really 
capable of higher speeds, it gets there very quickly.

Larry

Re: Recent linux-wireless git changes have broken my prism54pci card

[Hans de Goede]

Chr wrote:
> On Tuesday, 14. August 2007, Hans de Goede wrote:
> 
> Hans,
> 
> Any updates?

Erm, did you not receive my long mail with all kinda logs attached in logs.tar.gz?

 > Or are you on holiday?

Nope

> 
> I've prepared a patch, which should theoretically lower the excessive retry count.
> 
> however I don't think it will magically solve anything...
> 

Erm, I'm awfully busy, still I want to get this resolved! So I'll make time to 
test things as necessary, but could you first look at the logs I send and then 
confirm (or deny) that this pathc might help.

Regards,

Hans

Re: Recent linux-wireless git changes have broken my prism54pci card

[Chr]

On Monday, 20. August 2007, Hans de Goede wrote:
> Chr wrote:
> > On Tuesday, 14. August 2007, Hans de Goede wrote:
> > 
> > Hans,
> > 
> > Any updates?
> 
> Erm, did you not receive my long mail with all kinda logs attached in logs.tar.gz?
> 
yes I got the logs... but maybe you haven't seen my reply:
http://www.spinics.net/lists/linux-wireless/msg04658.html

>  > Or are you on holiday?
> 
> Nope
> 
> > 
> > I've prepared a patch, which should theoretically lower the excessive retry count.
> > 
> > however I don't think it will magically solve anything...
> > 
> 
> Erm, I'm awfully busy, still I want to get this resolved! So I'll make time to 
> test things as necessary, but could you first look at the logs I send and then 
> confirm (or deny) that this pathc might help.
> 

me too... but the logs don't carry much useful information inside:

"pyh2: not handling 0x02 type control frame" (could be the FW)
"wlan0: duplicate address detected!" (never seen this before... IPv6?)
"wlan0: switched to short barker preamble" (nothing to be scared.)

and of course: the low signal with any driver, except 13-6...

Thanks,
	Chr.

Re: Recent linux-wireless git changes have broken my prism54pci card

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On Mon, 2007-08-20 at 13:51 +0200, Chr wrote:

> "pyh2: not handling 0x02 type control frame" (could be the FW)

The driver, I assume.

> "wlan0: duplicate address detected!" (never seen this before... IPv6?)

Yes, IPv6, caused by the multicast bug.

> "wlan0: switched to short barker preamble" (nothing to be scared.)

Fairly new, but yeah, nothing to worry.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Recent linux-wireless git changes have broken my prism54pci card

[Chr]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On Monday, 20. August 2007, Johannes Berg wrote:
> On Mon, 2007-08-20 at 13:51 +0200, Chr wrote:
> 
> > "pyh2: not handling 0x02 type control frame" (could be the FW)
> 
> The driver, I assume.
No, it's really the firmware. I've "finally" tried the 2.4.12.0 and got the same messages... 
But, I didn't get them with 2.7.0.0 or 2.5.2.0.

Moreover, because of some "unknown reason" 2.4.12.0 does not work very well with
my isl3880 chip, I cannot tx/rx any QoS data frame... And probably, it's because the
feature is not supported by the firmware...  

I made two patches:

the p54-pull-padding.diff should finally fix the rate algorithm for "everyone" and as 
a bonus for developers: it adds a printk for the firmware revision p54 is using.
(If noone complains within a week, I'll write a official patch post for it...)

p54-remove-qos.diff (must be applied on top of p54-pull-padding.diff) is _only_ for
Hans...  It removes/reverts QoS/WME/WMM/IEEE802.11e features.

Thanks,
	Chr

    




[-- Attachment #2: p54-pull-padding.diff --]
[-- Type: text/x-diff, Size: 5122 bytes --]

diff -Nurp a/drivers/net/wireless/p54common.c b/drivers/net/wireless/p54common.c
--- a/drivers/net/wireless/p54common.c	2007-08-18 20:44:04.000000000 +0200
+++ b/drivers/net/wireless/p54common.c	2007-08-20 23:06:46.000000000 +0200
@@ -48,6 +48,7 @@ void p54_parse_firmware(struct ieee80211
 	while (bootrec->data <= end_data &&
 	       (bootrec->data + le32_to_cpu(bootrec->len)) <= end_data) {
 		u32 code = le32_to_cpu(bootrec->code);
+		size_t len = le32_to_cpu(bootrec->len);
 		switch (code) {
 		case BR_CODE_COMPONENT_ID:
 			switch (be32_to_cpu(*bootrec->data)) {
@@ -69,6 +70,9 @@ void p54_parse_firmware(struct ieee80211
 			}
 			break;
 		case BR_CODE_COMPONENT_VERSION:
+			priv->fw_version = kmalloc(len * 4, GFP_KERNEL);
+			snprintf(priv->fw_version, len * 4, "%s", (char*)bootrec->data);
+			printk(KERN_INFO "p54: firmware version %s\n", priv->fw_version);
 			break;
 		case BR_CODE_DESCR:
 			priv->rx_start = le32_to_cpu(bootrec->data[1]);
@@ -86,7 +90,7 @@ void p54_parse_firmware(struct ieee80211
 		default:
 			break;
 		}
-		bootrec = (struct bootrec *)&bootrec->data[le32_to_cpu(bootrec->len)];
+		bootrec = (struct bootrec *)&bootrec->data[len];
 	}
 }
 EXPORT_SYMBOL_GPL(p54_parse_firmware);
@@ -315,9 +319,11 @@ static void p54_rx_frame_sent(struct iee
 	struct p54_control_hdr *hdr = (struct p54_control_hdr *) skb->data;
 	struct p54_frame_sent_hdr *payload = (struct p54_frame_sent_hdr *) hdr->data;
 	struct sk_buff *entry = (struct sk_buff *) priv->tx_queue.next;
+	struct p54_control_hdr *entry_hdr;
+	struct p54_tx_control_allocdata *entry_data;
 	u32 addr = le32_to_cpu(hdr->req_id) - 0x70;
 	struct memrecord *range = NULL;
-	u32 freed = 0;
+	u32 freed = 0, pad = 0;
 	u32 last_addr = priv->rx_start;
 
 	while (entry != (struct sk_buff *)&priv->tx_queue) {
@@ -339,15 +345,25 @@ static void p54_rx_frame_sent(struct iee
 			memcpy(&status.control, range->control,
 			       sizeof(status.control));
 			kfree(range->control);
-			if (!payload->status)
-				status.flags |= IEEE80211_TX_STATUS_ACK;
-			else
-				status.excessive_retries = 1;
-			status.retry_count = payload->retries - 1;
-			status.ack_signal = le16_to_cpu(payload->ack_rssi);
-			skb_pull(entry, sizeof(*hdr) + sizeof(struct p54_tx_control_allocdata));
 			priv->tx_stats.data[status.control.queue].len--;
+
+			entry_hdr = (struct p54_control_hdr *) entry->data;
+			entry_data = (struct p54_tx_control_allocdata *) entry_hdr->data;
+			if (entry_hdr->magic1 & cpu_to_le16(0x4000))
+				pad = entry_data->align[0];
+			else 
+				pad = 0;
+			if (status.control.flags & IEEE80211_TXCTL_NO_ACK) {
+				if (!(payload->status & 0x01))
+					status.flags |= IEEE80211_TX_STATUS_ACK;
+				else
+					status.excessive_retries = 1;
+				status.retry_count = payload->retries - 1;
+				status.ack_signal = le16_to_cpu(payload->ack_rssi);
+			}
+			skb_pull(entry, sizeof(*hdr) + pad + sizeof(*entry_data));
 			ieee80211_tx_status_irqsafe(dev, entry, &status);
+
 			break;
 		} else
 			last_addr = range->end_addr;
@@ -486,6 +502,7 @@ static int p54_tx(struct ieee80211_hw *d
 		ieee80211_stop_queue(dev, control->queue);
 
 	padding = (unsigned long)(skb->data - (sizeof(*hdr) + sizeof(*txhdr))) & 3;
+
 	len = skb->len;
 
 	control_copy = kmalloc(sizeof(*control), GFP_ATOMIC);
@@ -496,10 +513,12 @@ static int p54_tx(struct ieee80211_hw *d
 			skb_push(skb, sizeof(*txhdr) + padding);
 	hdr = (struct p54_control_hdr *) skb_push(skb, sizeof(*hdr));
 
-	if (padding)
-		hdr->magic1 = cpu_to_le16(0x4010);
-	else
-		hdr->magic1 = cpu_to_le16(0x0010);
+	if (padding) {
+		hdr->magic1 = cpu_to_le16(0x4000);
+		txhdr->align[0] = padding;
+	} else
+		hdr->magic1 = cpu_to_le16(0x0000);
+
 	hdr->len = cpu_to_le16(len);
 	hdr->type = (control->flags & IEEE80211_TXCTL_NO_ACK) ? 0 : cpu_to_le16(1);
 	hdr->retry1 = hdr->retry2 = control->retry_limit;
@@ -515,6 +534,9 @@ static int p54_tx(struct ieee80211_hw *d
 		rate |= 0x40;
 	else if (control->flags & IEEE80211_TXCTL_USE_CTS_PROTECT)
 		rate |= 0x20;
+	else 
+		hdr->magic1 |= cpu_to_le16(0x0010);
+
 	memset(txhdr->rateset, rate, 8);
 	txhdr->wep_key_present = 0;
 	txhdr->wep_key_len = 0;
@@ -525,8 +547,6 @@ static int p54_tx(struct ieee80211_hw *d
 	txhdr->output_power = 0x7f; // HW Maximum
 	txhdr->magic5 = (control->flags & IEEE80211_TXCTL_NO_ACK) ?
 		0 : ((rate > 0x3) ? cpu_to_le32(0x33) : cpu_to_le32(0x23));
-	if (padding)
-		txhdr->align[0] = padding;
 
 	priv->tx(dev, hdr, skb->len, 0);
 	return 0;
@@ -938,6 +958,7 @@ void p54_free_common(struct ieee80211_hw
 	kfree(priv->output_limit);
 	kfree(priv->curve_data);
 	kfree(priv->cached_vdcf);
+	kfree(priv->fw_version);
 }
 EXPORT_SYMBOL_GPL(p54_free_common);
 
diff -Nurp a/drivers/net/wireless/p54.h b/drivers/net/wireless/p54.h
--- a/drivers/net/wireless/p54.h	2007-08-18 20:44:04.000000000 +0200
+++ b/drivers/net/wireless/p54.h	2007-08-20 23:05:45.000000000 +0200
@@ -60,6 +60,7 @@ struct p54_common {
 	struct pda_pa_curve_data *curve_data;
 	__le16 rxhw;
 	u8 version;
+	char *fw_version;
 	unsigned int tx_hdr_len;
 	void *cached_vdcf;
 	/* FIXME: this channels/modes/rates stuff sucks */

[-- Attachment #3: p54-remove-qos.diff --]
[-- Type: text/x-diff, Size: 1947 bytes --]

diff -Nurp a/drivers/net/wireless/p54common.c b/drivers/net/wireless/p54common.c
--- a/drivers/net/wireless/p54common.c	2007-08-20 23:06:46.000000000 +0200
+++ b/drivers/net/wireless/p54common.c	2007-08-20 23:41:07.000000000 +0200
@@ -345,7 +345,7 @@ static void p54_rx_frame_sent(struct iee
 			memcpy(&status.control, range->control,
 			       sizeof(status.control));
 			kfree(range->control);
-			priv->tx_stats.data[status.control.queue].len--;
+			priv->tx_stats.data[0].len--;
 
 			entry_hdr = (struct p54_control_hdr *) entry->data;
 			entry_data = (struct p54_tx_control_allocdata *) entry_hdr->data;
@@ -493,13 +493,13 @@ static int p54_tx(struct ieee80211_hw *d
 	size_t padding, len;
 	u8 rate;
 
-	current_queue = &priv->tx_stats.data[control->queue];
+	current_queue = &priv->tx_stats.data[0];
 	if (unlikely(current_queue->len > current_queue->limit))
 		return NETDEV_TX_BUSY;
 	current_queue->len++;
 	current_queue->count++;
 	if (current_queue->len == current_queue->limit)
-		ieee80211_stop_queue(dev, control->queue);
+		ieee80211_stop_queue(dev, 0);
 
 	padding = (unsigned long)(skb->data - (sizeof(*hdr) + sizeof(*txhdr))) & 3;
 
@@ -540,7 +540,7 @@ static int p54_tx(struct ieee80211_hw *d
 	memset(txhdr->rateset, rate, 8);
 	txhdr->wep_key_present = 0;
 	txhdr->wep_key_len = 0;
-	txhdr->frame_type = cpu_to_le32(control->queue + 4);
+	txhdr->frame_type = 4;
 	txhdr->magic4 = 0;
 	txhdr->antenna = (control->antenna_sel_tx == 0) ?
 		2 : control->antenna_sel_tx - 1;
@@ -920,12 +920,9 @@ struct ieee80211_hw *p54_init_common(siz
 	dev->max_rssi = 100;
 
 	/* (hard) queue limits */
-	priv->tx_stats.data[0].limit = 3;
-	priv->tx_stats.data[1].limit = 4;
-	priv->tx_stats.data[2].limit = 3;
-	priv->tx_stats.data[3].limit = 1;
+	priv->tx_stats.data[0].limit = 4;
 
-	dev->queues = 4;
+	dev->queues = 1;
 	dev->extra_tx_headroom = sizeof(struct p54_control_hdr) + 4 +
 				 sizeof(struct p54_tx_control_allocdata);
 

Re: Recent linux-wireless git changes have broken my prism54pci card

[Hans de Goede]

Chr wrote:
> On Monday, 20. August 2007, Hans de Goede wrote:
>> Chr wrote:
>>> On Tuesday, 14. August 2007, Hans de Goede wrote:
>>>
>>> Hans,
>>>
>>> Any updates?
>> Erm, did you not receive my long mail with all kinda logs attached in logs.tar.gz?
>>
> yes I got the logs... but maybe you haven't seen my reply:
> http://www.spinics.net/lists/linux-wireless/msg04658.html
> 

I indeed didn't see that, probably because I'm not on the list. Here are some 
answers to your questions:

 > > > 1. Which p54 firmware do you use? (It "must" be 2.7.0.0 for pci/cardbus)
 > > 2.4.12.0, extracted from the window driver for my card, any later version
 > > will cause the driver to fail to load with: "Error cannot read eeprom!"

 > uhh, that's a pity... Well, I'm thinking about to get the FW then. The
 > problem is that I don't have the necessary equipment "here" for debugging (I
 > am abroad with my old laptop and a minipci prism54 card...)
 >
 > Anyway, could you please verify that the firmware at
 > http://daemonizer.de/prism54/prism54-fw/fw-softmac/2.4.12.0.arm is the same
 > one you have? Or does it "differ"?

I'm at work atm, but I did verify that my 2.4.12.0 matched 2.4.12.0 available 
from the firmware site linked to from the prism54 wiki.

I can verify that your link matches too if you want, but it porbably will.


 >
 > > 2. What's your "average" txrate and Link Signal Level / Link Quality with 
and without the patches.
 > >    (see iwconfig)
 > See attached logs
 >
Your average speed is in the very low MBit/s and your normal Link Signal Level 
is only about
40/100 (~ -80 dbm! ) ?! (The equation is roughly (rssi / 2) - 100 = dbm)

Something is fishy: take a look at the "not working" scan-13-6.  Signal level 
is about 62/100
(~ -69 dbm! => much better! Did you move the laptop, or is this high value 
really reproducible?)

I'm afraid that my reception quality varies wildly. I don't know why, I'll try 
to configure a different channel on the AP the next time I do some testing.

 > > 3. what brand/type of AP do you have?
 > A davolink DV-201AMR its an embedded Linux device using the BCM6348 chipset,

hmm, a embedded linux? do you have a ssh/telnet access to the router? Maybe the
syslogs / dmesg gives us a "hint" why it won't connect.

I'm afraid its provisioned by my ISP , and I only have access to some crippled 
web interface, I really need to kick the ISP and ask them to give me the source 
and stuff, as they are oblidged under the GPL.

(BTW: does your router really only support the weak WEP encryptions?)
No it also supports 128 bit, but when first settings things up I had trouble 
getting that working. This has been working reasonably for me, so I didn't 
change it. The firmware can also do wpa, but the webinterface I'm stuck behind 
doesn't allow this (GRRRR).

 > k. Do you have another wifi card that can perform wifi sniffs? (just as an
 > option)

I can get my hands on a full mac prism pci card, but I'll first try your patches.

----

Replying to other mail in one go:

Chr wrote:
 > I made two patches:
 >
 > the p54-pull-padding.diff should finally fix the rate algorithm for 
"everyone" and as
 > a bonus for developers: it adds a printk for the firmware revision p54 is using.
 >

Cool I'll give this a try tonight, I really wanted to try it sooner, but ...

 > p54-remove-qos.diff (must be applied on top of p54-pull-padding.diff) is 
_only_ for
 > Hans...  It removes/reverts QoS/WME/WMM/IEEE802.11e features.
 >

Hmm, could this be made conditionally on the firmware revision perhaps? I don't 
like having to patch my kernel every update, and more importantly, my card is a 
pretty popular el cheapo sitecom, which are stacked by the dozen by every 
computershop in town, so it would be nice if this worked out of the box.

I'll try to see if 2.5.2.0 will work with my card, I think I've tried before 
but you never know, will 2.5.2.0 be good enough for the QoS/WME/WMM/IEEE802.11e 
features?

Maybe it would be an idea to dump the eeprom from the driver with the 2.4.12.0 
firmware, and then fake the eeprom in the driver using newer firmware to see if 
the eeprom reading is the only problem with newer firmware and my card ?

Thanks & Regards,

Hans

Re: Recent linux-wireless git changes have broken my prism54pci card

[Chr]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

On Thursday, 23. August 2007, Hans de Goede wrote:
> 
> I'm afraid that my reception quality varies wildly. I don't know why, I'll try 
> to configure a different channel on the AP the next time I do some testing.
> 
Ok, maybe someone has cooked a meal in a microwave oven, or
something like that...
 
> 
> Replying to other mail in one go:
> 
> Chr wrote:
>  > I made two patches:
>  >
>  > the p54-pull-padding.diff should finally fix the rate algorithm for 
> "everyone" and as
>  > a bonus for developers: it adds a printk for the firmware revision p54 is using.
>  >
> 
> Cool I'll give this a try tonight, I really wanted to try it sooner, but ...
> 
k, I'll wait ;-)

BTW: There's already a newer version of it... see attachment.

> 
> Hmm, could this be made conditionally on the firmware revision perhaps? I don't 
> like having to patch my kernel every update, and more importantly, my card is a 
> pretty popular el cheapo sitecom, which are stacked by the dozen by every 
> computershop in town, so it would be nice if this worked out of the box.
> 
Of course! This patch is just a "test" patch, because you never know if it's "this" or "that"...
Probably, it's only necessary to hardcode "txhdr->frame_type = 4;" in p54_tx again. 

> I'll try to see if 2.5.2.0 will work with my card, I think I've tried before 
> but you never know, will 2.5.2.0 be good enough for the QoS/WME/WMM/IEEE802.11e 
> features?

AFAIK Michael uses this revision too and he would not have merged the QoS patch, if it
was completly unusable or faulty... So I think 2.5.2 will be fine, if it works with your card.
(However, 2.7.0.0 is recommend, because it's one of the few FWs for which we have
additional debugging and testing facilities...)

> Maybe it would be an idea to dump the eeprom from the driver with the 2.4.12.0 
> firmware, and then fake the eeprom in the driver using newer firmware to see if 
> the eeprom reading is the only problem with newer firmware and my card ?

Hmm, I don't think that the firmware somehow changes the eeprom.

Thanks,
	Chr.

[-- Attachment #2: p54-pull-padding.diff --]
[-- Type: text/x-diff, Size: 5073 bytes --]

diff -Nurp a/drivers/net/wireless/p54common.c b/drivers/net/wireless/p54common.c
--- a/drivers/net/wireless/p54common.c	2007-08-18 20:44:04.000000000 +0200
+++ b/drivers/net/wireless/p54common.c	2007-08-23 15:50:12.000000000 +0200
@@ -48,6 +48,7 @@ void p54_parse_firmware(struct ieee80211
 	while (bootrec->data <= end_data &&
 	       (bootrec->data + le32_to_cpu(bootrec->len)) <= end_data) {
 		u32 code = le32_to_cpu(bootrec->code);
+		size_t len = le32_to_cpu(bootrec->len);
 		switch (code) {
 		case BR_CODE_COMPONENT_ID:
 			switch (be32_to_cpu(*bootrec->data)) {
@@ -69,6 +70,9 @@ void p54_parse_firmware(struct ieee80211
 			}
 			break;
 		case BR_CODE_COMPONENT_VERSION:
+			priv->fw_version = kmalloc(len * 4, GFP_KERNEL);
+			snprintf(priv->fw_version, len * 4, "%s", (char*)bootrec->data);
+			printk(KERN_INFO "p54: firmware version %s\n", priv->fw_version);
 			break;
 		case BR_CODE_DESCR:
 			priv->rx_start = le32_to_cpu(bootrec->data[1]);
@@ -86,7 +90,7 @@ void p54_parse_firmware(struct ieee80211
 		default:
 			break;
 		}
-		bootrec = (struct bootrec *)&bootrec->data[le32_to_cpu(bootrec->len)];
+		bootrec = (struct bootrec *)&bootrec->data[len];
 	}
 }
 EXPORT_SYMBOL_GPL(p54_parse_firmware);
@@ -315,9 +319,11 @@ static void p54_rx_frame_sent(struct iee
 	struct p54_control_hdr *hdr = (struct p54_control_hdr *) skb->data;
 	struct p54_frame_sent_hdr *payload = (struct p54_frame_sent_hdr *) hdr->data;
 	struct sk_buff *entry = (struct sk_buff *) priv->tx_queue.next;
+	struct p54_control_hdr *entry_hdr;
+	struct p54_tx_control_allocdata *entry_data;
 	u32 addr = le32_to_cpu(hdr->req_id) - 0x70;
 	struct memrecord *range = NULL;
-	u32 freed = 0;
+	u32 freed = 0, pad = 0;
 	u32 last_addr = priv->rx_start;
 
 	while (entry != (struct sk_buff *)&priv->tx_queue) {
@@ -339,15 +345,26 @@ static void p54_rx_frame_sent(struct iee
 			memcpy(&status.control, range->control,
 			       sizeof(status.control));
 			kfree(range->control);
-			if (!payload->status)
-				status.flags |= IEEE80211_TX_STATUS_ACK;
-			else
-				status.excessive_retries = 1;
+			priv->tx_stats.data[status.control.queue].len--;
+
+			entry_hdr = (struct p54_control_hdr *) entry->data;
+			entry_data = (struct p54_tx_control_allocdata *) entry_hdr->data;
+			if (entry_hdr->magic1 & cpu_to_le16(0x4000))
+				pad = entry_data->align[0];
+			else 
+				pad = 0;
+
+			if (!status.control.flags & IEEE80211_TXCTL_NO_ACK) {
+				if (!(payload->status & 0x01))
+					status.flags |= IEEE80211_TX_STATUS_ACK;
+				else
+					status.excessive_retries = 1;
+			}
 			status.retry_count = payload->retries - 1;
 			status.ack_signal = le16_to_cpu(payload->ack_rssi);
-			skb_pull(entry, sizeof(*hdr) + sizeof(struct p54_tx_control_allocdata));
-			priv->tx_stats.data[status.control.queue].len--;
+			skb_pull(entry, sizeof(*hdr) + pad + sizeof(*entry_data));
 			ieee80211_tx_status_irqsafe(dev, entry, &status);
+
 			break;
 		} else
 			last_addr = range->end_addr;
@@ -486,6 +503,7 @@ static int p54_tx(struct ieee80211_hw *d
 		ieee80211_stop_queue(dev, control->queue);
 
 	padding = (unsigned long)(skb->data - (sizeof(*hdr) + sizeof(*txhdr))) & 3;
+
 	len = skb->len;
 
 	control_copy = kmalloc(sizeof(*control), GFP_ATOMIC);
@@ -496,10 +514,12 @@ static int p54_tx(struct ieee80211_hw *d
 			skb_push(skb, sizeof(*txhdr) + padding);
 	hdr = (struct p54_control_hdr *) skb_push(skb, sizeof(*hdr));
 
-	if (padding)
-		hdr->magic1 = cpu_to_le16(0x4010);
-	else
-		hdr->magic1 = cpu_to_le16(0x0010);
+	if (padding) {
+		hdr->magic1 = cpu_to_le16(0x4000);
+		txhdr->align[0] = padding;
+	} else
+		hdr->magic1 = cpu_to_le16(0x0000);
+
 	hdr->len = cpu_to_le16(len);
 	hdr->type = (control->flags & IEEE80211_TXCTL_NO_ACK) ? 0 : cpu_to_le16(1);
 	hdr->retry1 = hdr->retry2 = control->retry_limit;
@@ -515,6 +535,9 @@ static int p54_tx(struct ieee80211_hw *d
 		rate |= 0x40;
 	else if (control->flags & IEEE80211_TXCTL_USE_CTS_PROTECT)
 		rate |= 0x20;
+	else 
+		hdr->magic1 |= cpu_to_le16(0x0010);
+
 	memset(txhdr->rateset, rate, 8);
 	txhdr->wep_key_present = 0;
 	txhdr->wep_key_len = 0;
@@ -525,8 +548,6 @@ static int p54_tx(struct ieee80211_hw *d
 	txhdr->output_power = 0x7f; // HW Maximum
 	txhdr->magic5 = (control->flags & IEEE80211_TXCTL_NO_ACK) ?
 		0 : ((rate > 0x3) ? cpu_to_le32(0x33) : cpu_to_le32(0x23));
-	if (padding)
-		txhdr->align[0] = padding;
 
 	priv->tx(dev, hdr, skb->len, 0);
 	return 0;
@@ -938,6 +959,7 @@ void p54_free_common(struct ieee80211_hw
 	kfree(priv->output_limit);
 	kfree(priv->curve_data);
 	kfree(priv->cached_vdcf);
+	kfree(priv->fw_version);
 }
 EXPORT_SYMBOL_GPL(p54_free_common);
 
diff -Nurp a/drivers/net/wireless/p54.h b/drivers/net/wireless/p54.h
--- a/drivers/net/wireless/p54.h	2007-08-18 20:44:04.000000000 +0200
+++ b/drivers/net/wireless/p54.h	2007-08-20 23:05:45.000000000 +0200
@@ -60,6 +60,7 @@ struct p54_common {
 	struct pda_pa_curve_data *curve_data;
 	__le16 rxhw;
 	u8 version;
+	char *fw_version;
 	unsigned int tx_hdr_len;
 	void *cached_vdcf;
 	/* FIXME: this channels/modes/rates stuff sucks */

Re: Recent linux-wireless git changes have broken my prism54pci card

[Hans de Goede]

Chr wrote:
> On Thursday, 23. August 2007, Hans de Goede wrote:
>> Maybe it would be an idea to dump the eeprom from the driver with the 2.4.12.0 
>> firmware, and then fake the eeprom in the driver using newer firmware to see if 
>> the eeprom reading is the only problem with newer firmware and my card ?
> 
> Hmm, I don't think that the firmware somehow changes the eeprom.
> 

I think you misunderstood me. The driver fails to load when using newer 
firmware with a "can not read eeprom" error. So I have the idea to add a couple 
of printk's printing all the important bits from the eeprom using the 2.4.12.0 
firmware, then modify the driver to hardcode these bits from the eeprom in to 
the driver and then try newer firmware with the driver with the hardcoded bits 
in. This way I want to see if the reading of the eeprom is the only problem, or 
if there are other problems too when using newer firmware. Does this sound like 
a plan or is it a waste of time?

Regards,

Hans

Re: Recent linux-wireless git changes have broken my prism54pci card

[Hans de Goede]

Chr wrote:
> On Thursday, 23. August 2007, Hans de Goede wrote:
>> I'm afraid that my reception quality varies wildly. I don't know why, I'll try 
>> to configure a different channel on the AP the next time I do some testing.
>>
> Ok, maybe someone has cooked a meal in a microwave oven, or
> something like that...
>  
>> Replying to other mail in one go:
>>
>> Chr wrote:
>>  > I made two patches:
>>  >
>>  > the p54-pull-padding.diff should finally fix the rate algorithm for 
>> "everyone" and as
>>  > a bonus for developers: it adds a printk for the firmware revision p54 is using.
>>  >
>>
>> Cool I'll give this a try tonight, I really wanted to try it sooner, but ...
>>
> k, I'll wait ;-)
> 
> BTW: There's already a newer version of it... see attachment.
> 

Okay, I've given this a test together with your remvoe QOS and other advanced 
features patch and it seems to work well (as good as the versiono of the driver 
I'm currently using).

I've tried using all other firmwares from here:
http://jbnote.free.fr/prism54usb/data/firmwares/

But none of them work, except for the (identical) 2.4.12.0 one. the others 
either don't boot or can't read the eeprom.

Regards,

Hans

Re: Recent linux-wireless git changes have broken my prism54pci card

[Chr]

On Thursday, 23. August 2007, Hans de Goede wrote:
> 
> Okay, I've given this a test together with your remvoe QOS and other advanced 
> features patch and it seems to work well (as good as the versiono of the driver 
> I'm currently using).
> 
> I've tried using all other firmwares from here:
> http://jbnote.free.fr/prism54usb/data/firmwares/
> 
> But none of them work, except for the (identical) 2.4.12.0 one. the others 
> either don't boot or can't read the eeprom.
> 

Thanks for testing! Let's see if I can write something over the weekend.
Since you have said in your previous post that your Sitecom adapter is cheap
and common ... can you please tell me which one is it?

Regards,
	Chr.

Re: Recent linux-wireless git changes have broken my prism54pci card

[Hans de Goede]

Chr wrote:
> On Thursday, 23. August 2007, Hans de Goede wrote:
>> Okay, I've given this a test together with your remvoe QOS and other advanced 
>> features patch and it seems to work well (as good as the versiono of the driver 
>> I'm currently using).
>>
>> I've tried using all other firmwares from here:
>> http://jbnote.free.fr/prism54usb/data/firmwares/
>>
>> But none of them work, except for the (identical) 2.4.12.0 one. the others 
>> either don't boot or can't read the eeprom.
>>
> 
> Thanks for testing! Let's see if I can write something over the weekend.
> Since you have said in your previous post that your Sitecom adapter is cheap
> and common ... can you please tell me which one is it?
> 

Its a Sitecom WL-140 V2 (small letters at the bottom right of the front of the 
box) aka the Sitecom Nitro XM 140G+

Note I think that the V2 is important to get the same one as mine, otherwise 
you probably get an older fullmac version (if they still sell that anyware).

Regards,

Hans

Re: Recent linux-wireless git changes have broken my prism54pci card

[Chr]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Friday, 24. August 2007, Hans de Goede wrote:
> Chr wrote:
> 
> Its a Sitecom WL-140 V2 (small letters at the bottom right of the front of the 
> box) aka the Sitecom Nitro XM 140G+
> 
> Note I think that the V2 is important to get the same one as mine, otherwise 
> you probably get an older fullmac version (if they still sell that anyware).
> 

Here we are:

series:
p54-pull-padding2.diff
p54-support-older-firmwares.diff

Signed-off will follow on friday/saturday... Michael, any complains?

Regards,
	Chr.

[-- Attachment #2: p54-pull-padding2.diff --]
[-- Type: text/x-diff, Size: 3109 bytes --]

diff -Nurp a/drivers/net/wireless/p54common.c b/drivers/net/wireless/p54common.c
--- a/drivers/net/wireless/p54common.c	2007-08-18 20:44:04.000000000 +0200
+++ b/drivers/net/wireless/p54common.c	2007-08-28 21:08:00.000000000 +0200
@@ -283,12 +283,13 @@ static void p54_rx_data(struct ieee80211
 	struct ieee80211_rx_status rx_status = {0};
 	u16 freq = le16_to_cpu(hdr->freq);
 
-	rx_status.ssi = hdr->rssi;	/* TODO: check this */
+	rx_status.ssi = hdr->rssi;
 	rx_status.rate = hdr->rate & 0x1f; /* report short preambles & CCK too */
 	rx_status.channel = freq == 2484 ? 14 : (freq - 2407)/5;
 	rx_status.freq = freq;
 	rx_status.phymode = MODE_IEEE80211G;
 	rx_status.antenna = hdr->antenna;
+	rx_status.mactime = le64_to_cpu(hdr->timestamp);
 
 	skb_pull(skb, sizeof(*hdr));
 	skb_trim(skb, le16_to_cpu(hdr->len));
@@ -324,6 +325,9 @@ static void p54_rx_frame_sent(struct iee
 		range = (struct memrecord *)&entry->cb;
 		if (range->start_addr == addr) {
 			struct ieee80211_tx_status status = {{0}};
+			struct p54_control_hdr *entry_hdr;
+			struct p54_tx_control_allocdata *entry_data;
+			int pad = 0;
 
 			if (entry->next != (struct sk_buff *)&priv->tx_queue)
 				freed = ((struct memrecord *)&entry->next->cb)->start_addr - last_addr;
@@ -339,14 +343,22 @@ static void p54_rx_frame_sent(struct iee
 			memcpy(&status.control, range->control,
 			       sizeof(status.control));
 			kfree(range->control);
-			if (!payload->status)
-				status.flags |= IEEE80211_TX_STATUS_ACK;
-			else
-				status.excessive_retries = 1;
+			priv->tx_stats.data[status.control.queue].len--;
+
+			entry_hdr = (struct p54_control_hdr *) entry->data;
+			entry_data = (struct p54_tx_control_allocdata *) entry_hdr->data;
+			if ((entry_hdr->magic1 & cpu_to_le16(0x4000)) != 0)
+				pad = entry_data->align[0];
+
+			if (!status.control.flags & IEEE80211_TXCTL_NO_ACK) {
+				if (!(payload->status & 0x01))
+					status.flags |= IEEE80211_TX_STATUS_ACK;
+				else
+					status.excessive_retries = 1;
+			}
 			status.retry_count = payload->retries - 1;
 			status.ack_signal = le16_to_cpu(payload->ack_rssi);
-			skb_pull(entry, sizeof(*hdr) + sizeof(struct p54_tx_control_allocdata));
-			priv->tx_stats.data[status.control.queue].len--;
+			skb_pull(entry, sizeof(*hdr) + pad + sizeof(*entry_data));
 			ieee80211_tx_status_irqsafe(dev, entry, &status);
 			break;
 		} else
@@ -897,7 +909,7 @@ struct ieee80211_hw *p54_init_common(siz
 		    IEEE80211_HW_DATA_NULLFUNC_ACK; /* TODO: check */
 		    /* IEEE80211_HW_MONITOR_DURING_OPER FIXME: check */
 	dev->channel_change_time = 1000;	/* TODO: find actual value */
-	dev->max_rssi = 100;
+	dev->max_rssi = 127;
 
 	/* (hard) queue limits */
 	priv->tx_stats.data[0].limit = 3;
diff -Nurp a/drivers/net/wireless/p54common.h b/drivers/net/wireless/p54common.h
--- a/drivers/net/wireless/p54common.h	2007-08-18 20:44:04.000000000 +0200
+++ b/drivers/net/wireless/p54common.h	2007-08-28 19:53:13.000000000 +0200
@@ -168,7 +168,7 @@ struct p54_rx_hdr {
 	u8 antenna;
 	u8 rate;
 	u8 rssi;
-	u8 padding;
+	u8 quality;
 	u16 unknown2;
 	__le64 timestamp;
 	u8 data[0];

[-- Attachment #3: p54-support-older-firmwares.diff --]
[-- Type: text/x-diff, Size: 3633 bytes --]

diff -Nurp a/drivers/net/wireless/p54common.c b/drivers/net/wireless/p54common.c
--- a/drivers/net/wireless/p54common.c	2007-08-28 21:08:00.000000000 +0200
+++ b/drivers/net/wireless/p54common.c	2007-08-28 21:11:06.000000000 +0200
@@ -30,9 +30,12 @@ MODULE_ALIAS("prism54common");
 void p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw)
 {
 	struct p54_common *priv = dev->priv;
+	struct bootrec_exp_if *exp_if;
 	struct bootrec *bootrec;
 	u32 *data = (u32 *)fw->data;
 	u32 *end_data = (u32 *)fw->data + (fw->size >> 2);
+	size_t len;
+	int i;
 
 	if (priv->rx_start)
 		return;
@@ -46,7 +49,7 @@ void p54_parse_firmware(struct ieee80211
 	bootrec = (struct bootrec *) data;
 
 	while (bootrec->data <= end_data &&
-	       (bootrec->data + le32_to_cpu(bootrec->len)) <= end_data) {
+	       (bootrec->data + (len = le32_to_cpu(bootrec->len))) <= end_data) {
 		u32 code = le32_to_cpu(bootrec->code);
 		switch (code) {
 		case BR_CODE_COMPONENT_ID:
@@ -69,6 +72,11 @@ void p54_parse_firmware(struct ieee80211
 			}
 			break;
 		case BR_CODE_COMPONENT_VERSION:
+			priv->fw_version = kmalloc(len * 4, GFP_KERNEL);
+			if (!priv->fw_version)
+				return ;
+			snprintf(priv->fw_version, len * 4, "%s",
+				(unsigned char*)bootrec->data);
 			break;
 		case BR_CODE_DESCR:
 			priv->rx_start = le32_to_cpu(bootrec->data[1]);
@@ -76,6 +84,10 @@ void p54_parse_firmware(struct ieee80211
 			priv->rx_end = le32_to_cpu(bootrec->data[2]) - 0x3500;
 			break;
 		case BR_CODE_EXPOSED_IF:
+			exp_if = (struct bootrec_exp_if *) bootrec->data;
+			for (i = 0; i < (len * sizeof(*exp_if) / 4); i++)
+				if (exp_if[i].if_id == 0x1a)
+					priv->fw_variant = le16_to_cpu(exp_if[i].variant);
 			break;
 		case BR_CODE_DEPENDENT_IF:
 			break;
@@ -86,8 +98,25 @@ void p54_parse_firmware(struct ieee80211
 		default:
 			break;
 		}
-		bootrec = (struct bootrec *)&bootrec->data[le32_to_cpu(bootrec->len)];
+		bootrec = (struct bootrec *)&bootrec->data[len];
+	}
+
+	if (priv->fw_version)
+		printk(KERN_INFO "p54: Rev %s - Softmac protocol %x\n",
+			priv->fw_version, priv->fw_variant);
+		
+	/* Firmware supports QoS, enable it! */
+	if (priv->fw_variant >= 0x300) {
+		/* queue limits */
+		priv->tx_stats.data[0].limit = 3;
+		priv->tx_stats.data[1].limit = 4;
+		priv->tx_stats.data[2].limit = 3;
+		priv->tx_stats.data[3].limit = 1;
+		
+		dev->queues = 4;
 	}
+
+
 }
 EXPORT_SYMBOL_GPL(p54_parse_firmware);
 
@@ -911,13 +940,9 @@ struct ieee80211_hw *p54_init_common(siz
 	dev->channel_change_time = 1000;	/* TODO: find actual value */
 	dev->max_rssi = 127;
 
-	/* (hard) queue limits */
-	priv->tx_stats.data[0].limit = 3;
-	priv->tx_stats.data[1].limit = 4;
-	priv->tx_stats.data[2].limit = 3;
-	priv->tx_stats.data[3].limit = 1;
+	priv->tx_stats.data[0].limit = 10;
+	dev->queues = 1;
 
-	dev->queues = 4;
 	dev->extra_tx_headroom = sizeof(struct p54_control_hdr) + 4 +
 				 sizeof(struct p54_tx_control_allocdata);
 
@@ -950,6 +975,7 @@ void p54_free_common(struct ieee80211_hw
 	kfree(priv->output_limit);
 	kfree(priv->curve_data);
 	kfree(priv->cached_vdcf);
+	kfree(priv->fw_version);
 }
 EXPORT_SYMBOL_GPL(p54_free_common);
 
diff -Nurp a/drivers/net/wireless/p54.h b/drivers/net/wireless/p54.h
--- a/drivers/net/wireless/p54.h	2007-08-28 12:00:54.000000000 +0200
+++ b/drivers/net/wireless/p54.h	2007-08-28 20:17:37.000000000 +0200
@@ -62,6 +62,8 @@ struct p54_common {
 	u8 version;
 	unsigned int tx_hdr_len;
 	void *cached_vdcf;
+	u8 *fw_version;
+	__le16 fw_variant;
 	/* FIXME: this channels/modes/rates stuff sucks */
 	struct ieee80211_channel channels[14];
 	struct ieee80211_rate rates[12];

Re: Recent linux-wireless git changes have broken my prism54pci card

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On Tuesday 28 August 2007 15:32, Chr wrote:
> Here we are:
>
> series:
> p54-pull-padding2.diff
Looks okay, but it seems to do more than just account for padding. I'm okay 
with those changes too.

> p54-support-older-firmwares.diff
The new information pulled from parsing the firmware isn't used anywhere but 
in this function.. no need to keep that information in the private structure.

Thanks,
-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Recent linux-wireless git changes have broken my prism54pci card

[Chr]

On Thursday, 30. August 2007, Michael Wu wrote:
> On Tuesday 28 August 2007 15:32, Chr wrote:
> > Here we are:
> >
> > series:
> > p54-pull-padding2.diff
> Looks okay, but it seems to do more than just account for padding. I'm okay 
> with those changes too.
> 
Ok!

> > p54-support-older-firmwares.diff
> The new information pulled from parsing the firmware isn't used anywhere but 
> in this function.. no need to keep that information in the private structure.
> 
Yes, the firmware version string could be freed right after the printk...
but I would like to keep the fw_variant for "further" patches, since the
softmac protocol has changed a bit throughout 2.4 - 2.13.1 firmwares. 

> Thanks,
> -Michael Wu


Thanks,
	Chr. 

[PATCH 1/2] p54: various fixes

[Chr]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

From: Christian Lamparter <chunkeey@web.de>

This patch should finally fix the mysterious "stuck at 1 mbps" and numerous of
"lost" ACKs (very important for the not yet released p54 AP addon).

The patch also includes a bunch of useful one liners that did not make it in the tree yet.

Signed-off-by: Christian Lamparter <chunkeey@web.de>
---

[-- Attachment #2: p54-forgotten-patch4.diff --]
[-- Type: text/x-diff, Size: 3145 bytes --]

diff -Nurp a/drivers/net/wireless/p54common.c b/drivers/net/wireless/p54common.c
--- a/drivers/net/wireless/p54common.c	2007-08-31 21:56:42.000000000 +0200
+++ b/drivers/net/wireless/p54common.c	2007-08-31 21:57:29.000000000 +0200
@@ -283,12 +283,13 @@ static void p54_rx_data(struct ieee80211
 	struct ieee80211_rx_status rx_status = {0};
 	u16 freq = le16_to_cpu(hdr->freq);
 
-	rx_status.ssi = hdr->rssi;	/* TODO: check this */
+	rx_status.ssi = hdr->rssi;
 	rx_status.rate = hdr->rate & 0x1f; /* report short preambles & CCK too */
 	rx_status.channel = freq == 2484 ? 14 : (freq - 2407)/5;
 	rx_status.freq = freq;
 	rx_status.phymode = MODE_IEEE80211G;
 	rx_status.antenna = hdr->antenna;
+	rx_status.mactime = le64_to_cpu(hdr->timestamp);
 
 	skb_pull(skb, sizeof(*hdr));
 	skb_trim(skb, le16_to_cpu(hdr->len));
@@ -324,6 +325,9 @@ static void p54_rx_frame_sent(struct iee
 		range = (struct memrecord *)&entry->cb;
 		if (range->start_addr == addr) {
 			struct ieee80211_tx_status status = {{0}};
+			struct p54_control_hdr *entry_hdr;
+			struct p54_tx_control_allocdata *entry_data;
+			int pad = 0;
 
 			if (entry->next != (struct sk_buff *)&priv->tx_queue)
 				freed = ((struct memrecord *)&entry->next->cb)->start_addr - last_addr;
@@ -339,14 +343,22 @@ static void p54_rx_frame_sent(struct iee
 			memcpy(&status.control, range->control,
 			       sizeof(status.control));
 			kfree(range->control);
-			if (!payload->status)
-				status.flags |= IEEE80211_TX_STATUS_ACK;
-			else
-				status.excessive_retries = 1;
+			priv->tx_stats.data[status.control.queue].len--;
+
+			entry_hdr = (struct p54_control_hdr *) entry->data;
+			entry_data = (struct p54_tx_control_allocdata *) entry_hdr->data;
+			if ((entry_hdr->magic1 & cpu_to_le16(0x4000)) != 0)
+				pad = entry_data->align[0];
+
+			if (!status.control.flags & IEEE80211_TXCTL_NO_ACK) {
+				if (!(payload->status & 0x01))
+					status.flags |= IEEE80211_TX_STATUS_ACK;
+				else
+					status.excessive_retries = 1;
+			}
 			status.retry_count = payload->retries - 1;
 			status.ack_signal = le16_to_cpu(payload->ack_rssi);
-			skb_pull(entry, sizeof(*hdr) + sizeof(struct p54_tx_control_allocdata));
-			priv->tx_stats.data[status.control.queue].len--;
+			skb_pull(entry, sizeof(*hdr) + pad + sizeof(*entry_data));
 			ieee80211_tx_status_irqsafe(dev, entry, &status);
 			break;
 		} else
@@ -895,7 +907,7 @@ struct ieee80211_hw *p54_init_common(siz
 		    IEEE80211_HW_RX_INCLUDES_FCS |
 		    IEEE80211_HW_WEP_INCLUDE_IV;
 	dev->channel_change_time = 1000;	/* TODO: find actual value */
-	dev->max_rssi = 100;
+	dev->max_rssi = 127;
 
 	/* (hard) queue limits */
 	priv->tx_stats.data[0].limit = 3;
diff -Nurp a/drivers/net/wireless/p54common.h b/drivers/net/wireless/p54common.h
--- a/drivers/net/wireless/p54common.h	2007-08-18 20:44:04.000000000 +0200
+++ b/drivers/net/wireless/p54common.h	2007-08-28 19:53:13.000000000 +0200
@@ -168,7 +168,7 @@ struct p54_rx_hdr {
 	u8 antenna;
 	u8 rate;
 	u8 rssi;
-	u8 padding;
+	u8 quality;
 	u16 unknown2;
 	__le64 timestamp;
 	u8 data[0];

[PATCH 2/2] p54: disable QoS on older firmwares

[Chr]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

From: Christian Lamparter <chunkeey@web.de>

This patch fixes a regression with older (pre 2.5.2.0) firmwares, that don't
support the QoS queues yet...

Thanks to Hans de Goede <j.w.r.degoede@hhs.nl> for reporting and debugging it.

Signed-off-by: Christian Lamparter <chunkeey@web.de>
---

[-- Attachment #2: p54-support-older-firmwares3.diff --]
[-- Type: text/x-diff, Size: 3427 bytes --]

diff -Nurp a/drivers/net/wireless/p54common.c b/drivers/net/wireless/p54common.c
--- a/drivers/net/wireless/p54common.c	2007-08-31 21:57:29.000000000 +0200
+++ b/drivers/net/wireless/p54common.c	2007-08-31 21:57:56.000000000 +0200
@@ -30,9 +30,13 @@ MODULE_ALIAS("prism54common");
 void p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw)
 {
 	struct p54_common *priv = dev->priv;
+	struct bootrec_exp_if *exp_if;
 	struct bootrec *bootrec;
 	u32 *data = (u32 *)fw->data;
 	u32 *end_data = (u32 *)fw->data + (fw->size >> 2);
+	u8 *fw_version = NULL;
+	size_t len;
+	int i;
 
 	if (priv->rx_start)
 		return;
@@ -46,7 +50,7 @@ void p54_parse_firmware(struct ieee80211
 	bootrec = (struct bootrec *) data;
 
 	while (bootrec->data <= end_data &&
-	       (bootrec->data + le32_to_cpu(bootrec->len)) <= end_data) {
+	       (bootrec->data + (len = le32_to_cpu(bootrec->len))) <= end_data) {
 		u32 code = le32_to_cpu(bootrec->code);
 		switch (code) {
 		case BR_CODE_COMPONENT_ID:
@@ -69,6 +73,11 @@ void p54_parse_firmware(struct ieee80211
 			}
 			break;
 		case BR_CODE_COMPONENT_VERSION:
+			fw_version = kmalloc(len * 4, GFP_KERNEL);
+			if (!fw_version)
+				return ;
+			snprintf(fw_version, len * 4, "%s",
+				(unsigned char*)bootrec->data);
 			break;
 		case BR_CODE_DESCR:
 			priv->rx_start = le32_to_cpu(bootrec->data[1]);
@@ -76,6 +85,10 @@ void p54_parse_firmware(struct ieee80211
 			priv->rx_end = le32_to_cpu(bootrec->data[2]) - 0x3500;
 			break;
 		case BR_CODE_EXPOSED_IF:
+			exp_if = (struct bootrec_exp_if *) bootrec->data;
+			for (i = 0; i < (len * sizeof(*exp_if) / 4); i++)
+				if (exp_if[i].if_id == 0x1a)
+					priv->fw_var = le16_to_cpu(exp_if[i].variant);
 			break;
 		case BR_CODE_DEPENDENT_IF:
 			break;
@@ -86,8 +99,26 @@ void p54_parse_firmware(struct ieee80211
 		default:
 			break;
 		}
-		bootrec = (struct bootrec *)&bootrec->data[le32_to_cpu(bootrec->len)];
+		bootrec = (struct bootrec *)&bootrec->data[len];
+	}
+
+	if (fw_version)
+		printk(KERN_INFO "p54: FW Rev %s - Softmac protocol %x.%x\n",
+			fw_version, priv->fw_var >> 8, priv->fw_var & 0xff);
+	kfree(fw_version);
+
+	/* Firmware supports QoS, use it! */
+	if (priv->fw_var >= 0x300) {
+		/* queue limits */
+		priv->tx_stats.data[0].limit = 3;
+		priv->tx_stats.data[1].limit = 4;
+		priv->tx_stats.data[2].limit = 3;
+		priv->tx_stats.data[3].limit = 1;
+		
+		dev->queues = 4;
 	}
+
+
 }
 EXPORT_SYMBOL_GPL(p54_parse_firmware);
 
@@ -909,13 +940,9 @@ struct ieee80211_hw *p54_init_common(siz
 	dev->channel_change_time = 1000;	/* TODO: find actual value */
 	dev->max_rssi = 127;
 
-	/* (hard) queue limits */
-	priv->tx_stats.data[0].limit = 3;
-	priv->tx_stats.data[1].limit = 4;
-	priv->tx_stats.data[2].limit = 3;
-	priv->tx_stats.data[3].limit = 1;
+	priv->tx_stats.data[0].limit = 5;
+	dev->queues = 1;
 
-	dev->queues = 4;
 	dev->extra_tx_headroom = sizeof(struct p54_control_hdr) + 4 +
 				 sizeof(struct p54_tx_control_allocdata);
 
diff -Nurp a/drivers/net/wireless/p54.h b/drivers/net/wireless/p54.h
--- a/drivers/net/wireless/p54.h	2007-08-28 12:00:54.000000000 +0200
+++ b/drivers/net/wireless/p54.h	2007-08-31 21:28:37.000000000 +0200
@@ -62,6 +62,7 @@ struct p54_common {
 	u8 version;
 	unsigned int tx_hdr_len;
 	void *cached_vdcf;
+	__le16 fw_var;
 	/* FIXME: this channels/modes/rates stuff sucks */
 	struct ieee80211_channel channels[14];
 	struct ieee80211_rate rates[12];

Re: [PATCH 2/2] p54: disable QoS on older firmwares

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

On Friday 31 August 2007 17:27, Chr wrote:
> This patch fixes a regression with older (pre 2.5.2.0) firmwares, that
> don't support the QoS queues yet...
>
Why bother allocating a temporary buffer for firmware version string? Just 
keep a pointer to where it's located. (unless it's not null terminated..)

There's two extra unnecessary lines added to the end of p54_parse_firmware.

Thanks,
-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/2 v2] p54: disable QoS on older firmwares

[Chr]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

From: Christian Lamparter <chunkeey@web.de>

This patch fixes a regression with older (pre 2.5.2.0) firmwares, that don't
support the QoS queues yet...

Thanks to Hans de Goede <j.w.r.degoede@hhs.nl> for reporting and debugging it.

Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
>Why bother allocating a temporary buffer for firmware version string? Just 
>keep a pointer to where it's located. (unless it's not null terminated..)
Ok
 

[-- Attachment #2: p54-support-older-firmwares4.diff --]
[-- Type: text/x-diff, Size: 3381 bytes --]

diff -Nurp a/drivers/net/wireless/p54common.c b/drivers/net/wireless/p54common.c
--- a/drivers/net/wireless/p54common.c	2007-08-31 21:57:29.000000000 +0200
+++ b/drivers/net/wireless/p54common.c	2007-09-01 18:27:10.000000000 +0200
@@ -30,9 +30,13 @@ MODULE_ALIAS("prism54common");
 void p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw)
 {
 	struct p54_common *priv = dev->priv;
+	struct bootrec_exp_if *exp_if;
 	struct bootrec *bootrec;
 	u32 *data = (u32 *)fw->data;
 	u32 *end_data = (u32 *)fw->data + (fw->size >> 2);
+	u8 *fw_version = NULL;
+	size_t len;
+	int i;
 
 	if (priv->rx_start)
 		return;
@@ -46,7 +50,7 @@ void p54_parse_firmware(struct ieee80211
 	bootrec = (struct bootrec *) data;
 
 	while (bootrec->data <= end_data &&
-	       (bootrec->data + le32_to_cpu(bootrec->len)) <= end_data) {
+	       (bootrec->data + (len = le32_to_cpu(bootrec->len))) <= end_data) {
 		u32 code = le32_to_cpu(bootrec->code);
 		switch (code) {
 		case BR_CODE_COMPONENT_ID:
@@ -69,6 +73,9 @@ void p54_parse_firmware(struct ieee80211
 			}
 			break;
 		case BR_CODE_COMPONENT_VERSION:
+			/* 24 bytes should be enough for all firmwares */
+			if (strnlen((unsigned char*)bootrec->data, 24) < 24)
+				fw_version = (unsigned char*)bootrec->data;
 			break;
 		case BR_CODE_DESCR:
 			priv->rx_start = le32_to_cpu(bootrec->data[1]);
@@ -76,6 +83,10 @@ void p54_parse_firmware(struct ieee80211
 			priv->rx_end = le32_to_cpu(bootrec->data[2]) - 0x3500;
 			break;
 		case BR_CODE_EXPOSED_IF:
+			exp_if = (struct bootrec_exp_if *) bootrec->data;
+			for (i = 0; i < (len * sizeof(*exp_if) / 4); i++)
+				if (exp_if[i].if_id == 0x1a)
+					priv->fw_var = le16_to_cpu(exp_if[i].variant);
 			break;
 		case BR_CODE_DEPENDENT_IF:
 			break;
@@ -86,7 +97,20 @@ void p54_parse_firmware(struct ieee80211
 		default:
 			break;
 		}
-		bootrec = (struct bootrec *)&bootrec->data[le32_to_cpu(bootrec->len)];
+		bootrec = (struct bootrec *)&bootrec->data[len];
+	}
+
+	if (fw_version)
+		printk(KERN_INFO "p54: FW rev %s - Softmac protocol %x.%x\n",
+			fw_version, priv->fw_var >> 8, priv->fw_var & 0xff);
+
+	if (priv->fw_var >= 0x300) {
+		/* Firmware supports QoS, use it! */
+		priv->tx_stats.data[0].limit = 3;
+		priv->tx_stats.data[1].limit = 4;
+		priv->tx_stats.data[2].limit = 3;
+		priv->tx_stats.data[3].limit = 1;
+		dev->queues = 4;
 	}
 }
 EXPORT_SYMBOL_GPL(p54_parse_firmware);
@@ -909,13 +933,9 @@ struct ieee80211_hw *p54_init_common(siz
 	dev->channel_change_time = 1000;	/* TODO: find actual value */
 	dev->max_rssi = 127;
 
-	/* (hard) queue limits */
-	priv->tx_stats.data[0].limit = 3;
-	priv->tx_stats.data[1].limit = 4;
-	priv->tx_stats.data[2].limit = 3;
-	priv->tx_stats.data[3].limit = 1;
+	priv->tx_stats.data[0].limit = 5;
+	dev->queues = 1;
 
-	dev->queues = 4;
 	dev->extra_tx_headroom = sizeof(struct p54_control_hdr) + 4 +
 				 sizeof(struct p54_tx_control_allocdata);
 
diff -Nurp a/drivers/net/wireless/p54.h b/drivers/net/wireless/p54.h
--- a/drivers/net/wireless/p54.h	2007-08-28 12:00:54.000000000 +0200
+++ b/drivers/net/wireless/p54.h	2007-09-01 18:04:51.000000000 +0200
@@ -62,6 +62,7 @@ struct p54_common {
 	u8 version;
 	unsigned int tx_hdr_len;
 	void *cached_vdcf;
+	unsigned int fw_var;
 	/* FIXME: this channels/modes/rates stuff sucks */
 	struct ieee80211_channel channels[14];
 	struct ieee80211_rate rates[12];

Re: Recent linux-wireless git changes have broken my prism54pci card

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

On Mon, 2007-08-13 at 07:46 +0100, Andy Green wrote:
> Somebody in the thread at some point said:
> 
> > Darn, is there a gitweb of the wireless-dev git anywhere else, I'm
> > pretty sure I can find those patches pretty quick again.
> 
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=summary

Actually, you want to look at
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=shortlog;h=everything or one of the other branches.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]