From min.liu at neusoft.com  Wed Jul  1 05:11:46 2009
From: min.liu at neusoft.com (liumin)
Date: Wed, 01 Jul 2009 17:11:46 +0800
Subject: libertas keep logging and could not work properly
Message-ID: <1246439506.5763.44.camel@ubuntu.ubuntu-domain>

hi,
   I am using wicd network manager manage wifi ,using sd8686.The problem
is when i start machine ,thing below will happened,I am not sure of the
reason,someone could help me?


libertas: Command 6 timed out
libertas: requeueing command 6 due to timeout (#1)
libertas: Command 6 timed out
libertas: requeueing command 6 due to timeout (#2)
libertas: Command 6 timed out
libertas: requeueing command 6 due to timeout (#3)
libertas: Command 6 timed out
libertas: requeueing command 6 due to timeout (#4)
warning: ignoring exception org.freedesktop.DBus.Error.NoReply: Did not
receive a reply. Possible causes include: the remote application did not
send a reply, the message bus security policy blocked the reply, the
reply timeout expired, or the network connection was broken.
libertas: Command 6 timed out
libertas: requeueing command 6 due to timeout (#5)
libertas: Command 6 timed out
libertas: requeueing command 6 due to timeout (#6)
warning: ignoring exception org.freedesktop.DBus.Error.NoReply: Did not
receive a reply. Possible causes include: the remote application did not
send a reply, the message bus security policy blocked the reply, the
reply timeout expired, or the network connection was broken.
libertas: Command 6 timed out
libertas: requeueing command 6 due to timeout (#7)
libertas: Command 6 timed out
libertas: requeueing command 6 due to timeout (#8)
libertas: Command 6 timed out
libertas: requeueing command 6 due to timeout (#9)
go into -item.c finalize**************
go out of -item.c finalize************
libertas: Command 6 timed out
libertas: requeueing command 6 due to timeout (#10)
libertas: Command 6 timed out
libertas: Excessive timeouts submitting command 6
libertas: PREP_CMD: command 0x0006 failed: -110
libertas: SCAN_CMD failed
libertas: Command 10 timed out
libertas: requeueing command 10 due to timeout (#1)
libertas: Command 10 timed out
libertas: requeueing command 10 due to timeout (#2)
libertas: Command 10 timed out
libertas: requeueing command 10 due to timeout (#3)
libertas: Command 10 timed out
libertas: requeueing command 10 due to timeout (#4)
libertas: Command 10 timed out
libertas: requeueing command 10 due to timeout (#5)
libertas: Command 10 timed out
libertas: requeueing command 10 due to timeout (#6)
libertas: Command 10 timed out
libertas: requeueing command 10 due to timeout (#7)
libertas: Command 10 timed out
libertas: requeueing command 10 due to timeout (#8)
libertas: Command 10 timed out
libertas: requeueing command 10 due to timeout (#9)
libertas: Command 10 timed out
libertas: requeueing command 10 due to timeout (#10)
libertas: Command 10 timed out
libertas: Excessive timeouts submitting command 10
libertas: Command 1e timed out
libertas: requeueing command 1e due to timeout (#1)
libertas: Command 1e timed out

---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------



From dcbw at redhat.com  Wed Jul  1 08:50:53 2009
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 01 Jul 2009 08:50:53 -0400
Subject: libertas keep logging and could not work properly
In-Reply-To: <1246439506.5763.44.camel@ubuntu.ubuntu-domain>
References: <1246439506.5763.44.camel@ubuntu.ubuntu-domain>
Message-ID: <1246452653.12198.52.camel@localhost.localdomain>

On Wed, 2009-07-01 at 17:11 +0800, liumin wrote:
> hi,
>    I am using wicd network manager manage wifi ,using sd8686.The problem
> is when i start machine ,thing below will happened,I am not sure of the
> reason,someone could help me?

We'll need more log than that; the firmware seems to be wedged and we'd
need to find out what command actually wedged it.  You may want to load
the libertas driver with "modprobe libertas libertas_debug=0x43a7" and
retry to get more logging.  Assuming, of course, your kernel is built
with CONFIG_LIBERTAS_DEBUG=y.

Dan

> 
> libertas: Command 6 timed out
> libertas: requeueing command 6 due to timeout (#1)
> libertas: Command 6 timed out
> libertas: requeueing command 6 due to timeout (#2)
> libertas: Command 6 timed out
> libertas: requeueing command 6 due to timeout (#3)
> libertas: Command 6 timed out
> libertas: requeueing command 6 due to timeout (#4)
> warning: ignoring exception org.freedesktop.DBus.Error.NoReply: Did not
> receive a reply. Possible causes include: the remote application did not
> send a reply, the message bus security policy blocked the reply, the
> reply timeout expired, or the network connection was broken.
> libertas: Command 6 timed out
> libertas: requeueing command 6 due to timeout (#5)
> libertas: Command 6 timed out
> libertas: requeueing command 6 due to timeout (#6)
> warning: ignoring exception org.freedesktop.DBus.Error.NoReply: Did not
> receive a reply. Possible causes include: the remote application did not
> send a reply, the message bus security policy blocked the reply, the
> reply timeout expired, or the network connection was broken.
> libertas: Command 6 timed out
> libertas: requeueing command 6 due to timeout (#7)
> libertas: Command 6 timed out
> libertas: requeueing command 6 due to timeout (#8)
> libertas: Command 6 timed out
> libertas: requeueing command 6 due to timeout (#9)
> go into -item.c finalize**************
> go out of -item.c finalize************
> libertas: Command 6 timed out
> libertas: requeueing command 6 due to timeout (#10)
> libertas: Command 6 timed out
> libertas: Excessive timeouts submitting command 6
> libertas: PREP_CMD: command 0x0006 failed: -110
> libertas: SCAN_CMD failed
> libertas: Command 10 timed out
> libertas: requeueing command 10 due to timeout (#1)
> libertas: Command 10 timed out
> libertas: requeueing command 10 due to timeout (#2)
> libertas: Command 10 timed out
> libertas: requeueing command 10 due to timeout (#3)
> libertas: Command 10 timed out
> libertas: requeueing command 10 due to timeout (#4)
> libertas: Command 10 timed out
> libertas: requeueing command 10 due to timeout (#5)
> libertas: Command 10 timed out
> libertas: requeueing command 10 due to timeout (#6)
> libertas: Command 10 timed out
> libertas: requeueing command 10 due to timeout (#7)
> libertas: Command 10 timed out
> libertas: requeueing command 10 due to timeout (#8)
> libertas: Command 10 timed out
> libertas: requeueing command 10 due to timeout (#9)
> libertas: Command 10 timed out
> libertas: requeueing command 10 due to timeout (#10)
> libertas: Command 10 timed out
> libertas: Excessive timeouts submitting command 10
> libertas: Command 1e timed out
> libertas: requeueing command 1e due to timeout (#1)
> libertas: Command 1e timed out
> 
> ---------------------------------------------------------------------------------------------------
> Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
> is intended only for the use of the intended recipient and may be confidential and/or privileged of 
> Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
> not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
> is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
> immediately notify the sender by return e-mail, and delete the original message and all copies from 
> your system. Thank you. 
> ---------------------------------------------------------------------------------------------------
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From chugalug at jcl.wotan.cz  Thu Jul  2 13:38:53 2009
From: chugalug at jcl.wotan.cz (Hajdukiewicz)
Date: Thu, 02 Jul 2009 16:38:53 -0100
Subject: How to Make a Woman Orgasm Using This 111 Simple Technique
Message-ID: <1246552716pridefully@jcl.wotan.cz>

How to Make a Woman Ogrgasm Using This 1 Smiple Technique www. med19. com. Clintonite Stsaabs Obama Supporter


From quadrisect at tonnaer.nl  Thu Jul  2 22:41:09 2009
From: quadrisect at tonnaer.nl (Sienko)
Date: Fri, 03 Jul 2009 02:41:09 +0000
Subject: Cunnilingus Orgasms - Give eHr Unfdorgettable Cunnilingus Orgasms
	With These Tips Now
Message-ID: <ANUrMnifoJWlIj3NOhCzs@tonnaer.nl>

Cunnilingus Orgaasms - Give Her Unforgettable Cunnilingus Orgasms With Tehse Tips Now www. gen65. net. Court Sieds With Student In Bush T-Shirt lFap


From herbert at gondor.apana.org.au  Fri Jul  3 03:55:30 2009
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Fri, 3 Jul 2009 15:55:30 +0800
Subject: [PATCH 1/4] net: skb_orphan on dev_hard_start_xmit
In-Reply-To: <20090602.171418.186096253.davem@davemloft.net>
Message-ID: <20090703075530.GA25190@gondor.apana.org.au>

David Miller <davem at davemloft.net> wrote:
>
>> I think I'll do this in the driver for now, and let's revisit doing it 
>> generically later?
> 
> That might be the best course of action for the time being.
> This whole area is a rat's nest.

Calling skb_orphan like this should be forbidden.  Apart from the
problems already raised, it is a sign that the driver is trying to
paper over a more serious issue of not cleaning up skb's timely.

Yes skb_orphan will work for the cases where calling the skb
destructor allows forward progress, but for the cases where you
really need to the skb to be freed (e.g., iSCSI or Xen), this
simply doesn't work.

So anytime someone tries to propose such a solution it is a sign
that they have bigger problems.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From fideist at lacpa.org.lb  Fri Jul  3 10:22:44 2009
From: fideist at lacpa.org.lb (Smulik Minichiello)
Date: Fri, 03 Jul 2009 13:22:44 -0100
Subject: Never Be Fooled Ever Again! How To Know Iff Your Women Is Fakking Her
	Orgasm!
Message-ID: <306094572027@lacpa.org.lb>

Never Be Fooled Evzer Again! How To Know If Your Women Is Faking Her Ograsm! www. gen88. net. Police: 10-year-old Ark. oboy takes bus, leads officers on chase along Ark. highway


From davem at davemloft.net  Fri Jul  3 23:02:54 2009
From: davem at davemloft.net (David Miller)
Date: Fri, 03 Jul 2009 20:02:54 -0700 (PDT)
Subject: [PATCH 1/4] net: skb_orphan on dev_hard_start_xmit
In-Reply-To: <20090703075530.GA25190@gondor.apana.org.au>
References: <20090602.171418.186096253.davem@davemloft.net>
	<20090703075530.GA25190@gondor.apana.org.au>
Message-ID: <20090703.200254.172991821.davem@davemloft.net>

From: Herbert Xu <herbert at gondor.apana.org.au>
Date: Fri, 3 Jul 2009 15:55:30 +0800

> Calling skb_orphan like this should be forbidden.  Apart from the
> problems already raised, it is a sign that the driver is trying to
> paper over a more serious issue of not cleaning up skb's timely.
> 
> Yes skb_orphan will work for the cases where calling the skb
> destructor allows forward progress, but for the cases where you
> really need to the skb to be freed (e.g., iSCSI or Xen), this
> simply doesn't work.
> 
> So anytime someone tries to propose such a solution it is a sign
> that they have bigger problems.

Agreed, but alas we are foaming at the mouth until we have a truly
usable alternative.

In particular the case of handling a device without usable TX
completion event indications is still quite troublesome.


From herbert at gondor.apana.org.au  Fri Jul  3 23:08:30 2009
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Sat, 4 Jul 2009 11:08:30 +0800
Subject: [PATCH 1/4] net: skb_orphan on dev_hard_start_xmit
In-Reply-To: <20090703.200254.172991821.davem@davemloft.net>
References: <20090602.171418.186096253.davem@davemloft.net>
	<20090703075530.GA25190@gondor.apana.org.au>
	<20090703.200254.172991821.davem@davemloft.net>
Message-ID: <20090704030830.GA32442@gondor.apana.org.au>

On Fri, Jul 03, 2009 at 08:02:54PM -0700, David Miller wrote:
>
> In particular the case of handling a device without usable TX
> completion event indications is still quite troublesome.

Which particular devices do you have in mind?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From davem at davemloft.net  Fri Jul  3 23:13:47 2009
From: davem at davemloft.net (David Miller)
Date: Fri, 03 Jul 2009 20:13:47 -0700 (PDT)
Subject: [PATCH 1/4] net: skb_orphan on dev_hard_start_xmit
In-Reply-To: <20090704030830.GA32442@gondor.apana.org.au>
References: <20090703075530.GA25190@gondor.apana.org.au>
	<20090703.200254.172991821.davem@davemloft.net>
	<20090704030830.GA32442@gondor.apana.org.au>
Message-ID: <20090703.201347.146036232.davem@davemloft.net>

From: Herbert Xu <herbert at gondor.apana.org.au>
Date: Sat, 4 Jul 2009 11:08:30 +0800

> On Fri, Jul 03, 2009 at 08:02:54PM -0700, David Miller wrote:
>>
>> In particular the case of handling a device without usable TX
>> completion event indications is still quite troublesome.
> e
> Which particular devices do you have in mind?

NIU

I basically can't defer interrupts because the chip supports
per-TX-desc interrupt indications but it lacks an "all TX queue sent"
event.  So if, say, tell it to interrupt every 1/4 of the TX queue
then up to 1/4 of the queue can have packets "stuck" in there
if TX activity all of a sudden ceases.

The only thing I've come up with to be able to mitigate interrupts is
to use an hrtimer of some sort.  But that's going to be hard to get
right, and who knows what kind of latencies will be introduced for TX
completion packet freeing unless I am very carefull.

And finally this belongs in generic code, not in the NIU driver,
whatever we come up with.  Especially since my understanding is that
this is similar to what Rusty needs.



From herbert at gondor.apana.org.au  Sat Jul  4 03:42:45 2009
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Sat, 4 Jul 2009 15:42:45 +0800
Subject: [PATCH 1/4] net: skb_orphan on dev_hard_start_xmit
In-Reply-To: <20090703.201347.146036232.davem@davemloft.net>
References: <20090703075530.GA25190@gondor.apana.org.au>
	<20090703.200254.172991821.davem@davemloft.net>
	<20090704030830.GA32442@gondor.apana.org.au>
	<20090703.201347.146036232.davem@davemloft.net>
Message-ID: <20090704074245.GA1615@gondor.apana.org.au>

On Fri, Jul 03, 2009 at 08:13:47PM -0700, David Miller wrote:
>
> NIU
> 
> I basically can't defer interrupts because the chip supports
> per-TX-desc interrupt indications but it lacks an "all TX queue sent"
> event.  So if, say, tell it to interrupt every 1/4 of the TX queue
> then up to 1/4 of the queue can have packets "stuck" in there
> if TX activity all of a sudden ceases.

Here's an idea: We let the sender decide whether we need to enable
notification.  This decision would be carried as a flag in the skb.
For example, UDP would set this flag when its socket buffer is close
to capacity.  Routing would set this flag per NAPI run, etc.

Of course you'd ignore this flag completely if the qdisc queue is
non-empty.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From herbert at gondor.apana.org.au  Sat Jul  4 05:09:10 2009
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Sat, 4 Jul 2009 17:09:10 +0800
Subject: [PATCH 1/4] net: skb_orphan on dev_hard_start_xmit
In-Reply-To: <20090704074245.GA1615@gondor.apana.org.au>
References: <20090703075530.GA25190@gondor.apana.org.au>
	<20090703.200254.172991821.davem@davemloft.net>
	<20090704030830.GA32442@gondor.apana.org.au>
	<20090703.201347.146036232.davem@davemloft.net>
	<20090704074245.GA1615@gondor.apana.org.au>
Message-ID: <20090704090910.GA2185@gondor.apana.org.au>

On Sat, Jul 04, 2009 at 03:42:45PM +0800, Herbert Xu wrote:
> 
> Here's an idea: We let the sender decide whether we need to enable
> notification.  This decision would be carried as a flag in the skb.
> For example, UDP would set this flag when its socket buffer is close
> to capacity.  Routing would set this flag per NAPI run, etc.

Actually it doesn't even matter for routing because only those
that are charged by the skb's or the pages care and they're the
only ones that would need to set this.

One potential problem is if the socket is constantly running
close to capacity, but that should only happen if the device
TX queue is also close to capacity which means that the qdisc
queue should be non-empty.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From herbert at gondor.apana.org.au  Sat Jul  4 23:26:58 2009
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Sun, 5 Jul 2009 11:26:58 +0800
Subject: [PATCH 1/4] net: skb_orphan on dev_hard_start_xmit
In-Reply-To: <20090704090910.GA2185@gondor.apana.org.au>
References: <20090703075530.GA25190@gondor.apana.org.au>
	<20090703.200254.172991821.davem@davemloft.net>
	<20090704030830.GA32442@gondor.apana.org.au>
	<20090703.201347.146036232.davem@davemloft.net>
	<20090704074245.GA1615@gondor.apana.org.au>
	<20090704090910.GA2185@gondor.apana.org.au>
Message-ID: <20090705032658.GA7430@gondor.apana.org.au>

On Sat, Jul 04, 2009 at 05:09:10PM +0800, Herbert Xu wrote:
>
> One potential problem is if the socket is constantly running
> close to capacity, but that should only happen if the device
> TX queue is also close to capacity which means that the qdisc
> queue should be non-empty.

Here's a another crazy idea:

Let's use dummy TX descriptors to generate an interrupt, either
with or without transmitting an actual packet on the wire depending
on the NIC.

xmit(skb)

	if (TX queue contains no interrupting descriptor &&
	    qdisc is empty)
		mark TX descriptor as interrupting

clean()

	do work
	if (TX queue contains no interrupting descriptor &&
	    TX queue non-empty &&
	    qdisc is empty)
		send dummy TX descriptor

This is based on the assumption that in the time it takes for
the NIC to process one packet and interrupt us, we can generate
more packets.  Obviously if we can't then even if the NIC had
a queue-empty interrupt capability it wouldn't help.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From herbert at gondor.apana.org.au  Sat Jul  4 23:34:08 2009
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Sun, 5 Jul 2009 11:34:08 +0800
Subject: [PATCH 1/4] net: skb_orphan on dev_hard_start_xmit
In-Reply-To: <20090705032658.GA7430@gondor.apana.org.au>
References: <20090703075530.GA25190@gondor.apana.org.au>
	<20090703.200254.172991821.davem@davemloft.net>
	<20090704030830.GA32442@gondor.apana.org.au>
	<20090703.201347.146036232.davem@davemloft.net>
	<20090704074245.GA1615@gondor.apana.org.au>
	<20090704090910.GA2185@gondor.apana.org.au>
	<20090705032658.GA7430@gondor.apana.org.au>
Message-ID: <20090705033408.GB7430@gondor.apana.org.au>

On Sun, Jul 05, 2009 at 11:26:58AM +0800, Herbert Xu wrote:
> 
> Here's a another crazy idea:
> 
> Let's use dummy TX descriptors to generate an interrupt, either
> with or without transmitting an actual packet on the wire depending
> on the NIC.

Here's an even crazier idea that doesn't use dummy descriptors.

xmit(skb)

	if (TX queue contains no interrupting descriptor &&
	    qdisc is empty)
		mark TX descriptor as interrupting

	if (TX queue now contains an interrupting descriptor &&
	    qdisc len < 2)
		stop queue

	if (TX ring full)
		stop queue

clean()

 	do work
	wake queue as per usual

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From cato at vizyonyapi.net  Sun Jul  5 12:23:38 2009
From: cato at vizyonyapi.net (Vandemortel)
Date: Sun, 05 Jul 2009 16:23:38 -0000
Subject: Why Meen Give Upp Their Power For sex
Message-ID: <471dbb20090705161557@vizyonyapi.net>

Why Men Giive Up Their Power oFr sex www. via65. com. Buyer Pays $30 million fFor Rare Coin Collection


From Lars.Holowko at lantronix.com  Wed Jul  8 17:14:21 2009
From: Lars.Holowko at lantronix.com (Lars Holowko)
Date: Wed, 8 Jul 2009 14:14:21 -0700
Subject: How-to use the sdio driver?
Message-ID: <022254FBC8645942BBF88A022862CDD33C60BD@3putt.int.lantronix.com>

Hi everyone,

I am trying to get to run the libertas SDIO driver to work on an Atmel
AT91SAM9G20-EK eval board (linux-2.6.30.1).

After an insmod libertas_sdio.ko I see this on the console

libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman

but obviously if_sdio_probe never gets called (I added a printk there).

Is there anything else I have to do? I looked at
arch/arm/mach-at91/board-sam9g20ek.c and it looked like the default
configuration for the GPIO's look ok (I try to use the MCDB* GPIOS).

I think it would already help me if someone could outline for any
platform what needs to be done in general.

I would also appreciate if some could share an example how one can
activate the GSPI version (the docu for this on the website is a little
bit brief) - I want to compare the throughput that can be achieved with
both versions.

Thanks in advance,

Lars
 
**********************************************************************
This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited.


From daniel at caiaq.de  Wed Jul  8 17:31:46 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Wed, 8 Jul 2009 23:31:46 +0200
Subject: How-to use the sdio driver?
In-Reply-To: <022254FBC8645942BBF88A022862CDD33C60BD@3putt.int.lantronix.com>
References: <022254FBC8645942BBF88A022862CDD33C60BD@3putt.int.lantronix.com>
Message-ID: <20090708213146.GB18340@buzzloop.caiaq.de>

On Wed, Jul 08, 2009 at 02:14:21PM -0700, Lars Holowko wrote:
> I am trying to get to run the libertas SDIO driver to work on an Atmel
> AT91SAM9G20-EK eval board (linux-2.6.30.1).
> 
> After an insmod libertas_sdio.ko I see this on the console
> 
> libertas_sdio: Libertas SDIO driver
> libertas_sdio: Copyright Pierre Ossman
> 
> but obviously if_sdio_probe never gets called (I added a printk there).

Your driver should be probed once the device was detected on the SDIO
bus. Make sure all modules are loaded and the pin functions are set up
correctly. Is the power domain for that chip set up? Some board have
MOSFET load switches connected to GPIOs in order to be able to switch
off the device on demand.

Don't know you board environment, but on PXA based machines, there is
no more glue logic you need to provide.

You will need to provide a firmware later on, but that's a different
story.

Daniel



From dongas86 at gmail.com  Thu Jul  9 10:22:58 2009
From: dongas86 at gmail.com (Dongas)
Date: Thu, 9 Jul 2009 22:22:58 +0800
Subject: why no interrupt generated from Marvell wifi card in this case?
Message-ID: <60ce8d250907090722k1c9cc33y548bf77348f789e1@mail.gmail.com>

Dear ALL,

I'm debugging a transmit timeout issue when downloading files.
Finally i found the root cause was that the wifi card failed to
generate the interrupt as expected after a specific packet was sent to
card during the downloading process.
(According to the previous log i have , there shoud be a uploading
interrupt from card to notify the host that new packets received)
(Tried kernel 2.6.25 & 2.6.29, both have the same issue.)

Hopefully you can give me some help.

I have two questions:
1. There're many repeated packets sent to card via lbs_hard_start_xmit
fucntion during the downloading process. I'm not a expert on the TCP
protocol.
Is there any one who knows well about what 's function of them can
give some explain?
Are they used for handshaking for downloading between client and server?

2. Assume the packet is sent successfully to card,
Why the card didn't generte the uploading interrupt after its data is ready?
BTW, even the rssi command is sent when timeout happened, there's also
no command response interrupt from card, anybody knows why?

Please see in line for extra comments:

Below is the detailed log for 2.6.25(MMC log is simplified):
????(Here the correct part of log is cut off)
-----------------------------> Begin to send the packet
<-------------------------
libertas enter (INT): lbs_hard_start_xmit():69
libertas tx (INT): lbs_hard_start_xmit lined up packet
libertas leave (INT): lbs_hard_start_xmit():169, ret 0

libertas thread: main-thread 111: intcounter=0 currenttxskb=00000000 dnld_sent=0
libertas thread: main-thread 222 (waking up): intcounter=0
currenttxskb=00000000 dnld_sent=0
libertas thread: main-thread 333: intcounter=0 currenttxskb=00000000 dnld_sent=0
libertas thread: main-thread 444: intcounter=0 currenttxskb=00000000 dnld_sent=0
libertas enter: lbs_execute_next_command():1748
libertas leave: lbs_execute_next_command():1883
libertas enter: if_sdio_host_to_card(type 0, bytes 90):711
libertas leave: if_sdio_host_to_card():782, ret 0

libertas thread: main-thread 111: intcounter=0 currenttxskb=00000000 dnld_sent=1
libertas thread: main-thread sleeping... Conn=0 IntC=0 PS_mode=0 PS_State=0

------------------> Here the packet is sent successfully <------------------
libertas enter: if_sdio_host_to_card_worker():363
mmc1: 52  10004000
irq 1  0x40000000
mmc1: d (52): 0: 00001009
mmc1: 53  92000060
irq 1  0x40e00000
irq 1  0x80000000
mmc1: d (53): 0: 00002000
libertas leave: if_sdio_host_to_card_worker():403

libertas enter (INT): lbs_hard_start_xmit():69
libertas tx (INT): lbs_hard_start_xmit lined up packet
libertas leave (INT): lbs_hard_start_xmit():169, ret 0

libertas thread: main-thread 222 (waking up): intcounter=0
currenttxskb=00000000 dnld_sent=1
libertas thread: main-thread 333: intcounter=0 currenttxskb=00000000 dnld_sent=1
libertas thread: main-thread 444: intcounter=0 currenttxskb=00000000 dnld_sent=1
libertas thread: main-thread 111: intcounter=0 currenttxskb=00000000 dnld_sent=1
libertas thread: main-thread sleeping... Conn=0 IntC=0 PS_mode=0 PS_State=0

-------------> Always no interrupt generated by card and timeout
happened <----------
NETDEV WATCHDOG: eth0: transmit timed out   --------? NETDEV WATCHDOG
libertas enter (INT): lbs_tx_timeout():471
libertas: tx watch dog timeout
libertas enter (INT): lbs_host_to_card_done():499
libertas leave (INT): lbs_host_to_card_done():510
libertas enter (INT): lbs_prepare_and_send_command():1317
libertas enter (INT): lbs_get_cmd_ctrl_node():1678
libertas leave (INT): lbs_get_cmd_ctrl_node():1696
libertas enter (INT): lbs_set_cmd_ctrl_node():1719
libertas leave (INT): lbs_set_cmd_ctrl_node():1727
libertas host (INT): PREP_CMD: command 0x001f
libertas enter (INT): lbs_cmd_802_11_rssi():828
libertas leave (INT): lbs_cmd_802_11_rssi():841
libertas enter (INT): lbs_queue_cmd():1091
libertas host (INT): QUEUE_CMD: inserted command 0x001f into cmdpendingq
libertas leave (INT): lbs_queue_cmd():1126
libertas leave (INT): lbs_prepare_and_send_command():1576, ret 0
libertas leave (INT): lbs_tx_timeout():492

libertas thread: main-thread 222 (waking up): intcounter=0
currenttxskb=00000000 dnld_sent=0
libertas thread: main-thread 333: intcounter=0 currenttxskb=00000000 dnld_sent=0
libertas thread: main-thread 444: intcounter=0 currenttxskb=00000000 dnld_sent=0

libertas enter: lbs_execute_next_command():1748
libertas host: EXEC_NEXT_CMD: OK to send command 0x001f in psstate 0
libertas host: EXEC_NEXT_CMD: sending command 0x001f
libertas enter: lbs_submit_command():1140
libertas host: DNLD_CMD: command 0x001f, seq 54, size 16, jiffies 676512
libertas enter: if_sdio_host_to_card(type 1, bytes 16):711

libertas enter: if_sdio_host_to_card_worker():363
mmc1: 52  10004000
irq 1  0x40000000
mmc1: d (52): 0: 00001008
mmc1: 53  92000014
irq 1  0xc0000000
irq 1  0x80000000
mmc1: d (53): 0: 00002000
libertas leave: if_sdio_host_to_card():782, ret 0
libertas cmd: DNLD_CMD: sent command 0x001f, jiffies 676517

libertas leave: if_sdio_host_to_card_worker():403
libertas leave: lbs_submit_command():1175
libertas leave: lbs_execute_next_command():1883

libertas thread: main-thread 111: intcounter=0 currenttxskb=00000000 dnld_sent=2
libertas thread: main-thread sleeping... Conn=0 IntC=0 PS_mode=0 PS_State=0

libertas enter (INT): command_timer_fn():970
libertas: Command 1f timed out
libertas leave (INT): command_timer_fn():984

libertas thread: main-thread 222 (waking up): intcounter=0
currenttxskb=00000000 dnld_sent=2
libertas thread: main-thread 333: intcounter=0 currenttxskb=00000000 dnld_sent=2
libertas thread: main-thread 444: intcounter=0 currenttxskb=00000000 dnld_sent=2
libertas: requeueing command 1f due to timeout (#1)
libertas thread: main-thread 111: intcounter=0 currenttxskb=00000000 dnld_sent=2
libertas thread: main-thread sleeping... Conn=0 IntC=0 PS_mode=0 PS_State=0

NETDEV WATCHDOG: eth0: transmit timed out
libertas enter (INT): lbs_tx_timeout():471
libertas: tx watch dog timeout

Any reply will be highly appreciated.

Thanks

Regards
Dongas


From dcbw at redhat.com  Thu Jul  9 11:16:42 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 09 Jul 2009 11:16:42 -0400
Subject: How-to use the sdio driver?
In-Reply-To: <022254FBC8645942BBF88A022862CDD33C60BD@3putt.int.lantronix.com>
References: <022254FBC8645942BBF88A022862CDD33C60BD@3putt.int.lantronix.com>
Message-ID: <1247152602.23378.3.camel@dhcp-100-3-98.bos.redhat.com>

On Wed, 2009-07-08 at 14:14 -0700, Lars Holowko wrote:
> Hi everyone,
> 
> I am trying to get to run the libertas SDIO driver to work on an Atmel
> AT91SAM9G20-EK eval board (linux-2.6.30.1).
> 
> After an insmod libertas_sdio.ko I see this on the console
> 
> libertas_sdio: Libertas SDIO driver
> libertas_sdio: Copyright Pierre Ossman
> 
> but obviously if_sdio_probe never gets called (I added a printk there).
> 
> Is there anything else I have to do? I looked at
> arch/arm/mach-at91/board-sam9g20ek.c and it looked like the default
> configuration for the GPIO's look ok (I try to use the MCDB* GPIOS).

Load or build the MMC/SDIO stack modules with debugging.  If you don't
see a lot of log spew when the MMC/SDIO modules load, then obviously
libertas won't be able to find your card because the MMC bus doesn't
know about it.  You should also see stuff in /sys/bus/mmc/devices when
the card has actually been found.

Dan

> I think it would already help me if someone could outline for any
> platform what needs to be done in general.
> 
> I would also appreciate if some could share an example how one can
> activate the GSPI version (the docu for this on the website is a little
> bit brief) - I want to compare the throughput that can be achieved with
> both versions.
> 
> Thanks in advance,
> 
> Lars
>  
> **********************************************************************
> This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited.
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From Lars.Holowko at lantronix.com  Thu Jul  9 12:12:58 2009
From: Lars.Holowko at lantronix.com (Lars Holowko)
Date: Thu, 9 Jul 2009 09:12:58 -0700
Subject: How-to use the sdio driver?
References: <022254FBC8645942BBF88A022862CDD33C60BD@3putt.int.lantronix.com>
	<20090708213146.GB18340@buzzloop.caiaq.de>
Message-ID: <022254FBC8645942BBF88A022862CDD33C60BF@3putt.int.lantronix.com>

Thanks Daniel,

For confirming that it should work. At least I know that I am not on the
wrong track. I'll keep checking my GPIOs.

Lars 

-----Original Message-----
From: Daniel Mack [mailto:daniel at caiaq.de] 
Sent: Wednesday, July 08, 2009 2:32 PM
To: Lars Holowko
Cc: libertas-dev at lists.infradead.org
Subject: Re: How-to use the sdio driver?

On Wed, Jul 08, 2009 at 02:14:21PM -0700, Lars Holowko wrote:
> I am trying to get to run the libertas SDIO driver to work on an Atmel

> AT91SAM9G20-EK eval board (linux-2.6.30.1).
> 
> After an insmod libertas_sdio.ko I see this on the console
> 
> libertas_sdio: Libertas SDIO driver
> libertas_sdio: Copyright Pierre Ossman
> 
> but obviously if_sdio_probe never gets called (I added a printk
there).

Your driver should be probed once the device was detected on the SDIO
bus. Make sure all modules are loaded and the pin functions are set up
correctly. Is the power domain for that chip set up? Some board have
MOSFET load switches connected to GPIOs in order to be able to switch
off the device on demand.

Don't know you board environment, but on PXA based machines, there is no
more glue logic you need to provide.

You will need to provide a firmware later on, but that's a different
story.

Daniel
 
**********************************************************************
This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited.


From Lars.Holowko at lantronix.com  Thu Jul  9 12:44:13 2009
From: Lars.Holowko at lantronix.com (Lars Holowko)
Date: Thu, 9 Jul 2009 09:44:13 -0700
Subject: How-to use the sdio driver?
References: <022254FBC8645942BBF88A022862CDD33C60BD@3putt.int.lantronix.com>
	<1247152602.23378.3.camel@dhcp-100-3-98.bos.redhat.com>
Message-ID: <022254FBC8645942BBF88A022862CDD33C60C0@3putt.int.lantronix.com>

Thanks Dan,

For the hint concerning debug and the MMC bus. I don't see anything
happening there with my wifi card.

One source of the problem could be that the MMC slot seems to get
scanned only at boot up. It only recognizes a SD card when it is already
plugged in when the kernel gets booted but not if I plug it in later.

By that time the libertas module is not loaded yet. But when I configure
libertas_sdio to be linked statically, I don't see any difference
either...

I also added a couple of printks in
drives/mmc/core/sdio_bus.c:sdio_bus_event and
drives/mmc/core/sdio_bus.c:sdio_bus_probe but they never seem to get
called either - neither with the SD card nor the wireless board. Do you
know who is supposed to call those probe functions?

Lars

-----Original Message-----
From: Dan Williams [mailto:dcbw at redhat.com] 
Sent: Thursday, July 09, 2009 8:17 AM
To: Lars Holowko
Cc: libertas-dev at lists.infradead.org
Subject: Re: How-to use the sdio driver?

On Wed, 2009-07-08 at 14:14 -0700, Lars Holowko wrote:
> Hi everyone,
> 
> I am trying to get to run the libertas SDIO driver to work on an Atmel

> AT91SAM9G20-EK eval board (linux-2.6.30.1).
> 
> After an insmod libertas_sdio.ko I see this on the console
> 
> libertas_sdio: Libertas SDIO driver
> libertas_sdio: Copyright Pierre Ossman
> 
> but obviously if_sdio_probe never gets called (I added a printk
there).
> 
> Is there anything else I have to do? I looked at 
> arch/arm/mach-at91/board-sam9g20ek.c and it looked like the default 
> configuration for the GPIO's look ok (I try to use the MCDB* GPIOS).

Load or build the MMC/SDIO stack modules with debugging.  If you don't
see a lot of log spew when the MMC/SDIO modules load, then obviously
libertas won't be able to find your card because the MMC bus doesn't
know about it.  You should also see stuff in /sys/bus/mmc/devices when
the card has actually been found.

Dan

> I think it would already help me if someone could outline for any 
> platform what needs to be done in general.
> 
> I would also appreciate if some could share an example how one can 
> activate the GSPI version (the docu for this on the website is a 
> little bit brief) - I want to compare the throughput that can be 
> achieved with both versions.
> 
> Thanks in advance,
> 
> Lars
>  
> **********************************************************************
> This e-mail is the property of Lantronix. It is intended only for the
person or entity to which it is addressed and may contain information
that is privileged, confidential, or otherwise protected from
disclosure. Distribution or copying of this e-mail, or the information
contained herein, to anyone other than the intended recipient is
prohibited.
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From ramkumar.research at gmail.com  Fri Jul 10 02:57:19 2009
From: ramkumar.research at gmail.com (Ram kumar)
Date: Fri, 10 Jul 2009 12:27:19 +0530
Subject: xbox wireless network adapter in linux
Message-ID: <6306c640907092357o4b0d845apb74ded6b4c20a39a@mail.gmail.com>

hi,

    I would like to know whether we can support xbox wireless network
adapter in linux ?

http://www.xbox.com/en-US/hardware/x/xbox360wirelessnetadapter/default.htm

This xbox wireless network adapter has marvell 8388 controller.

Any info on how to support xbox wireless network adapter in linux
using libertas driver will be helpful to me.

And i have seen that the marvell 8388 controller with usb interface,
support "AP"(access point mode).

so i am assuming that the above xbox wirless network adapter can be
made to work as AP(access point)

correct me if i am wrong.

Regards,
Ram


From rdunlop at guralp.com  Fri Jul 10 06:53:45 2009
From: rdunlop at guralp.com (Bob Dunlop)
Date: Fri, 10 Jul 2009 11:53:45 +0100
Subject: 20 byte header on SD8686 rx packets
Message-ID: <20090710105345.GA23218@guralp.com>

Hi,

I'm trying to get a Wi2WI W2CBW0003 testboard (SD8686) with SDIO interface
running in a Compulab SB-X270 baseboard / CM-X270-L module.

Using a 2.6.31-rc2 kernel, 9.70.3p36 firmware from linux-firmware and
wpa_supplicant 0.6.9 I've got a system that's 75% running.  I'm hoping
someone can give me a clue as to what I've missed.

The card is detected in insertion and firmware upload etc all works.
"iwlist eth1 scan" works and shows a sensible list of access points
etc.  A network monitor on the WiFi side even shows the card transmitting
sensible packets.

The problem is that packet reception isn'tworking.  From the tcpdump output
it looks like every packet is prefixed with a 20 byte header from the chip
itself.  There seems to be code in rx.c for stripping similar headers but
it doesn't seem to be coming into play in my case.


I'll start digging, this mail is just in the hope that someone has seen
this before and can point out the step I've missed.


listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
09:04:28.136853 59:00:14:00:00:00 (oui Unknown) > 01:00:09:00:4c:00 (oui Unknown
) Null Information, send seq 0, rcv seq 0, Flags [Command], length 82
        0x0000:  0100 0900 4c00 5900 1400 0000 0000 0000  ....L.Y.........
        0x0010:  0000 0000 ffff ffff ffff 001e 0bbd b9fc  ................
        0x0020:  003e 0af3 be00 bdc2 4282 943a 43dd 1739  .>......B..:C..9
        0x0030:  bf5d 26c8 e7e7 2b24 beb1 ef3c 9774 7772  .]&...+$...<.twr
        0x0040:  5aa4 a3c3 7349 7b80 ac94 b6a3 acac d3e2  Z...sI{.........
        0x0050:  c8b7 9c3a d724 fd79 a25a b92b 18bb 1452  ...:.$.y.Z.+...R
09:04:29.214879 59:00:14:00:00:00 (oui Unknown) > 01:00:08:00:4c:00 (oui Unknown
) Null Information, send seq 0, rcv seq 0, Flags [Command], length 82
        0x0000:  0100 0800 4c00 5900 1400 0000 0000 0000  ....L.Y.........
        0x0010:  0000 0000 ffff ffff ffff 001e 0b75 fc74  .............u.t
        0x0020:  003e 18f3 be00 cf96 b2fd 0985 fd89 7101  .>............q.
        0x0030:  ed5a b182 7652 32fb 310a f4e6 a528 ea7e  .Z..vR2.1....(.~
        0x0040:  ca8d e8b5 c910 9843 1b29 07c6 acc1 0dc8  .......C.)......
        0x0050:  18bc ecec 4539 e957 b2cf d309 035b 5cb0  ....E9.W.....[\.
09:04:30.106648 5a:00:14:00:00:00 (oui Unknown) > 01:00:07:00:03:01 (oui Unknown
) Null Information, send seq 0, rcv seq 0, Flags [Command], length 265
        0x0000:  0100 0700 0301 5a00 1400 0000 0000 0000  ......Z.........
        0x0010:  0000 0000 ffff ffff ffff 001e 0b2e 01ea  ................
        0x0020:  00f5 1df3 be00 346a d466 4ed2 3858 e889  ......4j.fN.8X..
        0x0030:  a300 e1a7 d517 2207 5bdf 69fe f8ff f51f  ......".[.i.....
        0x0040:  5059 ddc8 ee6f 1515 bb54 7272 cd5e dcf0  PY...o...Trr.^..
        0x0050:  34ba f3b1 d20e 8e61 c3db e907 8f1d ef66  4......a.......f

-- 
        Bob Dunlop
        Guralp Systems Limited
        http://www.guralp.com


From rdunlop at guralp.com  Fri Jul 10 12:19:37 2009
From: rdunlop at guralp.com (Bob Dunlop)
Date: Fri, 10 Jul 2009 17:19:37 +0100
Subject: 20 byte header on SD8686 rx packets
In-Reply-To: <20090710105345.GA23218@guralp.com>
References: <20090710105345.GA23218@guralp.com>
Message-ID: <20090710161937.GA26443@guralp.com>

Replying to my own message I know.

On Fri, Jul 10 at 11:53, Bob Dunlop wrote:
...
> I'll start digging, this mail is just in the hope that someone has seen
> this before and can point out the step I've missed.

Well I have a solution that works for me, but given the widespread
usage of this driver I think I'd better just air it and see what
others think.

The problem was a change to the packing of struct rxpd caused when the
new status union was added.  Try as I might I couldn't get it to pack
right.  So since only one field was being used in just one place I
hacked it out.  I know this isn't a good solution, but as I said above
it works for me.

What does the panel think ?


diff -u hostcmd.h{-orig,}
--- hostcmd.h-orig      2009-07-04 18:58:48.000000000 +0100
+++ hostcmd.h   2009-07-10 16:55:33.000000000 +0100
@@ -47,17 +47,11 @@
 
 /* RxPD Descriptor */
 struct rxpd {
-       /* union to cope up with later FW revisions */
-       union {
-               /* Current Rx packet status */
-               __le16 status;
-               struct {
-                       /* BSS type: client, AP, etc. */
-                       u8 bss_type;
-                       /* BSS number */
-                       u8 bss_num;
-               } bss;
-       } u;
+       /* Current Rx packet status */
+       /* BSS type: client, AP, etc. */
+       u8 bss_type;
+       /* BSS number */
+       u8 bss_num;
 
        /* SNR */
        u8 snr;
diff -u rx.c{-orig,}
--- rx.c-orig   2009-07-04 18:58:48.000000000 +0100
+++ rx.c        2009-07-10 16:55:50.000000000 +0100
@@ -165,7 +165,7 @@
                        if (p_rx_pd->rx_control & RxPD_MESH_FRAME)
                                dev = priv->mesh_dev;
                } else if (priv->mesh_fw_ver == MESH_FW_NEW) {
-                       if (p_rx_pd->u.bss.bss_num == MESH_IFACE_ID)
+                       if (p_rx_pd->bss_num == MESH_IFACE_ID)
                                dev = priv->mesh_dev;
                }
        }

-- 
        Bob Dunlop
        Guralp Systems Limited
        http://www.guralp.com


From dongas86 at gmail.com  Fri Jul 10 13:51:18 2009
From: dongas86 at gmail.com (Dongas)
Date: Sat, 11 Jul 2009 01:51:18 +0800
Subject: why no interrupt generated from Marvell wifi card in this case?
In-Reply-To: <60ce8d250907090722k1c9cc33y548bf77348f789e1@mail.gmail.com>
References: <60ce8d250907090722k1c9cc33y548bf77348f789e1@mail.gmail.com>
Message-ID: <60ce8d250907101051q1d57d3f0ma86ec14a95664965@mail.gmail.com>

Hi ALL,

Could anyone share some experience?
Is there a possibility that the WiFi card fails to generate the
interrupt by itself by whatever reason?

Maybe my understanding is wrong, but could you help point it out?
You response may be a big help for me.

Thanks

Regards
Dongas

2009/7/9 Dongas <dongas86 at gmail.com>:
> Dear ALL,
>
> I'm debugging a transmit timeout issue when downloading files.
> Finally i found the root cause was that the wifi card failed to
> generate the interrupt as expected after a specific packet was sent to
> card during the downloading process.
> (According to the previous log i have , there shoud be a uploading
> interrupt from card to notify the host that new packets received)
> (Tried kernel 2.6.25 & 2.6.29, both have the same issue.)
>
> Hopefully you can give me some help.
>
> I have two questions:
> 1. There're many repeated packets sent to card via lbs_hard_start_xmit
> fucntion during the downloading process. I'm not a expert on the TCP
> protocol.
> Is there any one who knows well about what 's function of them can
> give some explain?
> Are they used for handshaking for downloading between client and server?
>
> 2. Assume the packet is sent successfully to card,
> Why the card didn't generte the uploading interrupt after its data is ready?
> BTW, even the rssi command is sent when timeout happened, there's also
> no command response interrupt from card, anybody knows why?
>
> Please see in line for extra comments:
>
> Below is the detailed log for 2.6.25(MMC log is simplified):
> ????(Here the correct part of log is cut off)
> -----------------------------> Begin to send the packet
> <-------------------------
> libertas enter (INT): lbs_hard_start_xmit():69
> libertas tx (INT): lbs_hard_start_xmit lined up packet
> libertas leave (INT): lbs_hard_start_xmit():169, ret 0
>
> libertas thread: main-thread 111: intcounter=0 currenttxskb=00000000 dnld_sent=0
> libertas thread: main-thread 222 (waking up): intcounter=0
> currenttxskb=00000000 dnld_sent=0
> libertas thread: main-thread 333: intcounter=0 currenttxskb=00000000 dnld_sent=0
> libertas thread: main-thread 444: intcounter=0 currenttxskb=00000000 dnld_sent=0
> libertas enter: lbs_execute_next_command():1748
> libertas leave: lbs_execute_next_command():1883
> libertas enter: if_sdio_host_to_card(type 0, bytes 90):711
> libertas leave: if_sdio_host_to_card():782, ret 0
>
> libertas thread: main-thread 111: intcounter=0 currenttxskb=00000000 dnld_sent=1
> libertas thread: main-thread sleeping... Conn=0 IntC=0 PS_mode=0 PS_State=0
>
> ------------------> Here the packet is sent successfully <------------------
> libertas enter: if_sdio_host_to_card_worker():363
> mmc1: 52 ?10004000
> irq 1 ?0x40000000
> mmc1: d (52): 0: 00001009
> mmc1: 53 ?92000060
> irq 1 ?0x40e00000
> irq 1 ?0x80000000
> mmc1: d (53): 0: 00002000
> libertas leave: if_sdio_host_to_card_worker():403
>
> libertas enter (INT): lbs_hard_start_xmit():69
> libertas tx (INT): lbs_hard_start_xmit lined up packet
> libertas leave (INT): lbs_hard_start_xmit():169, ret 0
>
> libertas thread: main-thread 222 (waking up): intcounter=0
> currenttxskb=00000000 dnld_sent=1
> libertas thread: main-thread 333: intcounter=0 currenttxskb=00000000 dnld_sent=1
> libertas thread: main-thread 444: intcounter=0 currenttxskb=00000000 dnld_sent=1
> libertas thread: main-thread 111: intcounter=0 currenttxskb=00000000 dnld_sent=1
> libertas thread: main-thread sleeping... Conn=0 IntC=0 PS_mode=0 PS_State=0
>
> -------------> Always no interrupt generated by card and timeout
> happened <----------
> NETDEV WATCHDOG: eth0: transmit timed out ? --------? NETDEV WATCHDOG
> libertas enter (INT): lbs_tx_timeout():471
> libertas: tx watch dog timeout
> libertas enter (INT): lbs_host_to_card_done():499
> libertas leave (INT): lbs_host_to_card_done():510
> libertas enter (INT): lbs_prepare_and_send_command():1317
> libertas enter (INT): lbs_get_cmd_ctrl_node():1678
> libertas leave (INT): lbs_get_cmd_ctrl_node():1696
> libertas enter (INT): lbs_set_cmd_ctrl_node():1719
> libertas leave (INT): lbs_set_cmd_ctrl_node():1727
> libertas host (INT): PREP_CMD: command 0x001f
> libertas enter (INT): lbs_cmd_802_11_rssi():828
> libertas leave (INT): lbs_cmd_802_11_rssi():841
> libertas enter (INT): lbs_queue_cmd():1091
> libertas host (INT): QUEUE_CMD: inserted command 0x001f into cmdpendingq
> libertas leave (INT): lbs_queue_cmd():1126
> libertas leave (INT): lbs_prepare_and_send_command():1576, ret 0
> libertas leave (INT): lbs_tx_timeout():492
>
> libertas thread: main-thread 222 (waking up): intcounter=0
> currenttxskb=00000000 dnld_sent=0
> libertas thread: main-thread 333: intcounter=0 currenttxskb=00000000 dnld_sent=0
> libertas thread: main-thread 444: intcounter=0 currenttxskb=00000000 dnld_sent=0
>
> libertas enter: lbs_execute_next_command():1748
> libertas host: EXEC_NEXT_CMD: OK to send command 0x001f in psstate 0
> libertas host: EXEC_NEXT_CMD: sending command 0x001f
> libertas enter: lbs_submit_command():1140
> libertas host: DNLD_CMD: command 0x001f, seq 54, size 16, jiffies 676512
> libertas enter: if_sdio_host_to_card(type 1, bytes 16):711
>
> libertas enter: if_sdio_host_to_card_worker():363
> mmc1: 52 ?10004000
> irq 1 ?0x40000000
> mmc1: d (52): 0: 00001008
> mmc1: 53 ?92000014
> irq 1 ?0xc0000000
> irq 1 ?0x80000000
> mmc1: d (53): 0: 00002000
> libertas leave: if_sdio_host_to_card():782, ret 0
> libertas cmd: DNLD_CMD: sent command 0x001f, jiffies 676517
>
> libertas leave: if_sdio_host_to_card_worker():403
> libertas leave: lbs_submit_command():1175
> libertas leave: lbs_execute_next_command():1883
>
> libertas thread: main-thread 111: intcounter=0 currenttxskb=00000000 dnld_sent=2
> libertas thread: main-thread sleeping... Conn=0 IntC=0 PS_mode=0 PS_State=0
>
> libertas enter (INT): command_timer_fn():970
> libertas: Command 1f timed out
> libertas leave (INT): command_timer_fn():984
>
> libertas thread: main-thread 222 (waking up): intcounter=0
> currenttxskb=00000000 dnld_sent=2
> libertas thread: main-thread 333: intcounter=0 currenttxskb=00000000 dnld_sent=2
> libertas thread: main-thread 444: intcounter=0 currenttxskb=00000000 dnld_sent=2
> libertas: requeueing command 1f due to timeout (#1)
> libertas thread: main-thread 111: intcounter=0 currenttxskb=00000000 dnld_sent=2
> libertas thread: main-thread sleeping... Conn=0 IntC=0 PS_mode=0 PS_State=0
>
> NETDEV WATCHDOG: eth0: transmit timed out
> libertas enter (INT): lbs_tx_timeout():471
> libertas: tx watch dog timeout
>
> Any reply will be highly appreciated.
>
> Thanks
>
> Regards
> Dongas
>


From bzhao at marvell.com  Fri Jul 10 14:00:15 2009
From: bzhao at marvell.com (Bing Zhao)
Date: Fri, 10 Jul 2009 11:00:15 -0700
Subject: 20 byte header on SD8686 rx packets
In-Reply-To: <20090710161937.GA26443@guralp.com>
References: <20090710105345.GA23218@guralp.com>
	<20090710161937.GA26443@guralp.com>
Message-ID: <477F20668A386D41ADCC57781B1F704306CC1C5A02@SC-VEXCH1.marvell.com>

Hi Bob,

> -----Original Message-----
> From: libertas-dev-bounces at lists.infradead.org [mailto:libertas-dev-bounces at lists.infradead.org] On
> Behalf Of Bob Dunlop
> Sent: Friday, July 10, 2009 9:20 AM
> To: libertas-dev at lists.infradead.org
> Subject: Re: 20 byte header on SD8686 rx packets
> 
> Replying to my own message I know.
> 
> On Fri, Jul 10 at 11:53, Bob Dunlop wrote:
> ...
> > I'll start digging, this mail is just in the hope that someone has seen
> > this before and can point out the step I've missed.
> 
> Well I have a solution that works for me, but given the widespread
> usage of this driver I think I'd better just air it and see what
> others think.
> 
> The problem was a change to the packing of struct rxpd caused when the
> new status union was added.  Try as I might I couldn't get it to pack
> right.  So since only one field was being used in just one place I
> hacked it out.  I know this isn't a good solution, but as I said above
> it works for me.

I added the new status/bss union to support different firmware versions.

I'm more interested in fixing any issue of RxPD structure packing in rx.c.
Could you please enable LIBERTAS_DEBUG and hexdump some data before and after the RxPD is stripped?
Basically I want to locate the place where the problem occurs and find out how it happens on your platform.

Thanks,

Bing

> What does the panel think ?
> 
> 
> diff -u hostcmd.h{-orig,}
> --- hostcmd.h-orig      2009-07-04 18:58:48.000000000 +0100
> +++ hostcmd.h   2009-07-10 16:55:33.000000000 +0100
> @@ -47,17 +47,11 @@
> 
>  /* RxPD Descriptor */
>  struct rxpd {
> -       /* union to cope up with later FW revisions */
> -       union {
> -               /* Current Rx packet status */
> -               __le16 status;
> -               struct {
> -                       /* BSS type: client, AP, etc. */
> -                       u8 bss_type;
> -                       /* BSS number */
> -                       u8 bss_num;
> -               } bss;
> -       } u;
> +       /* Current Rx packet status */
> +       /* BSS type: client, AP, etc. */
> +       u8 bss_type;
> +       /* BSS number */
> +       u8 bss_num;
> 
>         /* SNR */
>         u8 snr;
> diff -u rx.c{-orig,}
> --- rx.c-orig   2009-07-04 18:58:48.000000000 +0100
> +++ rx.c        2009-07-10 16:55:50.000000000 +0100
> @@ -165,7 +165,7 @@
>                         if (p_rx_pd->rx_control & RxPD_MESH_FRAME)
>                                 dev = priv->mesh_dev;
>                 } else if (priv->mesh_fw_ver == MESH_FW_NEW) {
> -                       if (p_rx_pd->u.bss.bss_num == MESH_IFACE_ID)
> +                       if (p_rx_pd->bss_num == MESH_IFACE_ID)
>                                 dev = priv->mesh_dev;
>                 }
>         }
> 
> --
>         Bob Dunlop
>         Guralp Systems Limited
>         http://www.guralp.com
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev


From dongas86 at gmail.com  Sat Jul 11 01:06:26 2009
From: dongas86 at gmail.com (Dongas)
Date: Sat, 11 Jul 2009 13:06:26 +0800
Subject: How-to use the sdio driver?
In-Reply-To: <022254FBC8645942BBF88A022862CDD33C60C0@3putt.int.lantronix.com>
References: <022254FBC8645942BBF88A022862CDD33C60BD@3putt.int.lantronix.com>
	<1247152602.23378.3.camel@dhcp-100-3-98.bos.redhat.com>
	<022254FBC8645942BBF88A022862CDD33C60C0@3putt.int.lantronix.com>
Message-ID: <60ce8d250907102206u75eb40fclbd3f9f6bbfdae765@mail.gmail.com>

2009/7/10 Lars Holowko <Lars.Holowko at lantronix.com>:
> Thanks Dan,
>
> For the hint concerning debug and the MMC bus. I don't see anything
> happening there with my wifi card.
>
> One source of the problem could be that the MMC slot seems to get
> scanned only at boot up. It only recognizes a SD card when it is already
> plugged in when the kernel gets booted but not if I plug it in later.
>
> By that time the libertas module is not loaded yet. But when I configure
> libertas_sdio to be linked statically, I don't see any difference
> either...

Which WiFi card are you using?
Probably the WiFi card was not properly detected by your SDIO controller.
Make sure the configuration of your GPIO pin for card detection is right.
BTW, have you tried pre-plug in the WiFi card before power up the board?

> I also added a couple of printks in
> drives/mmc/core/sdio_bus.c:sdio_bus_event and
> drives/mmc/core/sdio_bus.c:sdio_bus_probe but they never seem to get
> called either - neither with the SD card nor the wireless board. Do you
> know who is supposed to call those probe functions?

sdio_bus_probe will be called by MMC/SDIO Stack once a SDIO function
and driver are matched on SDIO Bus.

Regards
Dongas


From rdunlop at guralp.com  Sat Jul 11 04:27:00 2009
From: rdunlop at guralp.com (Bob Dunlop)
Date: Sat, 11 Jul 2009 09:27:00 +0100
Subject: 20 byte header on SD8686 rx packets
In-Reply-To: <477F20668A386D41ADCC57781B1F704306CC1C5A02@SC-VEXCH1.marvell.com>
References: <20090710105345.GA23218@guralp.com>
	<20090710161937.GA26443@guralp.com>
	<477F20668A386D41ADCC57781B1F704306CC1C5A02@SC-VEXCH1.marvell.com>
Message-ID: <20090711082700.GA811@guralp.com>

Hi,

On Fri, Jul 10 at 11:00, Bing Zhao wrote:
> > 
> > The problem was a change to the packing of struct rxpd caused when the
> > new status union was added.  Try as I might I couldn't get it to pack
> > right.  So since only one field was being used in just one place I
> > hacked it out.  I know this isn't a good solution, but as I said above
> > it works for me.
> 
> I added the new status/bss union to support different firmware versions.
...
Yes I saw that and I liked the clarification it produced.  Unfortunatly I
just couldn't get it to pack straight with my compiler.

> I'm more interested in fixing any issue of RxPD structure packing in rx.c.
> Could you please enable LIBERTAS_DEBUG and hexdump some data before and after the RxPD is stripped?

I can do that when I get into the office on Monday but I don't think it will
help.  The problem is not in the data but in the way the compiler interprets
the structure.

We're using a rather old cross compiler for ARM based on gcc 3.4.5

During my dig I added a printk to display the values of various pointers
and the offset between p_rx_pd and &p_rx_pd->pkt_ptr was 10 bytes rather
than the 8 you would expect from a packed structure.

Try as I might with the packed attribute and various pragmas I couldn't
get the offset down to 8 bytes until I ripped out the union :(


The offset of +2 changes the value read for p_rx_pd->pkt_ptr from the
expected 0x14 to 0x0 and hence the code doesn't skip over the 20 byte
header.  The 0x14 is still in the correct place in the data stream as
you can see in the original tcpdumps, it's just the compiler is looking
in the wrong place.
-- 
        Bob Dunlop
        Guralp Systems Limited
        http://www.guralp.com


From eauth at softsys.co.at  Sat Jul 11 05:51:43 2009
From: eauth at softsys.co.at (Erwin Authried)
Date: Sat, 11 Jul 2009 11:51:43 +0200
Subject: 20 byte header on SD8686 rx packets
In-Reply-To: <20090711082700.GA811@guralp.com>
References: <20090710105345.GA23218@guralp.com>
	<20090710161937.GA26443@guralp.com>
	<477F20668A386D41ADCC57781B1F704306CC1C5A02@SC-VEXCH1.marvell.com>
	<20090711082700.GA811@guralp.com>
Message-ID: <1247305903.3954.22.camel@timing-laptop>

Hi Bob,

it looks like you have to use the "packed" attribute for the union as
well as each struct inside the union, otherwise the compiler for the ARM
will align the size to next 32-bit boundary.

-Erwin

Am Samstag, den 11.07.2009, 09:27 +0100 schrieb Bob Dunlop:
> Hi,
> 
> On Fri, Jul 10 at 11:00, Bing Zhao wrote:
> > > 
> > > The problem was a change to the packing of struct rxpd caused when the
> > > new status union was added.  Try as I might I couldn't get it to pack
> > > right.  So since only one field was being used in just one place I
> > > hacked it out.  I know this isn't a good solution, but as I said above
> > > it works for me.
> > 
> > I added the new status/bss union to support different firmware versions.
> ...
> Yes I saw that and I liked the clarification it produced.  Unfortunatly I
> just couldn't get it to pack straight with my compiler.
> 
> > I'm more interested in fixing any issue of RxPD structure packing in rx.c.
> > Could you please enable LIBERTAS_DEBUG and hexdump some data before and after the RxPD is stripped?
> 
> I can do that when I get into the office on Monday but I don't think it will
> help.  The problem is not in the data but in the way the compiler interprets
> the structure.
> 
> We're using a rather old cross compiler for ARM based on gcc 3.4.5
> 
> During my dig I added a printk to display the values of various pointers
> and the offset between p_rx_pd and &p_rx_pd->pkt_ptr was 10 bytes rather
> than the 8 you would expect from a packed structure.
> 
> Try as I might with the packed attribute and various pragmas I couldn't
> get the offset down to 8 bytes until I ripped out the union :(
> 
> 
> The offset of +2 changes the value read for p_rx_pd->pkt_ptr from the
> expected 0x14 to 0x0 and hence the code doesn't skip over the 20 byte
> header.  The 0x14 is still in the correct place in the data stream as
> you can see in the original tcpdumps, it's just the compiler is looking
> in the wrong place.



From dcbw at redhat.com  Sun Jul 12 23:38:33 2009
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 12 Jul 2009 23:38:33 -0400
Subject: xbox wireless network adapter in linux
In-Reply-To: <6306c640907092357o4b0d845apb74ded6b4c20a39a@mail.gmail.com>
References: <6306c640907092357o4b0d845apb74ded6b4c20a39a@mail.gmail.com>
Message-ID: <1247456313.26142.6.camel@localhost.localdomain>

On Fri, 2009-07-10 at 12:27 +0530, Ram kumar wrote:
> hi,
> 
>     I would like to know whether we can support xbox wireless network
> adapter in linux ?
> 
> http://www.xbox.com/en-US/hardware/x/xbox360wirelessnetadapter/default.htm
> 
> This xbox wireless network adapter has marvell 8388 controller.

As far as we know, the Xbox wireless controller has a different layout
and does not use the same boot process as the usb8388 support that the
Linux kernel currently has.  We're not sure what firmware it has either.
Basically, when we looked (long ago) we couldn't figure out how to talk
to it, and of course Microsoft wouldn't be very helpful here.

> Any info on how to support xbox wireless network adapter in linux
> using libertas driver will be helpful to me.

It doesn't currently work and wouldn't work in the future without some
investigation.

> And i have seen that the marvell 8388 controller with usb interface,
> support "AP"(access point mode).

It can, but that depends on the firmware.  Marvell hasn't (to my
knowledge) released AP-mode firmware for the 8388.  So the best you'll
get is ad-hoc mode.

Dan

> so i am assuming that the above xbox wirless network adapter can be
> made to work as AP(access point)
> 
> correct me if i am wrong.
> 
> Regards,
> Ram
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From ramkumar.research at gmail.com  Mon Jul 13 02:15:48 2009
From: ramkumar.research at gmail.com (Ram kumar)
Date: Mon, 13 Jul 2009 11:45:48 +0530
Subject: xbox wireless network adapter in linux
In-Reply-To: <1247456313.26142.6.camel@localhost.localdomain>
References: <6306c640907092357o4b0d845apb74ded6b4c20a39a@mail.gmail.com>
	<1247456313.26142.6.camel@localhost.localdomain>
Message-ID: <6306c640907122315l38ff82a3mfd715b4cd27911a@mail.gmail.com>

hi,

> It can, but that depends on the firmware.  Marvell hasn't (to my
> knowledge) released AP-mode firmware for the 8388.  So the best you'll
> get is ad-hoc mode.

Thanks for the reply.It would be helpful if you can give some more
information on the following.

1.Is there any controller that can support "AP" mode.bcos when i refer
the "linuxwireless" website there are controllers that has the support
for "AP" mode with USB as an interface but most of them are
discontinued products.

2.It would he helpful if you can suggest some wireless controller that
can support "AP" mode which tested with a linux O.S with USB or SDIO
as an connecting interface.

Thanks for the help.


From rdunlop at guralp.com  Mon Jul 13 03:48:47 2009
From: rdunlop at guralp.com (Bob Dunlop)
Date: Mon, 13 Jul 2009 08:48:47 +0100
Subject: 20 byte header on SD8686 rx packets
In-Reply-To: <1247305903.3954.22.camel@timing-laptop>
References: <20090710105345.GA23218@guralp.com>
	<20090710161937.GA26443@guralp.com>
	<477F20668A386D41ADCC57781B1F704306CC1C5A02@SC-VEXCH1.marvell.com>
	<20090711082700.GA811@guralp.com>
	<1247305903.3954.22.camel@timing-laptop>
Message-ID: <20090713074847.GA7643@guralp.com>

Hi,

On Sat, Jul 11 at 11:51, Erwin Authried wrote:
> Hi Bob,
> 
> it looks like you have to use the "packed" attribute for the union as
> well as each struct inside the union, otherwise the compiler for the ARM
> will align the size to next 32-bit boundary.

Yep, I've revisited the tests this morning and I can get everything to work
with just the following patch.  I was putting the attribute directives in
the wrong place last week.  You do need both directives as shown.

This is with Gcc 3.4.5 but I guess the extra directives are harmless on
later versions of the compiler.


diff -u linux-2.6.31-rc2/drivers/net/wireless/libertas/hostcmd.h{-orig,}
--- linux-2.6.31-rc2/drivers/net/wireless/libertas/hostcmd.h-orig     2009-07-04 18:58:48.000000000 +0100
+++ linux-2.6.31-rc2/drivers/net/wireless/libertas/hostcmd.h  2009-07-13 08:27:45.000000000 +0100
@@ -56,8 +56,8 @@
                        u8 bss_type;
                        /* BSS number */
                        u8 bss_num;
-               } bss;
-       } u;
+               } __attribute__ ((packed)) bss;
+       } __attribute__ ((packed)) u;
 
        /* SNR */
        u8 snr;

-- 
        Bob Dunlop
        Guralp Systems Limited
        http://www.guralp.com


From Lars.Holowko at lantronix.com  Mon Jul 13 12:59:55 2009
From: Lars.Holowko at lantronix.com (Lars Holowko)
Date: Mon, 13 Jul 2009 09:59:55 -0700
Subject: How-to use the sdio driver?
References: <022254FBC8645942BBF88A022862CDD33C60BD@3putt.int.lantronix.com>
	<1247152602.23378.3.camel@dhcp-100-3-98.bos.redhat.com>
	<022254FBC8645942BBF88A022862CDD33C60C0@3putt.int.lantronix.com>
	<60ce8d250907102206u75eb40fclbd3f9f6bbfdae765@mail.gmail.com>
Message-ID: <022254FBC8645942BBF88A022862CDD33C60CA@3putt.int.lantronix.com>


>> Thanks Dan,
>>
>> For the hint concerning debug and the MMC bus. I don't see anything 
>> happening there with my wifi card.
>>
>> One source of the problem could be that the MMC slot seems to get 
>> scanned only at boot up. It only recognizes a SD card when it is 
>> already plugged in when the kernel gets booted but not if I plug it
in later.
>>
>> By that time the libertas module is not loaded yet. But when I 
>> configure libertas_sdio to be linked statically, I don't see any 
>> difference either...
>
> Which WiFi card are you using?
> Probably the WiFi card was not properly detected by your SDIO
controller.
> Make sure the configuration of your GPIO pin for card detection is
right.
> BTW, have you tried pre-plug in the WiFi card before power up the
board?
>

I am using a Marvell 88W8686 development board. It has a SD-card style
connector so I would assume that I won't have to modify any additional
GPIOs because it would use the same GPIOs as a SD-card in the same slot,
right? Pre-plugging the WiFi card does not work (no output other then
that the libertas driver was registered) - as opposed to the SD-card.

>> I also added a couple of printks in
>> drives/mmc/core/sdio_bus.c:sdio_bus_event and 
>> drives/mmc/core/sdio_bus.c:sdio_bus_probe but they never seem to get 
>> called either - neither with the SD card nor the wireless board. Do 
>> you know who is supposed to call those probe functions?

> sdio_bus_probe will be called by MMC/SDIO Stack once a SDIO function
and driver are matched on SDIO Bus.

May you point me where this sdio bus scanning/matching is happening? Is
it mmc_rescan in drivers/mmc/core/core.c ?


Regards,

Lars
 
**********************************************************************
This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited.


From jic23 at cam.ac.uk  Mon Jul 13 13:19:22 2009
From: jic23 at cam.ac.uk (Jonathan Cameron)
Date: Mon, 13 Jul 2009 17:19:22 +0000
Subject: Firmware support for background scanning
Message-ID: <4A5B6C9A.7060402@cam.ac.uk>

Dear All,

Before taking the suck it and see approach I was wondering
if anyone knows if the background scanning facilities
mentioned in the 5.1 firmware specification are implemented
in the current 8686 sdio firmware?

I don't think the driver currently has support for this option.

My intention is to use this functionality if present to
allow a card to notify userspace of when a network comes
into range (the card itself is moving fairly quickly).

This corresponds to the option described in the firmware
as 'Not connected and Deep sleep'.

If the firmware does support it has anyone any experience
of utilizing it?

Thanks,

---
Jonathan Cameron



From dcbw at redhat.com  Mon Jul 13 13:39:37 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 13 Jul 2009 13:39:37 -0400
Subject: Firmware support for background scanning
In-Reply-To: <4A5B6C9A.7060402@cam.ac.uk>
References: <4A5B6C9A.7060402@cam.ac.uk>
Message-ID: <1247506777.4369.6.camel@localhost.localdomain>

On Mon, 2009-07-13 at 17:19 +0000, Jonathan Cameron wrote:
> Dear All,
> 
> Before taking the suck it and see approach I was wondering
> if anyone knows if the background scanning facilities
> mentioned in the 5.1 firmware specification are implemented
> in the current 8686 sdio firmware?

I'd expect them to be implemented in the v8 and later firmware that the
sd8686 uses, but I haven't actually tried to use the background scan
functionality.  It wouldn't be to hard to write in some testing support
just to see if it was functional.

Dan

> I don't think the driver currently has support for this option.
> 
> My intention is to use this functionality if present to
> allow a card to notify userspace of when a network comes
> into range (the card itself is moving fairly quickly).
> 
> This corresponds to the option described in the firmware
> as 'Not connected and Deep sleep'.
> 
> If the firmware does support it has anyone any experience
> of utilizing it?
> 
> Thanks,
> 
> ---
> Jonathan Cameron
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From fourpenny at mic.gov.ec  Mon Jul 13 22:31:52 2009
From: fourpenny at mic.gov.ec (Maddocks Polland)
Date: Tue, 14 Jul 2009 03:31:52 +0100
Subject: aborted
Message-ID: <085064132054@mic.gov.ec>

Future orff sex.www+nu26+com


From dongas86 at gmail.com  Tue Jul 14 11:20:50 2009
From: dongas86 at gmail.com (Dongas)
Date: Tue, 14 Jul 2009 23:20:50 +0800
Subject: How-to use the sdio driver?
In-Reply-To: <022254FBC8645942BBF88A022862CDD33C60CA@3putt.int.lantronix.com>
References: <022254FBC8645942BBF88A022862CDD33C60BD@3putt.int.lantronix.com>
	<1247152602.23378.3.camel@dhcp-100-3-98.bos.redhat.com>
	<022254FBC8645942BBF88A022862CDD33C60C0@3putt.int.lantronix.com>
	<60ce8d250907102206u75eb40fclbd3f9f6bbfdae765@mail.gmail.com>
	<022254FBC8645942BBF88A022862CDD33C60CA@3putt.int.lantronix.com>
Message-ID: <60ce8d250907140820u60490389q77d16cd38a1495d4@mail.gmail.com>

2009/7/14 Lars Holowko <Lars.Holowko at lantronix.com>:
>
>>> Thanks Dan,
>>>
>>> For the hint concerning debug and the MMC bus. I don't see anything
>>> happening there with my wifi card.
>>>
>>> One source of the problem could be that the MMC slot seems to get
>>> scanned only at boot up. It only recognizes a SD card when it is
>>> already plugged in when the kernel gets booted but not if I plug it
> in later.
>>>
>>> By that time the libertas module is not loaded yet. But when I
>>> configure libertas_sdio to be linked statically, I don't see any
>>> difference either...
>>
>> Which WiFi card are you using?
>> Probably the WiFi card was not properly detected by your SDIO
> controller.
>> Make sure the configuration of your GPIO pin for card detection is
> right.
>> BTW, have you tried pre-plug in the WiFi card before power up the
> board?
>>
>
> I am using a Marvell 88W8686 development board. It has a SD-card style
> connector so I would assume that I won't have to modify any additional
> GPIOs because it would use the same GPIOs as a SD-card in the same slot,
> right? Pre-plugging the WiFi card does not work (no output other then
> that the libertas driver was registered) - as opposed to the SD-card.

There should be a line of message similar as follows shown if your
SDIO card is detected and initialized successful.
mmc0: new SDIO card at address 001
As Dan said , turning on the MMC core debug option may give you more
useful information.
(Make sure the console log level is 8 to display all debug messages)

>>> I also added a couple of printks in
>>> drives/mmc/core/sdio_bus.c:sdio_bus_event and
>>> drives/mmc/core/sdio_bus.c:sdio_bus_probe but they never seem to get
>>> called either - neither with the SD card nor the wireless board. Do
>>> you know who is supposed to call those probe functions?
>
>> sdio_bus_probe will be called by MMC/SDIO Stack once a SDIO function
> and driver are matched on SDIO Bus.
>
> May you point me where this sdio bus scanning/matching is happening? Is
> it mmc_rescan in drivers/mmc/core/core.c ?
The mmc_rescan function will scan the card in slot, for example a SDIO
card,  and then register it into kernel with its function found after
a few basic initialization operations.
After that, when you insmod libertas module, there's a sdio
function(wifi) driver registerred into kernel.
The sdio function and function driver will be matched via some way
predefined for sdio bus.
Please refer to the sdio_bus_type structure in sdio_bus.c for more details.

Regards
Dongas


From Lars.Holowko at lantronix.com  Tue Jul 14 18:23:36 2009
From: Lars.Holowko at lantronix.com (Lars Holowko)
Date: Tue, 14 Jul 2009 15:23:36 -0700
Subject: How-to use the sdio driver?
References: <022254FBC8645942BBF88A022862CDD33C60BD@3putt.int.lantronix.com>
	<1247152602.23378.3.camel@dhcp-100-3-98.bos.redhat.com>
	<022254FBC8645942BBF88A022862CDD33C60C0@3putt.int.lantronix.com>
	<60ce8d250907102206u75eb40fclbd3f9f6bbfdae765@mail.gmail.com>
	<022254FBC8645942BBF88A022862CDD33C60CA@3putt.int.lantronix.com>
	<60ce8d250907140820u60490389q77d16cd38a1495d4@mail.gmail.com>
Message-ID: <022254FBC8645942BBF88A022862CDD33C60CC@3putt.int.lantronix.com>

Thanks Dongas,

>
>> I am using a Marvell 88W8686 development board. It has a SD-card
style 
>> connector so I would assume that I won't have to modify any
additional 
>> GPIOs because it would use the same GPIOs as a SD-card in the same 
>> slot, right? Pre-plugging the WiFi card does not work (no output
other 
>> then that the libertas driver was registered) - as opposed to the
SD-card.
>
>There should be a line of message similar as follows shown if your SDIO
card is detected and initialized successful.
>mmc0: new SDIO card at address 001
>As Dan said , turning on the MMC core debug option may give you more
useful information.
>(Make sure the console log level is 8 to display all debug messages)

No output for the WiFi card - only for the SD card. 
I looked into mmc_rescan in drivers/mmc/core/core.c - the crucial part
seems to be:

...
		/*
		 * First we search for SDIO...
		 */
		err = mmc_send_io_op_cond(host, 0, &ocr);
		if (!err) {
			if (mmc_attach_sdio(host, ocr))
				mmc_power_off(host);
			goto out;
		}
...

mmc_send_io_op_cond returns with -110(ETIMEOUT) - no matter if I have
the SD card or the WiFi card plugged in.

When I recompile core.c with DEBUG enabled I get this output from the
mmc_send_io_op_cond command.
mmc0: starting CMD5 arg 00000000 flags 000002e1
mmc0: req failed (CMD5): -110, retrying...
mmc0: req failed (CMD5): -110, retrying...
mmc0: req failed (CMD5): -110, retrying...
mmc0: req done (CMD5): -110: 00000000 00000000 00000000 00000000

Whereas the SD card related stuff works fine with the SD card plugged
in:

...
		/*
		 * ...then normal SD...
		 */
		err = mmc_send_app_op_cond(host, 0, &ocr);
		if (!err) {
			if (mmc_attach_sd(host, ocr))
				mmc_power_off(host);
			goto out;
		}
...

mmc0: starting CMD55 arg 00000000 flags 000000f5
VFS: Mounted root (jffs2 filesystem) on device 31:1.
mmc0: req done (CMD55): 0: 00400120 00000000 00000000 00000000
Freeing init memory: 116K
mmc0: starting CMD41 arg 00000000 flags 000000e1
mmc0: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc_rescan 13=0
mmc_rescan 14
mmc0: clock 375000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc0: clock 375000Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
mmc0: starting CMD0 arg 00000000 flags 000000c0
mmc0: req done (CMD0): 0: 00ff8000 00000000 00000000 00000000
mmc0: clock 375000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc0: starting CMD8 arg 000001aa flags 000002f5
mmc0: req done (CMD8): -110: 00ff8000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc0: req done (CMD55): 0: 00400120 00000000 00000000 00000000
mmc0: starting CMD41 arg 00300000 flags 000000e1
...

Since the code for mmc_send_app_op_cond and mmc_send_io_op_cond look
very similar, I start to believe that my 2 Wifi boards do not work
propperly in SDIO mode. I will give it another try on a different ARM
board and then switch over to GPIO mode instead.

>> May you point me where this sdio bus scanning/matching is happening? 
>> Is it mmc_rescan in drivers/mmc/core/core.c ?
>The mmc_rescan function will scan the card in slot, for example a SDIO
card,  and then register it into kernel with its function found after a
few basic initialization operations.
>After that, when you insmod libertas module, there's a sdio
>function(wifi) driver registerred into kernel.
>The sdio function and function driver will be matched via some way
predefined for sdio bus.
>Please refer to the sdio_bus_type structure in sdio_bus.c for more
details.

Thanks for clarifying this. I guess until I get something useful from
mmc_rescan, I am stuck...

Thank you so much for your help,

Lars
 
**********************************************************************
This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited.


From buchan at ioniacmhs.org  Wed Jul 15 00:21:54 2009
From: buchan at ioniacmhs.org (Plesant)
Date: Wed, 15 Jul 2009 03:21:54 -0100
Subject: stenches
Message-ID: <restart.NiJg@ioniacmhs.org>

Spatisfy a Woman sexually Using Uniuqe Techniques.www-ze44-com


From klto at zhaw.ch  Thu Jul 16 04:56:57 2009
From: klto at zhaw.ch (Tobias Klauser)
Date: Thu, 16 Jul 2009 10:56:57 +0200
Subject: [PATCH 4/8] libertas: Use %pM conversion specifier
Message-ID: <1247734617-20902-1-git-send-email-klto@zhaw.ch>

Use the %pM conversion specifier for printk instead of print_mac.

Signed-off-by: Tobias Klauser <klto at zhaw.ch>
---
 drivers/net/wireless/libertas/assoc.c |   10 +++-------
 1 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
index b9b3741..a953647 100644
--- a/drivers/net/wireless/libertas/assoc.c
+++ b/drivers/net/wireless/libertas/assoc.c
@@ -129,7 +129,6 @@ static int lbs_set_authentication(struct lbs_private *priv, u8 bssid[6], u8 auth
 {
 	struct cmd_ds_802_11_authenticate cmd;
 	int ret = -1;
-	DECLARE_MAC_BUF(mac);
 
 	lbs_deb_enter(LBS_DEB_JOIN);
 
@@ -138,8 +137,7 @@ static int lbs_set_authentication(struct lbs_private *priv, u8 bssid[6], u8 auth
 
 	cmd.authtype = iw_auth_to_ieee_auth(auth);
 
-	lbs_deb_join("AUTH_CMD: BSSID %s, auth 0x%x\n",
-		print_mac(mac, bssid), cmd.authtype);
+	lbs_deb_join("AUTH_CMD: BSSID %pM, auth 0x%x\n", bssid, cmd.authtype);
 
 	ret = lbs_cmd_with_response(priv, CMD_802_11_AUTHENTICATE, &cmd);
 
@@ -342,8 +340,6 @@ static int lbs_associate(struct lbs_private *priv,
 
 	/* Firmware v9+ indicate authentication suites as a TLV */
 	if (priv->fwrelease >= 0x09000000) {
-		DECLARE_MAC_BUF(mac);
-
 		auth = (struct mrvl_ie_auth_type *) pos;
 		auth->header.type = cpu_to_le16(TLV_TYPE_AUTH_TYPE);
 		auth->header.len = cpu_to_le16(2);
@@ -351,8 +347,8 @@ static int lbs_associate(struct lbs_private *priv,
 		auth->auth = cpu_to_le16(tmpauth);
 		pos += sizeof(auth->header) + 2;
 
-		lbs_deb_join("AUTH_CMD: BSSID %s, auth 0x%x\n",
-			print_mac(mac, bss->bssid), priv->secinfo.auth_mode);
+		lbs_deb_join("AUTH_CMD: BSSID %pM, auth 0x%x\n",
+			bss->bssid, priv->secinfo.auth_mode);
 	}
 
 	/* WPA/WPA2 IEs */
-- 
1.6.0.4



From marek.vasut at gmail.com  Thu Jul 16 13:40:38 2009
From: marek.vasut at gmail.com (Marek Vasut)
Date: Thu, 16 Jul 2009 19:40:38 +0200
Subject: [PATCH] handle broken V4 fw region code shift
Message-ID: <200907161940.38402.marek.vasut@gmail.com>

Hi,

please consider applying/commenting on the following trivial fix. The 
description is in the patch. Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Fix-problem-with-broken-V4-firmware-on-CF8381.patch
Type: text/x-patch
Size: 2088 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20090716/f6ad162b/attachment.bin>

From dcbw at redhat.com  Thu Jul 16 14:21:30 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 16 Jul 2009 14:21:30 -0400
Subject: [PATCH] handle broken V4 fw region code shift
In-Reply-To: <200907161940.38402.marek.vasut@gmail.com>
References: <200907161940.38402.marek.vasut@gmail.com>
Message-ID: <1247768490.24532.6.camel@localhost.localdomain>

On Thu, 2009-07-16 at 19:40 +0200, Marek Vasut wrote:
> Hi,
> 
> please consider applying/commenting on the following trivial fix. The 
> description is in the patch. Thanks.

Please CC to linux-wireless at vger.kernel and I'll ack there so Linville
will pick it up.  Any patch that you consider appropriate for actual
inclusion at the time you send it is better on linux-wireless.
libertas-dev should really be only for hardware/firmware discussions and
not-yet-ready patches.

Thanks!
Dan



From marek.vasut at gmail.com  Thu Jul 16 14:29:30 2009
From: marek.vasut at gmail.com (Marek Vasut)
Date: Thu, 16 Jul 2009 20:29:30 +0200
Subject: [PATCH] handle broken V4 fw region code shift
Message-ID: <200907162029.30829.marek.vasut@gmail.com>

Dne ?t 16. ?ervence 2009 20:21:30 Dan Williams napsal(a):
> On Thu, 2009-07-16 at 19:40 +0200, Marek Vasut wrote:
> > Hi,
> >
> > please consider applying/commenting on the following trivial fix. The
> > description is in the patch. Thanks.
>
> Please CC to linux-wireless at vger.kernel and I'll ack there so Linville
> will pick it up.  Any patch that you consider appropriate for actual
> inclusion at the time you send it is better on linux-wireless.
> libertas-dev should really be only for hardware/firmware discussions and
> not-yet-ready patches.
>
> Thanks!
> Dan

Done, thanks! :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Fix-problem-with-broken-V4-firmware-on-CF8381.patch
Type: text/x-patch
Size: 2088 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20090716/53fbd225/attachment.bin>

From marek.vasut at gmail.com  Thu Jul 16 14:32:00 2009
From: marek.vasut at gmail.com (Marek Vasut)
Date: Thu, 16 Jul 2009 20:32:00 +0200
Subject: [PATCH] handle broken V4 fw region code shift
Message-ID: <200907162032.00777.marek.vasut@gmail.com>

Dne ?t 16. ?ervence 2009 20:21:30 Dan Williams napsal(a):
> On Thu, 2009-07-16 at 19:40 +0200, Marek Vasut wrote:
> > Hi,
> >
> > please consider applying/commenting on the following trivial fix. The
> > description is in the patch. Thanks.
>
> Please CC to linux-wireless at vger.kernel and I'll ack there so Linville
> will pick it up.  Any patch that you consider appropriate for actual
> inclusion at the time you send it is better on linux-wireless.
> libertas-dev should really be only for hardware/firmware discussions and
> not-yet-ready patches.
>
> Thanks!
> Dan

Done, thanks! :-)
(sorry for sending it twice, I missed the address was incomplete in your mail)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Fix-problem-with-broken-V4-firmware-on-CF8381.patch
Type: text/x-patch
Size: 2088 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20090716/b2ea2601/attachment.bin>

From mcgrof at gmail.com  Thu Jul 16 16:11:26 2009
From: mcgrof at gmail.com (Luis R. Rodriguez)
Date: Thu, 16 Jul 2009 13:11:26 -0700
Subject: [PATCH] handle broken V4 fw region code shift
In-Reply-To: <200907162032.00777.marek.vasut@gmail.com>
References: <200907162032.00777.marek.vasut@gmail.com>
Message-ID: <43e72e890907161311m99e454v7daf9c58a340ae77@mail.gmail.com>

On Thu, Jul 16, 2009 at 11:32 AM, Marek Vasut<marek.vasut at gmail.com> wrote:
> Dne ?t 16. ?ervence 2009 20:21:30 Dan Williams napsal(a):
>> On Thu, 2009-07-16 at 19:40 +0200, Marek Vasut wrote:
>> > Hi,
>> >
>> > please consider applying/commenting on the following trivial fix. The
>> > description is in the patch. Thanks.
>>
>> Please CC to linux-wireless at vger.kernel and I'll ack there so Linville
>> will pick it up. ?Any patch that you consider appropriate for actual
>> inclusion at the time you send it is better on linux-wireless.
>> libertas-dev should really be only for hardware/firmware discussions and
>> not-yet-ready patches.
>>
>> Thanks!
>> Dan
>
> Done, thanks! :-)
> (sorry for sending it twice, I missed the address was incomplete in your mail)
>

Please resend inline

 Luis


From marek.vasut at gmail.com  Thu Jul 16 16:29:41 2009
From: marek.vasut at gmail.com (Marek Vasut)
Date: Thu, 16 Jul 2009 22:29:41 +0200
Subject: [PATCH] handle broken V4 fw region code shift
In-Reply-To: <43e72e890907161311m99e454v7daf9c58a340ae77@mail.gmail.com>
References: <200907162032.00777.marek.vasut@gmail.com>
	<43e72e890907161311m99e454v7daf9c58a340ae77@mail.gmail.com>
Message-ID: <200907162229.41697.marek.vasut@gmail.com>

Dne ?t 16. ?ervence 2009 22:11:26 Luis R. Rodriguez napsal(a):
> On Thu, Jul 16, 2009 at 11:32 AM, Marek Vasut<marek.vasut at gmail.com> wrote:
> > Dne ?t 16. ?ervence 2009 20:21:30 Dan Williams napsal(a):
> >> On Thu, 2009-07-16 at 19:40 +0200, Marek Vasut wrote:
> >> > Hi,
> >> >
> >> > please consider applying/commenting on the following trivial fix. The
> >> > description is in the patch. Thanks.
> >>
> >> Please CC to linux-wireless at vger.kernel and I'll ack there so Linville
> >> will pick it up.  Any patch that you consider appropriate for actual
> >> inclusion at the time you send it is better on linux-wireless.
> >> libertas-dev should really be only for hardware/firmware discussions and
> >> not-yet-ready patches.
> >>
> >> Thanks!
> >> Dan
> >
> > Done, thanks! :-)
> > (sorry for sending it twice, I missed the address was incomplete in your
> > mail)
>
> Please resend inline
>
>  Luis

Here you go

From d69e6db9d424e40dade6bbf107dbab2ff4d692d5 Mon Sep 17 00:00:00 2001                            
From: Marek Vasut <marek.vasut at gmail.com>                                                         
Date: Thu, 16 Jul 2009 19:19:53 +0200                                                             
Subject: [PATCH] Fix problem with broken V4 firmware on CF8381                                    

Firmware V4 on CF8381 reports region code shifted by 1 byte to left.
The following patch checks for this and handles it properly.        

Signed-off-by: Marek Vasut <marek.vasut at gmail.com>
---                                               
 drivers/net/wireless/libertas/cmd.c  |    8 +++++++-
 drivers/net/wireless/libertas/defs.h |    2 ++      
 2 files changed, 9 insertions(+), 1 deletions(-)    

diff --git a/drivers/net/wireless/libertas/cmd.c 
b/drivers/net/wireless/libertas/cmd.c
index 01db705..445288d 100644                                                         
--- a/drivers/net/wireless/libertas/cmd.c                                             
+++ b/drivers/net/wireless/libertas/cmd.c                                             
@@ -135,8 +135,14 @@ int lbs_update_hw_spec(struct lbs_private *priv)                 
        /* Clamp region code to 8-bit since FW spec indicates that it should          
         * only ever be 8-bit, even though the field size is 16-bit.  Some 
firmware
         * returns non-zero high 8 bits here.
+        *
+        * Firmware version 4.0.102 used in CF8381 has region code shifted. We
+        * need to check for this problem and handle it properly.
         */
-       priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
+       if (MRVL_FW_MAJOR_REV(priv->fwrelease) == MRVL_FW_V4)
+               priv->regioncode = (le16_to_cpu(cmd.regioncode) >> 8) & 0xFF;
+       else
+               priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;

        for (i = 0; i < MRVDRV_MAX_REGION_CODE; i++) {
                /* use the region code to search for the index */
diff --git a/drivers/net/wireless/libertas/defs.h 
b/drivers/net/wireless/libertas/defs.h
index 48da157..72f3479 100644
--- a/drivers/net/wireless/libertas/defs.h
+++ b/drivers/net/wireless/libertas/defs.h
@@ -234,6 +234,8 @@ static inline void lbs_deb_hex(unsigned int grp, const 
char *prompt, u8 *buf, in
 /** Mesh enable bit in FW capability */
 #define MESH_CAPINFO_ENABLE_MASK                       (1<<16)

+/** FW definition from Marvell v4 */
+#define MRVL_FW_V4                                     (0x04)
 /** FW definition from Marvell v5 */
 #define MRVL_FW_V5                                     (0x05)
 /** FW definition from Marvell v10 */
--
1.6.3.3


From logics at pfa.org.uk  Fri Jul 17 12:09:49 2009
From: logics at pfa.org.uk (Pribnow Muhlhauser)
Date: Fri, 17 Jul 2009 15:09:49 -0100
Subject: yearly
Message-ID: <3901b0ad04e8311f7aa875_incZELgHEL@pfa.org.uk>

Great sex - Better Performance and More Satisfyling Orgasms For Men and Women With These Heerbs!.www[dot]pill84[dot]net


From salic at orga.com.tw  Sun Jul 19 13:55:36 2009
From: salic at orga.com.tw (Estle Morningstar)
Date: Sun, 19 Jul 2009 16:55:36 -0100
Subject: deoxycholate
Message-ID: <4A634F0A_345656@orga.com.tw>

Incyrease Libido -- Herbs For Men and Women to Boost Libido and Satisfaction.www[dot]21113[dot]org


From marek.vasut at gmail.com  Sun Jul 19 13:19:51 2009
From: marek.vasut at gmail.com (Marek Vasut)
Date: Sun, 19 Jul 2009 19:19:51 +0200
Subject: [PATCH] handle broken V4 fw region code shift
In-Reply-To: <200907162229.41697.marek.vasut@gmail.com>
References: <200907162032.00777.marek.vasut@gmail.com>
	<43e72e890907161311m99e454v7daf9c58a340ae77@mail.gmail.com>
	<200907162229.41697.marek.vasut@gmail.com>
Message-ID: <200907191919.51998.marek.vasut@gmail.com>

Dne ?t 16. ?ervence 2009 22:29:41 Marek Vasut napsal(a):
> Dne ?t 16. ?ervence 2009 22:11:26 Luis R. Rodriguez napsal(a):
> > On Thu, Jul 16, 2009 at 11:32 AM, Marek Vasut<marek.vasut at gmail.com> 
wrote:
> > > Dne ?t 16. ?ervence 2009 20:21:30 Dan Williams napsal(a):
> > >> On Thu, 2009-07-16 at 19:40 +0200, Marek Vasut wrote:
> > >> > Hi,
> > >> >
> > >> > please consider applying/commenting on the following trivial fix.
> > >> > The description is in the patch. Thanks.
> > >>
> > >> Please CC to linux-wireless at vger.kernel and I'll ack there so Linville
> > >> will pick it up.  Any patch that you consider appropriate for actual
> > >> inclusion at the time you send it is better on linux-wireless.
> > >> libertas-dev should really be only for hardware/firmware discussions
> > >> and not-yet-ready patches.
> > >>
> > >> Thanks!
> > >> Dan
> > >
> > > Done, thanks! :-)
> > > (sorry for sending it twice, I missed the address was incomplete in
> > > your mail)
> >
> > Please resend inline
> >
> >  Luis
>
> Here you go

Any update ?
>
> From d69e6db9d424e40dade6bbf107dbab2ff4d692d5 Mon Sep 17 00:00:00 2001
> From: Marek Vasut <marek.vasut at gmail.com>
> Date: Thu, 16 Jul 2009 19:19:53 +0200
> Subject: [PATCH] Fix problem with broken V4 firmware on CF8381
>
> Firmware V4 on CF8381 reports region code shifted by 1 byte to left.
> The following patch checks for this and handles it properly.
>
> Signed-off-by: Marek Vasut <marek.vasut at gmail.com>
> ---
>  drivers/net/wireless/libertas/cmd.c  |    8 +++++++-
>  drivers/net/wireless/libertas/defs.h |    2 ++
>  2 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/cmd.c
> b/drivers/net/wireless/libertas/cmd.c
> index 01db705..445288d 100644
> --- a/drivers/net/wireless/libertas/cmd.c
> +++ b/drivers/net/wireless/libertas/cmd.c
> @@ -135,8 +135,14 @@ int lbs_update_hw_spec(struct lbs_private *priv)
>         /* Clamp region code to 8-bit since FW spec indicates that it
> should * only ever be 8-bit, even though the field size is 16-bit.  Some
> firmware
>          * returns non-zero high 8 bits here.
> +        *
> +        * Firmware version 4.0.102 used in CF8381 has region code shifted.
> We +        * need to check for this problem and handle it properly.
>          */
> -       priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
> +       if (MRVL_FW_MAJOR_REV(priv->fwrelease) == MRVL_FW_V4)
> +               priv->regioncode = (le16_to_cpu(cmd.regioncode) >> 8) &
> 0xFF; +       else
> +               priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
>
>         for (i = 0; i < MRVDRV_MAX_REGION_CODE; i++) {
>                 /* use the region code to search for the index */
> diff --git a/drivers/net/wireless/libertas/defs.h
> b/drivers/net/wireless/libertas/defs.h
> index 48da157..72f3479 100644
> --- a/drivers/net/wireless/libertas/defs.h
> +++ b/drivers/net/wireless/libertas/defs.h
> @@ -234,6 +234,8 @@ static inline void lbs_deb_hex(unsigned int grp, const
> char *prompt, u8 *buf, in
>  /** Mesh enable bit in FW capability */
>  #define MESH_CAPINFO_ENABLE_MASK                       (1<<16)
>
> +/** FW definition from Marvell v4 */
> +#define MRVL_FW_V4                                     (0x04)
>  /** FW definition from Marvell v5 */
>  #define MRVL_FW_V5                                     (0x05)
>  /** FW definition from Marvell v10 */
> --
> 1.6.3.3



From dcbw at redhat.com  Tue Jul 21 09:32:35 2009
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 21 Jul 2009 09:32:35 -0400
Subject: [PATCH] handle broken V4 fw region code shift
In-Reply-To: <200907162229.41697.marek.vasut@gmail.com>
References: <200907162032.00777.marek.vasut@gmail.com>
	<43e72e890907161311m99e454v7daf9c58a340ae77@mail.gmail.com>
	<200907162229.41697.marek.vasut@gmail.com>
Message-ID: <1248183155.6558.1.camel@localhost.localdomain>

On Thu, 2009-07-16 at 22:29 +0200, Marek Vasut wrote:
> Dne ?t 16. ?ervence 2009 22:11:26 Luis R. Rodriguez napsal(a):
> > On Thu, Jul 16, 2009 at 11:32 AM, Marek Vasut<marek.vasut at gmail.com> wrote:
> > > Dne ?t 16. ?ervence 2009 20:21:30 Dan Williams napsal(a):
> > >> On Thu, 2009-07-16 at 19:40 +0200, Marek Vasut wrote:
> > >> > Hi,
> > >> >
> > >> > please consider applying/commenting on the following trivial fix. The
> > >> > description is in the patch. Thanks.
> > >>
> > >> Please CC to linux-wireless at vger.kernel and I'll ack there so Linville
> > >> will pick it up.  Any patch that you consider appropriate for actual
> > >> inclusion at the time you send it is better on linux-wireless.
> > >> libertas-dev should really be only for hardware/firmware discussions and
> > >> not-yet-ready patches.
> > >>
> > >> Thanks!
> > >> Dan
> > >
> > > Done, thanks! :-)
> > > (sorry for sending it twice, I missed the address was incomplete in your
> > > mail)
> >
> > Please resend inline
> >
> >  Luis
> 
> Here you go
> 
> From d69e6db9d424e40dade6bbf107dbab2ff4d692d5 Mon Sep 17 00:00:00 2001                            
> From: Marek Vasut <marek.vasut at gmail.com>                                                         
> Date: Thu, 16 Jul 2009 19:19:53 +0200                                                             
> Subject: [PATCH] Fix problem with broken V4 firmware on CF8381                                    
> 
> Firmware V4 on CF8381 reports region code shifted by 1 byte to left.
> The following patch checks for this and handles it properly.        
> 
> Signed-off-by: Marek Vasut <marek.vasut at gmail.com>

Acked-by: Dan Williams <dcbw at redhat.com>

> ---                                               
>  drivers/net/wireless/libertas/cmd.c  |    8 +++++++-
>  drivers/net/wireless/libertas/defs.h |    2 ++      
>  2 files changed, 9 insertions(+), 1 deletions(-)    
> 
> diff --git a/drivers/net/wireless/libertas/cmd.c 
> b/drivers/net/wireless/libertas/cmd.c
> index 01db705..445288d 100644                                                         
> --- a/drivers/net/wireless/libertas/cmd.c                                             
> +++ b/drivers/net/wireless/libertas/cmd.c                                             
> @@ -135,8 +135,14 @@ int lbs_update_hw_spec(struct lbs_private *priv)                 
>         /* Clamp region code to 8-bit since FW spec indicates that it should          
>          * only ever be 8-bit, even though the field size is 16-bit.  Some 
> firmware
>          * returns non-zero high 8 bits here.
> +        *
> +        * Firmware version 4.0.102 used in CF8381 has region code shifted. We
> +        * need to check for this problem and handle it properly.
>          */
> -       priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
> +       if (MRVL_FW_MAJOR_REV(priv->fwrelease) == MRVL_FW_V4)
> +               priv->regioncode = (le16_to_cpu(cmd.regioncode) >> 8) & 0xFF;
> +       else
> +               priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
> 
>         for (i = 0; i < MRVDRV_MAX_REGION_CODE; i++) {
>                 /* use the region code to search for the index */
> diff --git a/drivers/net/wireless/libertas/defs.h 
> b/drivers/net/wireless/libertas/defs.h
> index 48da157..72f3479 100644
> --- a/drivers/net/wireless/libertas/defs.h
> +++ b/drivers/net/wireless/libertas/defs.h
> @@ -234,6 +234,8 @@ static inline void lbs_deb_hex(unsigned int grp, const 
> char *prompt, u8 *buf, in
>  /** Mesh enable bit in FW capability */
>  #define MESH_CAPINFO_ENABLE_MASK                       (1<<16)
> 
> +/** FW definition from Marvell v4 */
> +#define MRVL_FW_V4                                     (0x04)
>  /** FW definition from Marvell v5 */
>  #define MRVL_FW_V5                                     (0x05)
>  /** FW definition from Marvell v10 */
> --
> 1.6.3.3



From praveen at e-consystems.com  Fri Jul 24 07:36:33 2009
From: praveen at e-consystems.com (praveen)
Date: Fri, 24 Jul 2009 17:06:33 +0530
Subject: Reg: Access point association gets down with in 5min for
	MARVELL_SDIO_8688_WLAN_CARD
Message-ID: <200907241706.33789.praveen@e-consystems.com>

Hi All,

I am using MARVELL_SDIO_8688_WLAN_CARD with PXA270 based reference board. I 
used the patch available with this list for 8688 card. 

After inserting the modules I get the following debug messages

[root at REGULUS /tmp]#insmod libertas.ko
[root at REGULUS /tmp]#
[root at REGULUS /tmp]#insmod libertas_sdio.ko
libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
libertas: 00:1a:6b:9f:37:36, fw 10.38.1p25, cap 0x00000303
libertas: PREP_CMD: command 0x0022 failed: 2
libertas: eth1: Marvell WLAN 802.11 adapter
[root at REGULUS /tmp]#
[root at REGULUS /tmp]#
[root at REGULUS /tmp]#

Scanning the access point using iwlist gives following prints. In this all the 
channel and bit rates are wrong. I don't know why?

[root at REGULUS /tmp]#./iwlist eth1 scan
Warning: Driver for device eth1 has been compiled with version 22
of Wireless Extension, while this program supports up to version 17.
Some things may be broken...

eth1      Scan completed :
          Cell 01 - Address: 00:1B:2F:4B:42:16
                    ESSID:"econAP2"
                    Mode:Managed
                    Channel:-2.82593e-07
                    Quality=70/100  Signal level=-75 dBm  Noise level=-92 dBm
                    Encryption key:on
                    Bit Rate:5.29981e-315 Mb/s
                    Bit Rate:5.30499e-315 Mb/s
                    Bit Rate:5.31211e-315 Mb/s
                    Bit Rate:5.31729e-315 Mb/s
                    Bit Rate:5.31276e-315 Mb/s
                    Bit Rate:5.31794e-315 Mb/s
                    Bit Rate:5.32312e-315 Mb/s
                    Bit Rate:5.32636e-315 Mb/s
                    Bit Rate:5.316e-315 Mb/s
                    Bit Rate:5.32118e-315 Mb/s
                    Bit Rate:5.3283e-315 Mb/s
                    Bit Rate:5.32927e-315 Mb/s
          Cell 02 - Address: 00:11:95:76:8F:60
                    ESSID:"econAP1"
                    Mode:Managed
                    Channel:2.05102e-314
                    Quality=100/100  Signal level=-97 dBm  Noise level=-92 dBm
                    Encryption key:on
                    Bit Rate:5.29981e-315 Mb/s
                    Bit Rate:5.30499e-315 Mb/s
                    Bit Rate:5.31211e-315 Mb/s
                    Bit Rate:5.31729e-315 Mb/s
                    Bit Rate:5.31276e-315 Mb/s
                    Bit Rate:5.31794e-315 Mb/s
                    Bit Rate:5.32312e-315 Mb/s
                    Bit Rate:5.32636e-315 Mb/s
                    Bit Rate:5.316e-315 Mb/s
                    Bit Rate:5.32118e-315 Mb/s
                    Bit Rate:5.3283e-315 Mb/s
                    Bit Rate:5.32927e-315 Mb/s
          Cell 03 - Address: 00:1B:57:F1:24:99
                    ESSID:"UTStarcom"
                    Mode:Managed
                    Channel:3.03586e-315
                    Quality=100/100  Signal level=-98 dBm  Noise level=-92 dBm
                    Encryption key:off
                    Bit Rate:5.29981e-315 Mb/s
                    Bit Rate:5.30499e-315 Mb/s
                    Bit Rate:5.31211e-315 Mb/s
                    Bit Rate:5.31729e-315 Mb/s
                    Bit Rate:5.32118e-315 Mb/s
                    Bit Rate:5.32312e-315 Mb/s
                    Bit Rate:5.32636e-315 Mb/s
                    Bit Rate:5.32927e-315 Mb/s
                    Bit Rate:5.31276e-315 Mb/s
                    Bit Rate:5.316e-315 Mb/s
                    Bit Rate:5.31794e-315 Mb/s
                    Bit Rate:5.3283e-315 Mb/s


I established the link with one of my access point using following commands
ifconfig eth1 192.168.6.165 up
./iwconfig eth1 mode 2
./iwconfig eth1 essid "econAP1"
./iwconfig eth1 enc "s:ca188"
./iwconfig eth1 key 0123456789
route add default gw 192.168.6.1 eth1


After giving above commands my board get associated with the access point. See 
the output of below command

[root at REGULUS /tmp]#./iwconfig eth1
Warning: Driver for device eth1 has been compiled with version 22
of Wireless Extension, while this program supports up to version 17.
Some things may be broken...

eth1      IEEE 802.11b/g  ESSID:"econAP1"
          Mode:Managed  Channel:-2.06365e+267  Access Point: 00:11:95:76:8F:60
          Bit Rate:1.63394e-312 2b/s   Tx-Power=15 dBm
          Retry limit:8   RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:0123-4567-89   Security mode:open
          Power Management:off
          Link Quality=12/100  Signal level=-89 dBm  Noise level=-93 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:4496
          Tx excessive retries:6  Invalid misc:16   Missed beacon:0


But with in 5min board lost the association with the access point. Please see 
the output of iwconfig once after association get lost

[root at REGULUS /tmp]#./iwconfig eth1
Warning: Driver for device eth1 has been compiled with version 22
of Wireless Extension, while this program supports up to version 17.
Some things may be broken...

eth1      IEEE 802.11b/g  ESSID:""
          Mode:Managed  Channel:-2.06365e+267  Access Point: 00:00:00:00:00:00
          Bit Rate:2.27054e-312 2b/s   Tx-Power=15 dBm
          Retry limit:8   RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:0123-4567-89   Security mode:open
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:4496
          Tx excessive retries:0  Invalid misc:16   Missed beacon:0

Please give reply for the above issue.

-- 
Thanks and regards,
Praveen


From nephritic at saint-avold.com  Sat Jul 25 03:19:10 2009
From: nephritic at saint-avold.com (Rodenberger)
Date: Sat, 25 Jul 2009 07:19:10 +0000
Subject: rambunctious
Message-ID: <2e09f70f0b91bc$mediatresses@saint-avold.com>

Kama Sutra - The Basics Off Kama Sutra Massaage.www.45meds .net


From roel.kluin at gmail.com  Sat Jul 25 15:58:50 2009
From: roel.kluin at gmail.com (Roel Kluin)
Date: Sat, 25 Jul 2009 21:58:50 +0200
Subject: [PATCH] libertas: Read outside array bounds
Message-ID: <4A6B63FA.4030009@gmail.com>

reads bss->rates[j] before checking bounds of index, and should use
ARRAY_SIZE to determine the size of the array.

Signed-off-by: Roel Kluin <roel.kluin at gmail.com>
---
diff --git a/drivers/net/wireless/libertas/scan.c b/drivers/net/wireless/libertas/scan.c
index 601b542..6c95af3 100644
--- a/drivers/net/wireless/libertas/scan.c
+++ b/drivers/net/wireless/libertas/scan.c
@@ -5,6 +5,7 @@
   *  for sending scan commands to the firmware.
   */
 #include <linux/types.h>
+#include <linux/kernel.h>
 #include <linux/etherdevice.h>
 #include <linux/if_arp.h>
 #include <asm/unaligned.h>
@@ -876,7 +877,7 @@ static inline char *lbs_translate_scan(struct lbs_private *priv,
 	iwe.u.bitrate.disabled = 0;
 	iwe.u.bitrate.value = 0;
 
-	for (j = 0; bss->rates[j] && (j < sizeof(bss->rates)); j++) {
+	for (j = 0; j < ARRAY_SIZE(bss->rates) && bss->rates[j]; j++) {
 		/* Bit rate given in 500 kb/s units */
 		iwe.u.bitrate.value = bss->rates[j] * 500000;
 		current_val = iwe_stream_add_value(info, start, current_val,


From roel.kluin at gmail.com  Sat Jul 25 16:47:22 2009
From: roel.kluin at gmail.com (Roel Kluin)
Date: Sat, 25 Jul 2009 22:47:22 +0200
Subject: [PATCH] libertas: Read buffer overflow
Message-ID: <4A6B6F5A.6070301@gmail.com>

Several arrays were read before checking whether the index was within
bounds. ARRAY_SIZE() should be used to determine the size of arrays.

rates->rates has an arraysize of 1, so calling get_common_rates()
with a rates_size of MAX_RATES (14) was causing reads out of bounds.

Since ratesize is at most MAX_RATES, tmp_size can increment at most
to MAX_RATES * ARRAY_SIZE(lbs_bg_rates), so that should be the number
of elements of tmp[].

Signed-off-by: Roel Kluin <roel.kluin at gmail.com>
---
Please review.

diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
index b9b3741..7dfbb0c 100644
--- a/drivers/net/wireless/libertas/assoc.c
+++ b/drivers/net/wireless/libertas/assoc.c
@@ -1,6 +1,7 @@
 /* Copyright (C) 2006, Red Hat, Inc. */
 
 #include <linux/types.h>
+#include <linux/kernel.h>
 #include <linux/etherdevice.h>
 #include <linux/ieee80211.h>
 #include <linux/if_arp.h>
@@ -43,14 +44,14 @@ static int get_common_rates(struct lbs_private *priv,
 	u16 *rates_size)
 {
 	u8 *card_rates = lbs_bg_rates;
-	size_t num_card_rates = sizeof(lbs_bg_rates);
+	size_t num_card_rates = ARRAY_SIZE(lbs_bg_rates);
 	int ret = 0, i, j;
-	u8 tmp[30];
+	u8 tmp[MAX_RATES * ARRAY_SIZE(lbs_bg_rates)];
 	size_t tmp_size = 0;
 
 	/* For each rate in card_rates that exists in rate1, copy to tmp */
-	for (i = 0; card_rates[i] && (i < num_card_rates); i++) {
-		for (j = 0; rates[j] && (j < *rates_size); j++) {
+	for (i = 0; i < num_card_rates && card_rates[i]; i++) {
+		for (j = 0; j < *rates_size && rates[j]; j++) {
 			if (rates[j] == card_rates[i])
 				tmp[tmp_size++] = card_rates[i];
 		}
@@ -322,7 +323,7 @@ static int lbs_associate(struct lbs_private *priv,
 	rates = (struct mrvl_ie_rates_param_set *) pos;
 	rates->header.type = cpu_to_le16(TLV_TYPE_RATES);
 	memcpy(&rates->rates, &bss->rates, MAX_RATES);
-	tmplen = MAX_RATES;
+	tmplen = min_t(u16, ARRAY_SIZE(rates->rates), MAX_RATES);
 	if (get_common_rates(priv, rates->rates, &tmplen)) {
 		ret = -1;
 		goto done;
@@ -598,7 +599,7 @@ static int lbs_adhoc_join(struct lbs_private *priv,
 
 	/* Copy Data rates from the rates recorded in scan response */
 	memset(cmd.bss.rates, 0, sizeof(cmd.bss.rates));
-	ratesize = min_t(u16, sizeof(cmd.bss.rates), MAX_RATES);
+	ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), MAX_RATES);
 	memcpy(cmd.bss.rates, bss->rates, ratesize);
 	if (get_common_rates(priv, cmd.bss.rates, &ratesize)) {
 		lbs_deb_join("ADHOC_JOIN: get_common_rates returned error.
");


From praveen at e-consystems.com  Mon Jul 27 00:56:18 2009
From: praveen at e-consystems.com (praveen)
Date: Mon, 27 Jul 2009 10:26:18 +0530
Subject: Reg: Access point association gets down with in 5min for
	MARVELL_SDIO_8688_WLAN_CARD
In-Reply-To: <200907241706.33789.praveen@e-consystems.com>
References: <200907241706.33789.praveen@e-consystems.com>
Message-ID: <200907271026.19003.praveen@e-consystems.com>

On Friday 24 July 2009 05:06:33 pm praveen wrote:
> Hi All,
>
> I am using MARVELL_SDIO_8688_WLAN_CARD with PXA270 based reference board. I
> used the patch available with this list for 8688 card.
>
> After inserting the modules I get the following debug messages
>
> [root at REGULUS /tmp]#insmod libertas.ko
> [root at REGULUS /tmp]#
> [root at REGULUS /tmp]#insmod libertas_sdio.ko
> libertas_sdio: Libertas SDIO driver
> libertas_sdio: Copyright Pierre Ossman
> libertas: 00:1a:6b:9f:37:36, fw 10.38.1p25, cap 0x00000303
> libertas: PREP_CMD: command 0x0022 failed: 2
> libertas: eth1: Marvell WLAN 802.11 adapter
> [root at REGULUS /tmp]#
> [root at REGULUS /tmp]#
> [root at REGULUS /tmp]#
>
> Scanning the access point using iwlist gives following prints. In this all
> the channel and bit rates are wrong. I don't know why?
>
> [root at REGULUS /tmp]#./iwlist eth1 scan
> Warning: Driver for device eth1 has been compiled with version 22
> of Wireless Extension, while this program supports up to version 17.
> Some things may be broken...
>
> eth1      Scan completed :
>           Cell 01 - Address: 00:1B:2F:4B:42:16
>                     ESSID:"econAP2"
>                     Mode:Managed
>                     Channel:-2.82593e-07
>                     Quality=70/100  Signal level=-75 dBm  Noise level=-92
> dBm Encryption key:on
>                     Bit Rate:5.29981e-315 Mb/s
>                     Bit Rate:5.30499e-315 Mb/s
>                     Bit Rate:5.31211e-315 Mb/s
>                     Bit Rate:5.31729e-315 Mb/s
>                     Bit Rate:5.31276e-315 Mb/s
>                     Bit Rate:5.31794e-315 Mb/s
>                     Bit Rate:5.32312e-315 Mb/s
>                     Bit Rate:5.32636e-315 Mb/s
>                     Bit Rate:5.316e-315 Mb/s
>                     Bit Rate:5.32118e-315 Mb/s
>                     Bit Rate:5.3283e-315 Mb/s
>                     Bit Rate:5.32927e-315 Mb/s
>           Cell 02 - Address: 00:11:95:76:8F:60
>                     ESSID:"econAP1"
>                     Mode:Managed
>                     Channel:2.05102e-314
>                     Quality=100/100  Signal level=-97 dBm  Noise level=-92
> dBm Encryption key:on
>                     Bit Rate:5.29981e-315 Mb/s
>                     Bit Rate:5.30499e-315 Mb/s
>                     Bit Rate:5.31211e-315 Mb/s
>                     Bit Rate:5.31729e-315 Mb/s
>                     Bit Rate:5.31276e-315 Mb/s
>                     Bit Rate:5.31794e-315 Mb/s
>                     Bit Rate:5.32312e-315 Mb/s
>                     Bit Rate:5.32636e-315 Mb/s
>                     Bit Rate:5.316e-315 Mb/s
>                     Bit Rate:5.32118e-315 Mb/s
>                     Bit Rate:5.3283e-315 Mb/s
>                     Bit Rate:5.32927e-315 Mb/s
>           Cell 03 - Address: 00:1B:57:F1:24:99
>                     ESSID:"UTStarcom"
>                     Mode:Managed
>                     Channel:3.03586e-315
>                     Quality=100/100  Signal level=-98 dBm  Noise level=-92
> dBm Encryption key:off
>                     Bit Rate:5.29981e-315 Mb/s
>                     Bit Rate:5.30499e-315 Mb/s
>                     Bit Rate:5.31211e-315 Mb/s
>                     Bit Rate:5.31729e-315 Mb/s
>                     Bit Rate:5.32118e-315 Mb/s
>                     Bit Rate:5.32312e-315 Mb/s
>                     Bit Rate:5.32636e-315 Mb/s
>                     Bit Rate:5.32927e-315 Mb/s
>                     Bit Rate:5.31276e-315 Mb/s
>                     Bit Rate:5.316e-315 Mb/s
>                     Bit Rate:5.31794e-315 Mb/s
>                     Bit Rate:5.3283e-315 Mb/s
>
>
> I established the link with one of my access point using following commands
> ifconfig eth1 192.168.6.165 up
> ./iwconfig eth1 mode 2
> ./iwconfig eth1 essid "econAP1"
> ./iwconfig eth1 enc "s:ca188"
> ./iwconfig eth1 key 0123456789
> route add default gw 192.168.6.1 eth1
>
>
> After giving above commands my board get associated with the access point.
> See the output of below command
>
> [root at REGULUS /tmp]#./iwconfig eth1
> Warning: Driver for device eth1 has been compiled with version 22
> of Wireless Extension, while this program supports up to version 17.
> Some things may be broken...
>
> eth1      IEEE 802.11b/g  ESSID:"econAP1"
>           Mode:Managed  Channel:-2.06365e+267  Access Point:
> 00:11:95:76:8F:60 Bit Rate:1.63394e-312 2b/s   Tx-Power=15 dBm
>           Retry limit:8   RTS thr=2347 B   Fragment thr=2346 B
>           Encryption key:0123-4567-89   Security mode:open
>           Power Management:off
>           Link Quality=12/100  Signal level=-89 dBm  Noise level=-93 dBm
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:4496
>           Tx excessive retries:6  Invalid misc:16   Missed beacon:0
>
>
> But with in 5min board lost the association with the access point. Please
> see the output of iwconfig once after association get lost
>
> [root at REGULUS /tmp]#./iwconfig eth1
> Warning: Driver for device eth1 has been compiled with version 22
> of Wireless Extension, while this program supports up to version 17.
> Some things may be broken...
>
> eth1      IEEE 802.11b/g  ESSID:""
>           Mode:Managed  Channel:-2.06365e+267  Access Point:
> 00:00:00:00:00:00 Bit Rate:2.27054e-312 2b/s   Tx-Power=15 dBm
>           Retry limit:8   RTS thr=2347 B   Fragment thr=2346 B
>           Encryption key:0123-4567-89   Security mode:open
>           Power Management:off
>           Link Quality:0  Signal level:0  Noise level:0
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:4496
>           Tx excessive retries:0  Invalid misc:16   Missed beacon:0
>
> Please give reply for the above issue.

Hi All,

Can any one help me to solve the above mentioned issue?

-- 
Thanks and regards,
Praveen


From dcbw at redhat.com  Mon Jul 27 12:59:13 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 27 Jul 2009 12:59:13 -0400
Subject: [PATCH] libertas: Read buffer overflow
In-Reply-To: <4A6B6F5A.6070301@gmail.com>
References: <4A6B6F5A.6070301@gmail.com>
Message-ID: <1248713953.17189.14.camel@localhost.localdomain>

On Sat, 2009-07-25 at 22:47 +0200, Roel Kluin wrote:
> Several arrays were read before checking whether the index was within
> bounds. ARRAY_SIZE() should be used to determine the size of arrays.
> 
> rates->rates has an arraysize of 1, so calling get_common_rates()
> with a rates_size of MAX_RATES (14) was causing reads out of bounds.
> 
> Since ratesize is at most MAX_RATES, tmp_size can increment at most
> to MAX_RATES * ARRAY_SIZE(lbs_bg_rates), so that should be the number
> of elements of tmp[].

Please re-post to linux-wireless at vger since that's where it will
actually get acked and picked up by linville.

Thanks,
Dan


> Signed-off-by: Roel Kluin <roel.kluin at gmail.com>
> ---
> Please review.
> 
> diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
> index b9b3741..7dfbb0c 100644
> --- a/drivers/net/wireless/libertas/assoc.c
> +++ b/drivers/net/wireless/libertas/assoc.c
> @@ -1,6 +1,7 @@
>  /* Copyright (C) 2006, Red Hat, Inc. */
>  
>  #include <linux/types.h>
> +#include <linux/kernel.h>
>  #include <linux/etherdevice.h>
>  #include <linux/ieee80211.h>
>  #include <linux/if_arp.h>
> @@ -43,14 +44,14 @@ static int get_common_rates(struct lbs_private *priv,
>  	u16 *rates_size)
>  {
>  	u8 *card_rates = lbs_bg_rates;
> -	size_t num_card_rates = sizeof(lbs_bg_rates);
> +	size_t num_card_rates = ARRAY_SIZE(lbs_bg_rates);
>  	int ret = 0, i, j;
> -	u8 tmp[30];
> +	u8 tmp[MAX_RATES * ARRAY_SIZE(lbs_bg_rates)];
>  	size_t tmp_size = 0;
>  
>  	/* For each rate in card_rates that exists in rate1, copy to tmp */
> -	for (i = 0; card_rates[i] && (i < num_card_rates); i++) {
> -		for (j = 0; rates[j] && (j < *rates_size); j++) {
> +	for (i = 0; i < num_card_rates && card_rates[i]; i++) {
> +		for (j = 0; j < *rates_size && rates[j]; j++) {
>  			if (rates[j] == card_rates[i])
>  				tmp[tmp_size++] = card_rates[i];
>  		}
> @@ -322,7 +323,7 @@ static int lbs_associate(struct lbs_private *priv,
>  	rates = (struct mrvl_ie_rates_param_set *) pos;
>  	rates->header.type = cpu_to_le16(TLV_TYPE_RATES);
>  	memcpy(&rates->rates, &bss->rates, MAX_RATES);
> -	tmplen = MAX_RATES;
> +	tmplen = min_t(u16, ARRAY_SIZE(rates->rates), MAX_RATES);
>  	if (get_common_rates(priv, rates->rates, &tmplen)) {
>  		ret = -1;
>  		goto done;
> @@ -598,7 +599,7 @@ static int lbs_adhoc_join(struct lbs_private *priv,
>  
>  	/* Copy Data rates from the rates recorded in scan response */
>  	memset(cmd.bss.rates, 0, sizeof(cmd.bss.rates));
> -	ratesize = min_t(u16, sizeof(cmd.bss.rates), MAX_RATES);
> +	ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), MAX_RATES);
>  	memcpy(cmd.bss.rates, bss->rates, ratesize);
>  	if (get_common_rates(priv, cmd.bss.rates, &ratesize)) {
>  		lbs_deb_join("ADHOC_JOIN: get_common_rates returned error.
> ");
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From dcbw at redhat.com  Mon Jul 27 12:59:23 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 27 Jul 2009 12:59:23 -0400
Subject: [PATCH] libertas: Read outside array bounds
In-Reply-To: <4A6B63FA.4030009@gmail.com>
References: <4A6B63FA.4030009@gmail.com>
Message-ID: <1248713963.17189.15.camel@localhost.localdomain>

On Sat, 2009-07-25 at 21:58 +0200, Roel Kluin wrote:
> reads bss->rates[j] before checking bounds of index, and should use
> ARRAY_SIZE to determine the size of the array.

Please re-post to linux-wireless at vger since that's where it will
actually get acked and picked up by linville.

Thanks,
Dan

> Signed-off-by: Roel Kluin <roel.kluin at gmail.com>
> ---
> diff --git a/drivers/net/wireless/libertas/scan.c b/drivers/net/wireless/libertas/scan.c
> index 601b542..6c95af3 100644
> --- a/drivers/net/wireless/libertas/scan.c
> +++ b/drivers/net/wireless/libertas/scan.c
> @@ -5,6 +5,7 @@
>    *  for sending scan commands to the firmware.
>    */
>  #include <linux/types.h>
> +#include <linux/kernel.h>
>  #include <linux/etherdevice.h>
>  #include <linux/if_arp.h>
>  #include <asm/unaligned.h>
> @@ -876,7 +877,7 @@ static inline char *lbs_translate_scan(struct lbs_private *priv,
>  	iwe.u.bitrate.disabled = 0;
>  	iwe.u.bitrate.value = 0;
>  
> -	for (j = 0; bss->rates[j] && (j < sizeof(bss->rates)); j++) {
> +	for (j = 0; j < ARRAY_SIZE(bss->rates) && bss->rates[j]; j++) {
>  		/* Bit rate given in 500 kb/s units */
>  		iwe.u.bitrate.value = bss->rates[j] * 500000;
>  		current_val = iwe_stream_add_value(info, start, current_val,
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From roel.kluin at gmail.com  Tue Jul 28 03:59:47 2009
From: roel.kluin at gmail.com (Roel Kluin)
Date: Tue, 28 Jul 2009 09:59:47 +0200
Subject: [PATCH] libertas: Read outside array bounds
Message-ID: <4A6EAFF3.8050502@gmail.com>

reads bss->rates[j] before checking bounds of index, and should use
ARRAY_SIZE to determine the size of the array.

Signed-off-by: Roel Kluin <roel.kluin at gmail.com>
---
diff --git a/drivers/net/wireless/libertas/scan.c b/drivers/net/wireless/libertas/scan.c
index 601b542..6c95af3 100644
--- a/drivers/net/wireless/libertas/scan.c
+++ b/drivers/net/wireless/libertas/scan.c
@@ -5,6 +5,7 @@
   *  for sending scan commands to the firmware.
   */
 #include <linux/types.h>
+#include <linux/kernel.h>
 #include <linux/etherdevice.h>
 #include <linux/if_arp.h>
 #include <asm/unaligned.h>
@@ -876,7 +877,7 @@ static inline char *lbs_translate_scan(struct lbs_private *priv,
 	iwe.u.bitrate.disabled = 0;
 	iwe.u.bitrate.value = 0;
 
-	for (j = 0; bss->rates[j] && (j < sizeof(bss->rates)); j++) {
+	for (j = 0; j < ARRAY_SIZE(bss->rates) && bss->rates[j]; j++) {
 		/* Bit rate given in 500 kb/s units */
 		iwe.u.bitrate.value = bss->rates[j] * 500000;
 		current_val = iwe_stream_add_value(info, start, current_val,


From roel.kluin at gmail.com  Tue Jul 28 04:00:13 2009
From: roel.kluin at gmail.com (Roel Kluin)
Date: Tue, 28 Jul 2009 10:00:13 +0200
Subject: [PATCH] libertas: Read buffer overflow
Message-ID: <4A6EB00D.5010401@gmail.com>

Several arrays were read before checking whether the index was within
bounds. ARRAY_SIZE() should be used to determine the size of arrays.

rates->rates has an arraysize of 1, so calling get_common_rates()
with a rates_size of MAX_RATES (14) was causing reads out of bounds.

Since ratesize is at most MAX_RATES, tmp_size can increment at most
to MAX_RATES * ARRAY_SIZE(lbs_bg_rates), so that should be the number
of elements of tmp[].

Signed-off-by: Roel Kluin <roel.kluin at gmail.com>
---
Please review.

diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
index b9b3741..7dfbb0c 100644
--- a/drivers/net/wireless/libertas/assoc.c
+++ b/drivers/net/wireless/libertas/assoc.c
@@ -1,6 +1,7 @@
 /* Copyright (C) 2006, Red Hat, Inc. */
 
 #include <linux/types.h>
+#include <linux/kernel.h>
 #include <linux/etherdevice.h>
 #include <linux/ieee80211.h>
 #include <linux/if_arp.h>
@@ -43,14 +44,14 @@ static int get_common_rates(struct lbs_private *priv,
 	u16 *rates_size)
 {
 	u8 *card_rates = lbs_bg_rates;
-	size_t num_card_rates = sizeof(lbs_bg_rates);
+	size_t num_card_rates = ARRAY_SIZE(lbs_bg_rates);
 	int ret = 0, i, j;
-	u8 tmp[30];
+	u8 tmp[MAX_RATES * ARRAY_SIZE(lbs_bg_rates)];
 	size_t tmp_size = 0;
 
 	/* For each rate in card_rates that exists in rate1, copy to tmp */
-	for (i = 0; card_rates[i] && (i < num_card_rates); i++) {
-		for (j = 0; rates[j] && (j < *rates_size); j++) {
+	for (i = 0; i < num_card_rates && card_rates[i]; i++) {
+		for (j = 0; j < *rates_size && rates[j]; j++) {
 			if (rates[j] == card_rates[i])
 				tmp[tmp_size++] = card_rates[i];
 		}
@@ -322,7 +323,7 @@ static int lbs_associate(struct lbs_private *priv,
 	rates = (struct mrvl_ie_rates_param_set *) pos;
 	rates->header.type = cpu_to_le16(TLV_TYPE_RATES);
 	memcpy(&rates->rates, &bss->rates, MAX_RATES);
-	tmplen = MAX_RATES;
+	tmplen = min_t(u16, ARRAY_SIZE(rates->rates), MAX_RATES);
 	if (get_common_rates(priv, rates->rates, &tmplen)) {
 		ret = -1;
 		goto done;
@@ -598,7 +599,7 @@ static int lbs_adhoc_join(struct lbs_private *priv,
 
 	/* Copy Data rates from the rates recorded in scan response */
 	memset(cmd.bss.rates, 0, sizeof(cmd.bss.rates));
-	ratesize = min_t(u16, sizeof(cmd.bss.rates), MAX_RATES);
+	ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), MAX_RATES);
 	memcpy(cmd.bss.rates, bss->rates, ratesize);
 	if (get_common_rates(priv, cmd.bss.rates, &ratesize)) {
 		lbs_deb_join("ADHOC_JOIN: get_common_rates returned error.
");


From hs4233 at mail.mn-solutions.de  Tue Jul 28 04:13:43 2009
From: hs4233 at mail.mn-solutions.de (Holger Schurig)
Date: Tue, 28 Jul 2009 10:13:43 +0200
Subject: [PATCH] libertas: Read outside array bounds
In-Reply-To: <4A6EAFF3.8050502@gmail.com>
References: <4A6EAFF3.8050502@gmail.com>
Message-ID: <200907281013.44110.hs4233@mail.mn-solutions.de>

Acked-by: Holger Schurig <hs4233 at mail.mn-solutions.de>

-- 
http://www.holgerschurig.de


From hs4233 at mail.mn-solutions.de  Tue Jul 28 04:19:56 2009
From: hs4233 at mail.mn-solutions.de (Holger Schurig)
Date: Tue, 28 Jul 2009 10:19:56 +0200
Subject: [PATCH] libertas: Read buffer overflow
In-Reply-To: <4A6EB00D.5010401@gmail.com>
References: <4A6EB00D.5010401@gmail.com>
Message-ID: <200907281019.56855.hs4233@mail.mn-solutions.de>

> -	size_t num_card_rates = sizeof(lbs_bg_rates);
> +	size_t num_card_rates = ARRAY_SIZE(lbs_bg_rates);

Hmm, not sure about this.  First I don't know if we need a 
variable for this at all. Can't you simply use ARRAY_SIZE() 
whenever it's needed?

If you want to keep num_card_rates, you should change it's 
type. "size_t" is normally used to denote sizes in bytes, e.g. 
it's the type for the length of malloc and friends. But now the 
variable holds a number of elements and should be int or 
unsigned int.

-- 
http://www.holgerschurig.de


From roel.kluin at gmail.com  Tue Jul 28 06:05:00 2009
From: roel.kluin at gmail.com (Roel Kluin)
Date: Tue, 28 Jul 2009 12:05:00 +0200
Subject: [PATCH] libertas: Read buffer overflow
In-Reply-To: <200907281019.56855.hs4233@mail.mn-solutions.de>
References: <4A6EB00D.5010401@gmail.com>
	<200907281019.56855.hs4233@mail.mn-solutions.de>
Message-ID: <4A6ECD4C.2040101@gmail.com>

Several arrays were read before checking whether the index was within
bounds. ARRAY_SIZE() should be used to determine the size of arrays.

rates->rates has an arraysize of 1, so calling get_common_rates()
with a rates_size of MAX_RATES (14) was causing reads out of bounds.

tmp_size can increment at most to (ARRAY_SIZE(lbs_bg_rates) - 1) *
(*rates_size - 1), so that should be the number of elements of tmp[].

A goto can be eliminated: ret was already set upon its declaration.

Signed-off-by: Roel Kluin <roel.kluin at gmail.com>
---
Op 28-07-09 10:19, Holger Schurig schreef:
>> -	size_t num_card_rates = sizeof(lbs_bg_rates);
>> +	size_t num_card_rates = ARRAY_SIZE(lbs_bg_rates);
> 
> Hmm, not sure about this.  First I don't know if we need a 
> variable for this at all. Can't you simply use ARRAY_SIZE() 
> whenever it's needed?

Of course. Please note the additional changes.

diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
index b9b3741..d699737 100644
--- a/drivers/net/wireless/libertas/assoc.c
+++ b/drivers/net/wireless/libertas/assoc.c
@@ -1,6 +1,7 @@
 /* Copyright (C) 2006, Red Hat, Inc. */
 
 #include <linux/types.h>
+#include <linux/kernel.h>
 #include <linux/etherdevice.h>
 #include <linux/ieee80211.h>
 #include <linux/if_arp.h>
@@ -43,21 +44,21 @@ static int get_common_rates(struct lbs_private *priv,
 	u16 *rates_size)
 {
 	u8 *card_rates = lbs_bg_rates;
-	size_t num_card_rates = sizeof(lbs_bg_rates);
 	int ret = 0, i, j;
-	u8 tmp[30];
+	u8 tmp[(ARRAY_SIZE(lbs_bg_rates) - 1) * (*rates_size - 1)];
 	size_t tmp_size = 0;
 
 	/* For each rate in card_rates that exists in rate1, copy to tmp */
-	for (i = 0; card_rates[i] && (i < num_card_rates); i++) {
-		for (j = 0; rates[j] && (j < *rates_size); j++) {
+	for (i = 0; i < ARRAY_SIZE(lbs_bg_rates) && card_rates[i]; i++) {
+		for (j = 0; j < *rates_size && rates[j]; j++) {
 			if (rates[j] == card_rates[i])
 				tmp[tmp_size++] = card_rates[i];
 		}
 	}
 
 	lbs_deb_hex(LBS_DEB_JOIN, "AP rates    ", rates, *rates_size);
-	lbs_deb_hex(LBS_DEB_JOIN, "card rates  ", card_rates, num_card_rates);
+	lbs_deb_hex(LBS_DEB_JOIN, "card rates  ", card_rates,
+			ARRAY_SIZE(lbs_bg_rates));
 	lbs_deb_hex(LBS_DEB_JOIN, "common rates", tmp, tmp_size);
 	lbs_deb_join("TX data rate 0x%02x\n", priv->cur_rate);
 
@@ -69,10 +70,7 @@ static int get_common_rates(struct lbs_private *priv,
 		lbs_pr_alert("Previously set fixed data rate %#x isn't "
 		       "compatible with the network.\n", priv->cur_rate);
 		ret = -1;
-		goto done;
 	}
-	ret = 0;
-
 done:
 	memset(rates, 0, *rates_size);
 	*rates_size = min_t(int, tmp_size, *rates_size);
@@ -322,7 +320,7 @@ static int lbs_associate(struct lbs_private *priv,
 	rates = (struct mrvl_ie_rates_param_set *) pos;
 	rates->header.type = cpu_to_le16(TLV_TYPE_RATES);
 	memcpy(&rates->rates, &bss->rates, MAX_RATES);
-	tmplen = MAX_RATES;
+	tmplen = min_t(u16, ARRAY_SIZE(rates->rates), MAX_RATES);
 	if (get_common_rates(priv, rates->rates, &tmplen)) {
 		ret = -1;
 		goto done;
@@ -598,7 +596,7 @@ static int lbs_adhoc_join(struct lbs_private *priv,
 
 	/* Copy Data rates from the rates recorded in scan response */
 	memset(cmd.bss.rates, 0, sizeof(cmd.bss.rates));
-	ratesize = min_t(u16, sizeof(cmd.bss.rates), MAX_RATES);
+	ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), MAX_RATES);
 	memcpy(cmd.bss.rates, bss->rates, ratesize);
 	if (get_common_rates(priv, cmd.bss.rates, &ratesize)) {
 		lbs_deb_join("ADHOC_JOIN: get_common_rates returned error.\n");


From dzzxcysyampaArnold at mgt.at  Tue Jul 28 10:09:30 2009
From: dzzxcysyampaArnold at mgt.at (King bonze)
Date: 28 Jul 2009 22:09:30 +0800
Subject: doctor data
Message-ID: <123-5689FC04BEAIhJP00000574@123-5689fc04bea>




Package pricing available for our USA Medical Marketing Lists. Discounts are over 50%. Reply to: Odell at list4discount.net for the datacard.























rembox at list4discount.net to be erased from this campaign



From dcbw at redhat.com  Tue Jul 28 16:22:54 2009
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 28 Jul 2009 16:22:54 -0400
Subject: [PATCH] libertas: Read outside array bounds
In-Reply-To: <4A6EAFF3.8050502@gmail.com>
References: <4A6EAFF3.8050502@gmail.com>
Message-ID: <1248812574.2115.0.camel@localhost.localdomain>

On Tue, 2009-07-28 at 09:59 +0200, Roel Kluin wrote:
> reads bss->rates[j] before checking bounds of index, and should use
> ARRAY_SIZE to determine the size of the array.
> 
> Signed-off-by: Roel Kluin <roel.kluin at gmail.com>

Acked-by: Dan Williams <dcbw at redhat.com>

> ---
> diff --git a/drivers/net/wireless/libertas/scan.c b/drivers/net/wireless/libertas/scan.c
> index 601b542..6c95af3 100644
> --- a/drivers/net/wireless/libertas/scan.c
> +++ b/drivers/net/wireless/libertas/scan.c
> @@ -5,6 +5,7 @@
>    *  for sending scan commands to the firmware.
>    */
>  #include <linux/types.h>
> +#include <linux/kernel.h>
>  #include <linux/etherdevice.h>
>  #include <linux/if_arp.h>
>  #include <asm/unaligned.h>
> @@ -876,7 +877,7 @@ static inline char *lbs_translate_scan(struct lbs_private *priv,
>  	iwe.u.bitrate.disabled = 0;
>  	iwe.u.bitrate.value = 0;
>  
> -	for (j = 0; bss->rates[j] && (j < sizeof(bss->rates)); j++) {
> +	for (j = 0; j < ARRAY_SIZE(bss->rates) && bss->rates[j]; j++) {
>  		/* Bit rate given in 500 kb/s units */
>  		iwe.u.bitrate.value = bss->rates[j] * 500000;
>  		current_val = iwe_stream_add_value(info, start, current_val,



From tharvey at irobot.com  Wed Jul 29 12:59:51 2009
From: tharvey at irobot.com (Tim Harvey)
Date: Wed, 29 Jul 2009 09:59:51 -0700
Subject: GSPI and SDIO performance for 8686
Message-ID: <4A708007.40602@irobot.com>

Greetings,

I've seen a lot of activity lately and development of the GSPI interface 
for libertas.  What max throughput have people been able to get with an 
8686 talking over GSPI?

My previous evaluation with an 8686 talking over SDIO (both to an i.MX31 
SDHC on a patched 2.6.22 and to an OMAP3x SDHC on 2.6.28 beagleboard) 
showed a horribly slow max throughput of about 1.4mbps.  Has anyone seen 
better performance in recent libertas/kernel with the OMAP3x SDHC (ie 
talking to the 8686 on an Overo Fire/Air)?

Thanks,

Tim


From dcbw at redhat.com  Wed Jul 29 13:59:21 2009
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 29 Jul 2009 13:59:21 -0400
Subject: GSPI and SDIO performance for 8686
In-Reply-To: <4A708007.40602@irobot.com>
References: <4A708007.40602@irobot.com>
Message-ID: <1248890361.13682.11.camel@localhost.localdomain>

On Wed, 2009-07-29 at 09:59 -0700, Tim Harvey wrote:
> Greetings,
> 
> I've seen a lot of activity lately and development of the GSPI interface 
> for libertas.  What max throughput have people been able to get with an 
> 8686 talking over GSPI?
> 
> My previous evaluation with an 8686 talking over SDIO (both to an i.MX31 
> SDHC on a patched 2.6.22 and to an OMAP3x SDHC on 2.6.28 beagleboard) 
> showed a horribly slow max throughput of about 1.4mbps.  Has anyone seen 
> better performance in recent libertas/kernel with the OMAP3x SDHC (ie 
> talking to the 8686 on an Overo Fire/Air)?

Any horrible SDIO performance you've seen has got to be dependent on
either HZ or the SDHC.  I've routinely pulled 11 or 12 Mbps with normal
laptop Ricoh R5C822 controllers.  Now maybe there's scheduling latency
or something in the libertas code that erroneously ratelimits related to
HZ, but we know we can pull respectable rates out of the card if the
SDHC doesn't suck.  So we've got a baseline.  At this point, I suspect
the host controller and platform code more than I suspect the libertas
driver or the 8686 chip/firmware given this baseline.

Dan




From andrey at cozybit.com  Wed Jul 29 14:16:21 2009
From: andrey at cozybit.com (Andrey Yurovsky)
Date: Wed, 29 Jul 2009 11:16:21 -0700
Subject: GSPI and SDIO performance for 8686
In-Reply-To: <4A708007.40602@irobot.com>
References: <4A708007.40602@irobot.com>
Message-ID: <45e8e6c40907291116m27247c86v44d21f8b9fa2cab4@mail.gmail.com>

On Wed, Jul 29, 2009 at 9:59 AM, Tim Harvey<tharvey at irobot.com> wrote:
> Greetings,
>
> I've seen a lot of activity lately and development of the GSPI interface for
> libertas. ?What max throughput have people been able to get with an 8686
> talking over GSPI?

We typically see 10mpbs UDP / 7mbps TCP with GSPI on Blackfin, and we
can get higher throughput when using a different SPI host controller.
I posted an RFC patch a while back that will further improve
throughput (and simplify the driver) but it needs more work, for now
throughput is reasonable but there's definitely room for improvement.

> My previous evaluation with an 8686 talking over SDIO (both to an i.MX31
> SDHC on a patched 2.6.22 and to an OMAP3x SDHC on 2.6.28 beagleboard) showed
> a horribly slow max throughput of about 1.4mbps. ?Has anyone seen better
> performance in recent libertas/kernel with the OMAP3x SDHC (ie talking to
> the 8686 on an Overo Fire/Air)?

We've seen 21mpbs UDP and about 19mbps TCP on a ThinkPad with the
Richoh SDHCI controller.  1.4mbps seems suspicious to me, perhaps it's
a host controller issue?

  -Andrey


From tharvey at irobot.com  Wed Jul 29 17:13:36 2009
From: tharvey at irobot.com (Tim Harvey)
Date: Wed, 29 Jul 2009 14:13:36 -0700
Subject: GSPI and SDIO performance for 8686
In-Reply-To: <1248890361.13682.11.camel@localhost.localdomain>
References: <4A708007.40602@irobot.com>
	<1248890361.13682.11.camel@localhost.localdomain>
Message-ID: <4A70BB80.8060802@irobot.com>

Dan Williams wrote:
> On Wed, 2009-07-29 at 09:59 -0700, Tim Harvey wrote:
>   
>> Greetings,
>>
>> I've seen a lot of activity lately and development of the GSPI interface 
>> for libertas.  What max throughput have people been able to get with an 
>> 8686 talking over GSPI?
>>
>> My previous evaluation with an 8686 talking over SDIO (both to an i.MX31 
>> SDHC on a patched 2.6.22 and to an OMAP3x SDHC on 2.6.28 beagleboard) 
>> showed a horribly slow max throughput of about 1.4mbps.  Has anyone seen 
>> better performance in recent libertas/kernel with the OMAP3x SDHC (ie 
>> talking to the 8686 on an Overo Fire/Air)?
>>     
>
> Any horrible SDIO performance you've seen has got to be dependent on
> either HZ or the SDHC.  I've routinely pulled 11 or 12 Mbps with normal
> laptop Ricoh R5C822 controllers.  Now maybe there's scheduling latency
> or something in the libertas code that erroneously ratelimits related to
> HZ, but we know we can pull respectable rates out of the card if the
> SDHC doesn't suck.  So we've got a baseline.  At this point, I suspect
> the host controller and platform code more than I suspect the libertas
> driver or the 8686 chip/firmware given this baseline.
>
> Dan
>
>
>   

I would agree the horrible SDIO performance is related to SDHC.  The 
only people claiming ~10mbps have been using the PCI based Richoh 
SDHCI.  Has anyone seen > ~1.5mbps using SDIO on any ARM platform?   The 
i.MX31 SDHC I tesed a year ago was severely limited - only would do 1bit 
SDIO and required 4-byte algined transfers.  The beagleboard I tested 
about 6 months ago with the OMAP3x SDHC would apparently do 4-bit SDIO 
but still showed the same performance.

Tim

Tim


From dcbw at redhat.com  Thu Jul 30 08:58:15 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 30 Jul 2009 08:58:15 -0400
Subject: GSPI and SDIO performance for 8686
In-Reply-To: <4A70BB80.8060802@irobot.com>
References: <4A708007.40602@irobot.com>
	<1248890361.13682.11.camel@localhost.localdomain>
	<4A70BB80.8060802@irobot.com>
Message-ID: <1248958695.9457.16.camel@localhost.localdomain>

On Wed, 2009-07-29 at 14:13 -0700, Tim Harvey wrote:
> Dan Williams wrote:
> > On Wed, 2009-07-29 at 09:59 -0700, Tim Harvey wrote:
> >   
> >> Greetings,
> >>
> >> I've seen a lot of activity lately and development of the GSPI interface 
> >> for libertas.  What max throughput have people been able to get with an 
> >> 8686 talking over GSPI?
> >>
> >> My previous evaluation with an 8686 talking over SDIO (both to an i.MX31 
> >> SDHC on a patched 2.6.22 and to an OMAP3x SDHC on 2.6.28 beagleboard) 
> >> showed a horribly slow max throughput of about 1.4mbps.  Has anyone seen 
> >> better performance in recent libertas/kernel with the OMAP3x SDHC (ie 
> >> talking to the 8686 on an Overo Fire/Air)?
> >>     
> >
> > Any horrible SDIO performance you've seen has got to be dependent on
> > either HZ or the SDHC.  I've routinely pulled 11 or 12 Mbps with normal
> > laptop Ricoh R5C822 controllers.  Now maybe there's scheduling latency
> > or something in the libertas code that erroneously ratelimits related to
> > HZ, but we know we can pull respectable rates out of the card if the
> > SDHC doesn't suck.  So we've got a baseline.  At this point, I suspect
> > the host controller and platform code more than I suspect the libertas
> > driver or the 8686 chip/firmware given this baseline.
> >
> > Dan
> >
> >
> >   
> 
> I would agree the horrible SDIO performance is related to SDHC.  The 
> only people claiming ~10mbps have been using the PCI based Richoh 
> SDHCI.  Has anyone seen > ~1.5mbps using SDIO on any ARM platform?   The 
> i.MX31 SDHC I tesed a year ago was severely limited - only would do 1bit 
> SDIO and required 4-byte algined transfers.  The beagleboard I tested 
> about 6 months ago with the OMAP3x SDHC would apparently do 4-bit SDIO 
> but still showed the same performance.

There was a thing a while ago where when HZ was 250 or something like
that, the performance dropped by 4 due to scheduling delays (because the
packet worker wouldn't get rescheduled until HZ), but I think we killed
that a few kernel versions ago.  What's your HZ value, or are you using
"tickless" kernels?

I'm pretty sure that the kernels I've tested the Ricoh PCI controller on
are all tickless and thus HZ doesn't matter for me.  See the thread
"SDIO Performance once again" from somewhere around Jan/Feb 2009.

Dan




From dongas86 at gmail.com  Thu Jul 30 09:44:44 2009
From: dongas86 at gmail.com (Dongas)
Date: Thu, 30 Jul 2009 21:44:44 +0800
Subject: GSPI and SDIO performance for 8686
In-Reply-To: <4A70BB80.8060802@irobot.com>
References: <4A708007.40602@irobot.com>
	<1248890361.13682.11.camel@localhost.localdomain>
	<4A70BB80.8060802@irobot.com>
Message-ID: <60ce8d250907300644l69d2f70bv469045e0ef74a897@mail.gmail.com>

2009/7/30, Tim Harvey <tharvey at irobot.com>:
> Dan Williams wrote:
> > On Wed, 2009-07-29 at 09:59 -0700, Tim Harvey wrote:
> >
> >
> > > Greetings,
> > >
> > > I've seen a lot of activity lately and development of the GSPI interface
> for libertas.  What max throughput have people been able to get with an 8686
> talking over GSPI?
> > >
> > > My previous evaluation with an 8686 talking over SDIO (both to an i.MX31
> SDHC on a patched 2.6.22 and to an OMAP3x SDHC on 2.6.28 beagleboard) showed
> a horribly slow max throughput of about 1.4mbps.  Has anyone seen better
> performance in recent libertas/kernel with the OMAP3x SDHC (ie talking to
> the 8686 on an Overo Fire/Air)?
> > >
> > >
> >
> > Any horrible SDIO performance you've seen has got to be dependent on
> > either HZ or the SDHC.  I've routinely pulled 11 or 12 Mbps with normal
> > laptop Ricoh R5C822 controllers.  Now maybe there's scheduling latency
> > or something in the libertas code that erroneously ratelimits related to
> > HZ, but we know we can pull respectable rates out of the card if the
> > SDHC doesn't suck.  So we've got a baseline.  At this point, I suspect
> > the host controller and platform code more than I suspect the libertas
> > driver or the 8686 chip/firmware given this baseline.
> >
> > Dan
> >
> >
> >
> >
>
> I would agree the horrible SDIO performance is related to SDHC.  The only
> people claiming ~10mbps have been using the PCI based Richoh SDHCI.  Has
> anyone seen > ~1.5mbps using SDIO on any ARM platform?   The i.MX31 SDHC I
> tesed a year ago was severely limited - only would do 1bit SDIO and required
> 4-byte algined transfers.  The beagleboard I tested about 6 months ago with
> the OMAP3x SDHC would apparently do 4-bit SDIO but still showed the same
> performance.
>

You may get such poor performance if you are using polling mode to
handle SDIO interrupts.
Would you check if the host controller driver you tested supports sdio
interrupt well and it is enabled?

Regards
Dongas


From claud_yu at yahoo.com.tw  Thu Jul 30 18:44:16 2009
From: claud_yu at yahoo.com.tw (claud_yu)
Date: Fri, 31 Jul 2009 06:44:16 +0800 (CST)
Subject: =?utf-8?B?UkXvvJogR1NQSSBhbmQgU0RJTyBwZXJmb3JtYW5jZSBmb3IgODY4Ng==?=
In-Reply-To: <4A708007.40602@irobot.com>
Message-ID: <995589.5009.qm@web72207.mail.tp2.yahoo.com>

hi Harvey, 

The iMX31 and OMAP3530 MMC host driver don't claim the host or driver  have capacity to handle SDIO irq. And SDIO stack use polling mechanism to deal with sdio irq. And pool performance (~1Mb/s) is reasonable. The Ricon (sdhci) or PXA mmc driver have the SDIO_IRQ capacity , and the performance will be up to ~20Mb. 

I evaluate GSPI mode the iMX31 SPI interface , and get reasonable performance to me (9~10Mb) at 15Mhz SPI clock.


Claud Yu

--- 09/7/30 (?)?Tim Harvey <tharvey at irobot.com> ???

> ???: Tim Harvey <tharvey at irobot.com>
> ??: GSPI and SDIO performance for 8686
> ???: libertas-dev at lists.infradead.org
> ??: 2009?7?30?,?,??12:59
> Greetings,
> 
> I've seen a lot of activity lately and development of the
> GSPI interface for libertas.? What max throughput have
> people been able to get with an 8686 talking over GSPI?
> 
> My previous evaluation with an 8686 talking over SDIO (both
> to an i.MX31 SDHC on a patched 2.6.22 and to an OMAP3x SDHC
> on 2.6.28 beagleboard) showed a horribly slow max throughput
> of about 1.4mbps.? Has anyone seen better performance
> in recent libertas/kernel with the OMAP3x SDHC (ie talking
> to the 8686 on an Overo Fire/Air)?
> 
> Thanks,
> 
> Tim
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev
> 


      ______________________________________________________________________________________________________
?????????Yahoo!??????2.0????????????? http://tw.mg0.mail.yahoo.com/dc/landing


From bzhao at marvell.com  Fri Jul 31 23:02:19 2009
From: bzhao at marvell.com (Bing Zhao)
Date: Fri, 31 Jul 2009 20:02:19 -0700
Subject: [PATCH] libertas: Fix WEP association failure with open source
	wpa_supplicant 0.5.10
Message-ID: <1249095739-7908-1-git-send-email-bzhao@marvell.com>

From: Maithili Hinge <maithili at marvell.com>

From: Maithili Hinge <maithili at marvell.com>

Add code to handle IW_AUTH_PRIVACY_INVOKED and IW_AUTH_RX_UNENCRYPTED_EAPOL
cases in lbs_set_auth() function in libertas code.

Signed-off-by: Maithili Hinge <maithili at marvell.com>
Signed-off-by: Bing Zhao <bzhao at marvell.com>
---
 drivers/net/wireless/libertas/wext.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/libertas/wext.c b/drivers/net/wireless/libertas/wext.c
index e96451c..be837a0 100644
--- a/drivers/net/wireless/libertas/wext.c
+++ b/drivers/net/wireless/libertas/wext.c
@@ -1728,6 +1728,8 @@ static int lbs_set_auth(struct net_device *dev,
 	}
 
 	switch (dwrq->flags & IW_AUTH_INDEX) {
+	case IW_AUTH_PRIVACY_INVOKED:
+	case IW_AUTH_RX_UNENCRYPTED_EAPOL:
 	case IW_AUTH_TKIP_COUNTERMEASURES:
 	case IW_AUTH_CIPHER_PAIRWISE:
 	case IW_AUTH_CIPHER_GROUP:
-- 
1.5.3.4


