From George.Shore at imgtec.com  Mon Nov  2 08:59:25 2009
From: George.Shore at imgtec.com (George Shore)
Date: Mon, 2 Nov 2009 13:59:25 -0000
Subject: [PATCH] libertas: remove internal buffers from GSPI driver
In-Reply-To: <45e8e6c40910291048g2958c086oa6b7a39dbb68258f@mail.gmail.com>
References: <1256687501-8636-1-git-send-email-andrey@cozybit.com>
	<1256749998.3850.45.camel@localhost.localdomain>
	<45e8e6c40910291048g2958c086oa6b7a39dbb68258f@mail.gmail.com>
Message-ID: <0D107966AF6D79418315B7C5549F4B5101150E65@lemail1.le.imgtec.org>

Andrey,

I've been unable to fully test the WPA2 functionality - I've not got
access to a WPA2 enabled access point - however, I have had a chance to
try the PS mode while connected to a WEP access point (something I
neglected to test first time around - my apologies :-S )

After connecting to the AP, I enabled PS mode and then tried the
following commands (in order):

* iwconfig (no arguments)
  This reurned the connection information, and indicated that power
namagement had been enabled;

* iwlist wlan0 scan
  This gave the following in my log:
[  741.343474] libertas: if_spi_c2h_cmd: error: response packet too
large: 4616 bytes, but maximum is 2400
[  741.370373] libertas: if_spi_c2h_cmd: err=-22
[  741.396573] libertas: lbs_spi_thread: got error -22
[  741.426908] libertas: if_spi_c2h_cmd: error: response packet too
large: 4616 bytes, but maximum is 2400
[  741.453290] libertas: if_spi_c2h_cmd: err=-22
[  741.466275] libertas: lbs_spi_thread: got error -22
[  743.454090] libertas: if_spi_c2h_cmd: error: response packet too
large: 4616 bytes, but maximum is 2400
[  743.480131] libertas: if_spi_c2h_cmd: err=-22
[  743.505172] libertas: lbs_spi_thread: got error -22
[  747.896416] libertas: if_spi_c2h_cmd: error: response packet too
large: 4616 bytes, but maximum is 2400
[  747.909623] libertas: if_spi_c2h_cmd: err=-22
[  747.934910] libertas: lbs_spi_thread: got error -22

  And then returned a 'Failed to read scan data : Resource temporarily
unavailable' error.

* iwconfig wlan0 power off
  After the previous command, this hung with no output on the console or
log.

* iwconfig
  After displaying the 'lo' entry (with no wireless extensions) this too
hung with no output on the console or log.

I apologise for not testing this functionality of the driver, our use
case for the device doesn't include power management so I didn't test it
(to be honest, I'm not sure how our usage of the device would affect any
results wrt power management - I'm still pretty new at this whole
testing and driver development gig!)

Hope this helps, and if I can get onto a WPA2 AP I'll do some more
tests,

George.

> -----Original Message-----
> From: Andrey Yurovsky [mailto:andrey at cozybit.com]
> Sent: 29 October 2009 17:49
> To: Dan Williams
> Cc: linux-wireless at vger.kernel.org; libertas-dev at lists.infradead.org;
> sebatian at breakpoint.cc; George Shore
> Subject: Re: [PATCH] libertas: remove internal buffers from GSPI
driver
> 
> On Wed, Oct 28, 2009 at 10:13 AM, Dan Williams <dcbw at redhat.com>
wrote:
> > Looks OK to me, but I don't have any of the SPI hardware so when you
get
> > a Tested-by:, let me know and I'll ack.
> 
> Thanks Dan, by the way the issue with WPA2 and IEEE PS is unrelated to
> this patch (that is, I can reproduce it without the patch applied) so
> we'll need to address that separately.  So at this point we have:
> 
> Tested-by: George Shore <george.shore at imgtec.com>
> Signed-off-by: Andrey Yurovsky <andrey at cozybit.com>
-
This message is subject to Imagination Technologies' e-mail terms: http://www.imgtec.com/e-mail.htm

Imagination Technologies Ltd is a limited company registered in England No:  1306335 
Registered Office: Imagination House, Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ.  

Email to and from the company may be monitored for compliance and other administrative purposes.  
-



From dcbw at redhat.com  Mon Nov  2 14:54:35 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 02 Nov 2009 11:54:35 -0800
Subject: [PATCH] libertas: remove internal buffers from GSPI driver
In-Reply-To: <45e8e6c40910291048g2958c086oa6b7a39dbb68258f@mail.gmail.com>
References: <1256687501-8636-1-git-send-email-andrey@cozybit.com>
	<1256749998.3850.45.camel@localhost.localdomain>
	<45e8e6c40910291048g2958c086oa6b7a39dbb68258f@mail.gmail.com>
Message-ID: <1257191675.1027.12.camel@localhost.localdomain>

On Thu, 2009-10-29 at 10:48 -0700, Andrey Yurovsky wrote:
> On Wed, Oct 28, 2009 at 10:13 AM, Dan Williams <dcbw at redhat.com> wrote:
> > Looks OK to me, but I don't have any of the SPI hardware so when you get
> > a Tested-by:, let me know and I'll ack.
> 
> Thanks Dan, by the way the issue with WPA2 and IEEE PS is unrelated to
> this patch (that is, I can reproduce it without the patch applied) so
> we'll need to address that separately.  So at this point we have:
> 
> Tested-by: George Shore <george.shore at imgtec.com>
> Signed-off-by: Andrey Yurovsky <andrey at cozybit.com>

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




From dcbw at redhat.com  Mon Nov  2 15:00:32 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 02 Nov 2009 12:00:32 -0800
Subject: MXC MMC driver and SDIO peripherals
In-Reply-To: <20091029102751.GO14091@buzzloop.caiaq.de>
References: <20091021192038.GK14091@buzzloop.caiaq.de>
	<1256156119.8469.40.camel@localhost.localdomain>
	<20091028164752.GN29442@buzzloop.caiaq.de>
	<1256749562.3850.41.camel@localhost.localdomain>
	<20091029102751.GO14091@buzzloop.caiaq.de>
Message-ID: <1257192032.1027.19.camel@localhost.localdomain>

On Thu, 2009-10-29 at 11:27 +0100, Daniel Mack wrote:
> On Wed, Oct 28, 2009 at 10:06:02AM -0700, Dan Williams wrote:
> > On Wed, 2009-10-28 at 17:47 +0100, Daniel Mack wrote:
> > > I did some more research on this and it turns out that the problem is
> > > related to multi block transfers. At least, this is when it first
> > > occurs.
> > > 
> > > The libertas SDIO driver downloads two firmwares to the device, one
> > > 'helper' and one 'real' firmware The first one only uses chunks of 64
> > > bytes each and that seems to work fine. The real firmware, however,
> > > loads in 512 bytes chunks which the SDIO core breaks up into 16 blocks
> > > of 32 bytes. And this is where the MXC host controller bails out with a
> > > CRC error. Unfortunately, it does not give any more detailed information
> > > about what exactly went wrong.
> > > 
> > > The effect might be related to an errata entry[1], which is what I'm
> > > currently investigating. To do so, I would like to limit the the
> > > communication to singe-block transfers, just to exclude all other
> > > possible (electrical, clock speed, ...) issues. I did that by setting
> > > mmc->max_blk_count to 1 in the the host controller, but then again,
> > > the libertas driver and/or the firmware doesn't like that and dies in
> > > if_sdio_pro_real() with
> > > 
> > >   firmware wants 17 bytes
> > >   firmware helper signalled error
> 
> A number of bytes requested has bit 1 set indicates an error, according
> to the code if_sdio_prog_real(). Is there any more information in such
> cases? An error code that tells us about the real reason maybe?

Not that I know of; the helper is pretty simple.  The v9 SD8686 vendor
driver assumes that any helper error is a CRC error, and retries that
block a few times before failing.  But the helper asking for 17 bytes
seems a bit suspicious.  Are you sure there aren't any TX/RX issues with
your SDHC and the connections to the card?

> > All the Marvell documentation (v5 at least) refers to 512-byte transfers
> > of the second-stage firmware in 32-byte blocks:
> > 
> > Section 2.2.1.1 of the v5 spec states:
> 
> What documentation is that? Is it publically available?

http://wiki.laptop.org/images/f/f3/Firmware-Spec-v5.1-MV-S103752-00.pdf

Dan




From bart.cerneels at essensium.com  Wed Nov  4 06:27:32 2009
From: bart.cerneels at essensium.com (Bart Cerneels)
Date: Wed, 4 Nov 2009 12:27:32 +0100
Subject: SDIO on AT91SAMPM9263
Message-ID: <dd7ac1430911040327n62a8c401id2f911a8059af8f8@mail.gmail.com>

Hi all

I've hit a problem with libertas and a marvell sd8385 using FW version
5.0.11p0 and 5.0.20p0.

It's the same timeout issues like [1] but with completely difference
processor architecture and MMC host controller.
While I suspected the host controller to be the problem, this makes me
think its the libertas-sdio driver again.

So what is the most likely culprit here firmware (tried 2 versions),
libertas-core, libertas-sdio or perhaps it's the MMC host screwing
everything up.

I'm not really experience with SD but I absolutely have to fix this
issue this month so if you can help me you can expect a patch if it
turns out to be a libertas bug.

Bart

[1] http://lists.infradead.org/pipermail/libertas-dev/2009-March/002317.html


From linville at tuxdriver.com  Wed Nov  4 14:16:42 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Wed, 4 Nov 2009 14:16:42 -0500
Subject: [PATCH] libertas if_usb: Fix crash on 64-bit machines
In-Reply-To: <200910302026.47131.chunkeey@googlemail.com>
References: <1256924714.4030.44.camel@macbook.infradead.org>
	<200910301944.14740.chunkeey@googlemail.com>
	<1256928681.4030.112.camel@macbook.infradead.org>
	<200910302026.47131.chunkeey@googlemail.com>
Message-ID: <20091104191642.GB10786@tuxdriver.com>

Is anyone evaluating these suggestions?  Should I be expecting properly
formatted patch emails?

John

On Fri, Oct 30, 2009 at 08:26:46PM +0100, Christian Lamparter wrote:
> On Friday 30 October 2009 19:51:21 David Woodhouse wrote:
> > On Fri, 2009-10-30 at 19:44 +0100, Christian Lamparter wrote:
> > > 
> > > that's just a fill-in macro.
> > > AFAICT usb_submit_urb does the tricky dma mapping.
> > 
> > Ah, that makes sense. In that case, all we need to do is make
> > map_urb_for_dma() do the right thing.
> 
> well, but while we're on the subject of libertas.
> 
> I took a quick look around and wrote down some hopefully _helpful_ comments.
> That said, I don't have any libertas hw, so I have no idea if the attached
> code will actually do what its supposed to do... I'll leave it up to the
> professionals to test & write a real fix(es) with a proper commit message. 
> 
> Notes:
> - most + IPFIELD_ALIGN_OFFSET can be replaced by a
>   single skb_reserve, right after allocation.
> 
> - skb_tail_pointer(skb) should be used to get
>   the right rx_buf pointer.
> 
> - setting URB_ZERO_PACKET is pointless for urbs
>   which are submitted to an IN endpoint.
> ---
> diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
> index a8262de..f220db9 100644
> --- a/drivers/net/wireless/libertas/if_usb.c
> +++ b/drivers/net/wireless/libertas/if_usb.c
> @@ -506,17 +506,16 @@ static int __if_usb_submit_rx_urb(struct if_usb_card *cardp,
>  		goto rx_ret;
>  	}
>  
> +	skb_reserve(skb, IPFIELD_ALIGN_OFFSET);
>  	cardp->rx_skb = skb;
>  
>  	/* Fill the receive configuration URB and initialise the Rx call back */
>  	usb_fill_bulk_urb(cardp->rx_urb, cardp->udev,
>  			  usb_rcvbulkpipe(cardp->udev, cardp->ep_in),
> -			  (void *) (skb->tail + (size_t) IPFIELD_ALIGN_OFFSET),
> +			  skb_tail_pointer(skb),
>  			  MRVDRV_ETH_RX_PACKET_BUFFER_SIZE, callbackfn,
>  			  cardp);
>  
> -	cardp->rx_urb->transfer_flags |= URB_ZERO_PACKET;
> -
>  	lbs_deb_usb2(&cardp->udev->dev, "Pointer for rx_urb %p\n", cardp->rx_urb);
>  	if ((ret = usb_submit_urb(cardp->rx_urb, GFP_ATOMIC))) {
>  		lbs_deb_usbd(&cardp->udev->dev, "Submit Rx URB failed: %d\n", ret);
> @@ -557,7 +556,7 @@ static void if_usb_receive_fwload(struct urb *urb)
>  	}
>  
>  	if (cardp->fwdnldover) {
> -		__le32 *tmp = (__le32 *)(skb->data + IPFIELD_ALIGN_OFFSET);
> +		__le32 *tmp = (__le32 *)skb->data;
>  
>  		if (tmp[0] == cpu_to_le32(CMD_TYPE_INDICATION) &&
>  		    tmp[1] == cpu_to_le32(MACREG_INT_CODE_FIRMWARE_READY)) {
> @@ -572,8 +571,7 @@ static void if_usb_receive_fwload(struct urb *urb)
>  		return;
>  	}
>  	if (cardp->bootcmdresp <= 0) {
> -		memcpy (&bootcmdresp, skb->data + IPFIELD_ALIGN_OFFSET,
> -			sizeof(bootcmdresp));
> +		memcpy(&bootcmdresp, skb->data, sizeof(bootcmdresp));
>  
>  		if (le16_to_cpu(cardp->udev->descriptor.bcdDevice) < 0x3106) {
>  			kfree_skb(skb);
> @@ -619,8 +617,7 @@ static void if_usb_receive_fwload(struct urb *urb)
>  		return;
>  	}
>  
> -	memcpy(syncfwheader, skb->data + IPFIELD_ALIGN_OFFSET,
> -	       sizeof(struct fwsyncheader));
> +	memcpy(syncfwheader, skb->data, sizeof(struct fwsyncheader));
>  
>  	if (!syncfwheader->cmd) {
>  		lbs_deb_usb2(&cardp->udev->dev, "FW received Blk with correct CRC\n");
> @@ -665,7 +662,6 @@ static inline void process_cmdtypedata(int recvlength, struct sk_buff *skb,
>  		return;
>  	}
>  
> -	skb_reserve(skb, IPFIELD_ALIGN_OFFSET);
>  	skb_put(skb, recvlength);
>  	skb_pull(skb, MESSAGE_HEADER_LEN);
>  
> @@ -719,7 +715,7 @@ static void if_usb_receive(struct urb *urb)
>  	int recvlength = urb->actual_length;
>  	uint8_t *recvbuff = NULL;
>  	uint32_t recvtype = 0;
> -	__le32 *pkt = (__le32 *)(skb->data + IPFIELD_ALIGN_OFFSET);
> +	__le32 *pkt = (__le32 *)skb->data;
>  	uint32_t event;
>  
>  	lbs_deb_enter(LBS_DEB_USB);
> @@ -732,7 +728,7 @@ static void if_usb_receive(struct urb *urb)
>  			goto setup_for_next;
>  		}
>  
> -		recvbuff = skb->data + IPFIELD_ALIGN_OFFSET;
> +		recvbuff = skb->data;
>  		recvtype = le32_to_cpu(pkt[0]);
>  		lbs_deb_usbd(&cardp->udev->dev,
>  			    "Recv length = 0x%x, Recv type = 0x%X\n",
> 
> 
> 
> 

-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


From dwmw2 at infradead.org  Wed Nov  4 14:36:58 2009
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 04 Nov 2009 19:36:58 +0000
Subject: [PATCH] libertas if_usb: Fix crash on 64-bit machines
In-Reply-To: <20091104191642.GB10786@tuxdriver.com>
References: <1256924714.4030.44.camel@macbook.infradead.org>
	<200910301944.14740.chunkeey@googlemail.com>
	<1256928681.4030.112.camel@macbook.infradead.org>
	<200910302026.47131.chunkeey@googlemail.com>
	<20091104191642.GB10786@tuxdriver.com>
Message-ID: <1257363418.22822.28.camel@macbook.infradead.org>

On Wed, 2009-11-04 at 14:16 -0500, John W. Linville wrote:
> Is anyone evaluating these suggestions?  Should I be expecting
> properly formatted patch emails? 

The suggestions make sense, but not for stable. Let's fix the crasher
bug first, and worry about the rest later.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From dcbw at redhat.com  Wed Nov  4 15:01:43 2009
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 04 Nov 2009 12:01:43 -0800
Subject: [PATCH] libertas if_usb: Fix crash on 64-bit machines
In-Reply-To: <1257363418.22822.28.camel@macbook.infradead.org>
References: <1256924714.4030.44.camel@macbook.infradead.org>
	<200910301944.14740.chunkeey@googlemail.com>
	<1256928681.4030.112.camel@macbook.infradead.org>
	<200910302026.47131.chunkeey@googlemail.com>
	<20091104191642.GB10786@tuxdriver.com>
	<1257363418.22822.28.camel@macbook.infradead.org>
Message-ID: <1257364903.14545.51.camel@localhost.localdomain>

On Wed, 2009-11-04 at 19:36 +0000, David Woodhouse wrote:
> On Wed, 2009-11-04 at 14:16 -0500, John W. Linville wrote:
> > Is anyone evaluating these suggestions?  Should I be expecting
> > properly formatted patch emails? 
> 
> The suggestions make sense, but not for stable. Let's fix the crasher
> bug first, and worry about the rest later.

Sounds good to me...

Dan




From dcbw at redhat.com  Wed Nov  4 15:03:26 2009
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 04 Nov 2009 12:03:26 -0800
Subject: SDIO on AT91SAMPM9263
In-Reply-To: <dd7ac1430911040327n62a8c401id2f911a8059af8f8@mail.gmail.com>
References: <dd7ac1430911040327n62a8c401id2f911a8059af8f8@mail.gmail.com>
Message-ID: <1257365006.14545.52.camel@localhost.localdomain>

On Wed, 2009-11-04 at 12:27 +0100, Bart Cerneels wrote:
> Hi all
> 
> I've hit a problem with libertas and a marvell sd8385 using FW version
> 5.0.11p0 and 5.0.20p0.
> 
> It's the same timeout issues like [1] but with completely difference
> processor architecture and MMC host controller.
> While I suspected the host controller to be the problem, this makes me
> think its the libertas-sdio driver again.
> 
> So what is the most likely culprit here firmware (tried 2 versions),
> libertas-core, libertas-sdio or perhaps it's the MMC host screwing
> everything up.
> 
> I'm not really experience with SD but I absolutely have to fix this
> issue this month so if you can help me you can expect a patch if it
> turns out to be a libertas bug.

Does the SDHC have any quirks or errata with respect to DMA, block size,
multi-block transfers, or interrupts?

Dan




From linville at tuxdriver.com  Wed Nov  4 16:16:00 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Wed, 4 Nov 2009 16:16:00 -0500
Subject: [PATCH] libertas if_usb: Fix crash on 64-bit machines
In-Reply-To: <1257364903.14545.51.camel@localhost.localdomain>
References: <1256924714.4030.44.camel@macbook.infradead.org>
	<200910301944.14740.chunkeey@googlemail.com>
	<1256928681.4030.112.camel@macbook.infradead.org>
	<200910302026.47131.chunkeey@googlemail.com>
	<20091104191642.GB10786@tuxdriver.com>
	<1257363418.22822.28.camel@macbook.infradead.org>
	<1257364903.14545.51.camel@localhost.localdomain>
Message-ID: <20091104211600.GE10786@tuxdriver.com>

On Wed, Nov 04, 2009 at 12:01:43PM -0800, Dan Williams wrote:
> On Wed, 2009-11-04 at 19:36 +0000, David Woodhouse wrote:
> > On Wed, 2009-11-04 at 14:16 -0500, John W. Linville wrote:
> > > Is anyone evaluating these suggestions?  Should I be expecting
> > > properly formatted patch emails? 
> > 
> > The suggestions make sense, but not for stable. Let's fix the crasher
> > bug first, and worry about the rest later.
> 
> Sounds good to me...

Yes, of course.

So, Christian, will you be following-up?

Thanks!

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


From chunkeey at googlemail.com  Wed Nov  4 17:12:59 2009
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Wed, 4 Nov 2009 23:12:59 +0100
Subject: [PATCH] libertas if_usb: tiny usb-rx overhaul
In-Reply-To: <20091104211600.GE10786@tuxdriver.com>
References: <1256924714.4030.44.camel@macbook.infradead.org>
	<1257364903.14545.51.camel@localhost.localdomain>
	<20091104211600.GE10786@tuxdriver.com>
Message-ID: <200911042313.00089.chunkeey@googlemail.com>

This patch reorganizes libertas' if_usb rx routines.

 - URB_ZERO_PACKET flag has no use for urbs for 
   incoming endpoints.
    
 - skb_tail_pointer(skb) should be used to get
   the right rx_buf pointer.

 - most + IPFIELD_ALIGN_OFFSET can be prevented by
   moving skb_reserve up right after allocation.

Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>
---
any Tested-by: ?
---
diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
index a8262de..f220db9 100644
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -506,17 +506,16 @@ static int __if_usb_submit_rx_urb(struct if_usb_card *cardp,
 		goto rx_ret;
 	}
 
+	skb_reserve(skb, IPFIELD_ALIGN_OFFSET);
 	cardp->rx_skb = skb;
 
 	/* Fill the receive configuration URB and initialise the Rx call back */
 	usb_fill_bulk_urb(cardp->rx_urb, cardp->udev,
 			  usb_rcvbulkpipe(cardp->udev, cardp->ep_in),
-			  skb->data + IPFIELD_ALIGN_OFFSET,
+			  skb_tail_pointer(skb),
 			  MRVDRV_ETH_RX_PACKET_BUFFER_SIZE, callbackfn,
 			  cardp);
 
-	cardp->rx_urb->transfer_flags |= URB_ZERO_PACKET;
-
 	lbs_deb_usb2(&cardp->udev->dev, "Pointer for rx_urb %p\n", cardp->rx_urb);
 	if ((ret = usb_submit_urb(cardp->rx_urb, GFP_ATOMIC))) {
 		lbs_deb_usbd(&cardp->udev->dev, "Submit Rx URB failed: %d\n", ret);
@@ -557,7 +556,7 @@ static void if_usb_receive_fwload(struct urb *urb)
 	}
 
 	if (cardp->fwdnldover) {
-		__le32 *tmp = (__le32 *)(skb->data + IPFIELD_ALIGN_OFFSET);
+		__le32 *tmp = (__le32 *)skb->data;
 
 		if (tmp[0] == cpu_to_le32(CMD_TYPE_INDICATION) &&
 		    tmp[1] == cpu_to_le32(MACREG_INT_CODE_FIRMWARE_READY)) {
@@ -572,8 +571,7 @@ static void if_usb_receive_fwload(struct urb *urb)
 		return;
 	}
 	if (cardp->bootcmdresp <= 0) {
-		memcpy (&bootcmdresp, skb->data + IPFIELD_ALIGN_OFFSET,
-			sizeof(bootcmdresp));
+		memcpy(&bootcmdresp, skb->data, sizeof(bootcmdresp));
 
 		if (le16_to_cpu(cardp->udev->descriptor.bcdDevice) < 0x3106) {
 			kfree_skb(skb);
@@ -619,8 +617,7 @@ static void if_usb_receive_fwload(struct urb *urb)
 		return;
 	}
 
-	memcpy(syncfwheader, skb->data + IPFIELD_ALIGN_OFFSET,
-	       sizeof(struct fwsyncheader));
+	memcpy(syncfwheader, skb->data, sizeof(struct fwsyncheader));
 
 	if (!syncfwheader->cmd) {
 		lbs_deb_usb2(&cardp->udev->dev, "FW received Blk with correct CRC\n");
@@ -665,7 +662,6 @@ static inline void process_cmdtypedata(int recvlength, struct sk_buff *skb,
 		return;
 	}
 
-	skb_reserve(skb, IPFIELD_ALIGN_OFFSET);
 	skb_put(skb, recvlength);
 	skb_pull(skb, MESSAGE_HEADER_LEN);
 
@@ -719,7 +715,7 @@ static void if_usb_receive(struct urb *urb)
 	int recvlength = urb->actual_length;
 	uint8_t *recvbuff = NULL;
 	uint32_t recvtype = 0;
-	__le32 *pkt = (__le32 *)(skb->data + IPFIELD_ALIGN_OFFSET);
+	__le32 *pkt = (__le32 *)skb->data;
 	uint32_t event;
 
 	lbs_deb_enter(LBS_DEB_USB);
@@ -732,7 +728,7 @@ static void if_usb_receive(struct urb *urb)
 			goto setup_for_next;
 		}
 
-		recvbuff = skb->data + IPFIELD_ALIGN_OFFSET;
+		recvbuff = skb->data;
 		recvtype = le32_to_cpu(pkt[0]);
 		lbs_deb_usbd(&cardp->udev->dev,
 			    "Recv length = 0x%x, Recv type = 0x%X\n",


From colin.bates at gmx.co.uk  Wed Nov  4 18:25:18 2009
From: colin.bates at gmx.co.uk (Colin Bates)
Date: Wed, 4 Nov 2009 23:25:18 +0000
Subject: Firmware loads twice.
Message-ID: <200911042325.18594.colin.bates@gmx.co.uk>

Hi,

I am using Angstrom on a Zaurus. When I plug in my CF wifi card the libertas 
and libertas_cs modules load and /lib/udev/firmware.sh is called.

The problem is that the firmware.sh script is called twice to load the 
libertas_helper.fw file.

I have tried chasing through the Kernel with printk's to find why this is. 
From what I can see everything is correct until the netlink_broadcast 
function. After that I get a bit lost as to how udev calls the firmware.sh.

The SEQNUM is that same for both calls to firmware.sh. From what I can see 
this means that all is correct from libertas_cs through to the 
netlink_broadcast call in kobject_uevent.c.

The second firmware.sh call does not start until the script has returned from 
the first call.

With some hacking to make the firmware.sh ignore the second call I can make 
the things work and the eth0 interface appears.

Any help as to what is going would be appreciated.

Cheers,

Colin


From bzhao at marvell.com  Wed Nov  4 20:06:35 2009
From: bzhao at marvell.com (Bing Zhao)
Date: Wed,  4 Nov 2009 17:06:35 -0800
Subject: [PATCH] Libertas: Fix issues while configuring host sleep
Message-ID: <1257383195-951-1-git-send-email-bzhao@marvell.com>

From: Amitkumar Karwar <akarwar at marvell.com>

Configuration of wake-on-lan for unicast, multicast, broadcast, physical
activity was not working. Kernel panic issue was there when user tries to
disable WOL. Fixed them.

Signed-off-by: Amitkumar Karwar <akarwar at marvell.com>
Signed-off-by: Bing Zhao <bzhao at marvell.com>
---
 drivers/net/wireless/libertas/ethtool.c |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
index 039b555..eeda6d7 100644
--- a/drivers/net/wireless/libertas/ethtool.c
+++ b/drivers/net/wireless/libertas/ethtool.c
@@ -169,16 +169,22 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
 	struct lbs_private *priv = dev->ml_priv;
 	uint32_t criteria = 0;
 
-	if (priv->wol_criteria == 0xffffffff && wol->wolopts)
+	if (priv->wol_criteria != 0xffffffff && wol->wolopts)
 		return -EOPNOTSUPP;
 
 	if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
 		return -EOPNOTSUPP;
 
-	if (wol->wolopts & WAKE_UCAST) criteria |= EHS_WAKE_ON_UNICAST_DATA;
-	if (wol->wolopts & WAKE_MCAST) criteria |= EHS_WAKE_ON_MULTICAST_DATA;
-	if (wol->wolopts & WAKE_BCAST) criteria |= EHS_WAKE_ON_BROADCAST_DATA;
-	if (wol->wolopts & WAKE_PHY)   criteria |= EHS_WAKE_ON_MAC_EVENT;
+	if (wol->wolopts & WAKE_UCAST)
+		criteria |= EHS_WAKE_ON_UNICAST_DATA;
+	if (wol->wolopts & WAKE_MCAST)
+		criteria |= EHS_WAKE_ON_MULTICAST_DATA;
+	if (wol->wolopts & WAKE_BCAST)
+		criteria |= EHS_WAKE_ON_BROADCAST_DATA;
+	if (wol->wolopts & WAKE_PHY)
+		criteria |= EHS_WAKE_ON_MAC_EVENT;
+	if (wol->wolopts == 0)
+		criteria |= EHS_REMOVE_WAKEUP;
 
 	return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
 }
-- 
1.5.4.3



From ek9852 at gmail.com  Wed Nov  4 19:59:39 2009
From: ek9852 at gmail.com (Mok Keith)
Date: Thu, 5 Nov 2009 08:59:39 +0800
Subject: Firmware loads twice.
In-Reply-To: <200911042325.18594.colin.bates@gmx.co.uk>
References: <200911042325.18594.colin.bates@gmx.co.uk>
Message-ID: <69f617130911041659r4889f9e2gacf1c32706f137c0@mail.gmail.com>

Hi,

Check you udev rules, I encounter this before which finally found out
to be a bug in the old version of udev which openembedded used.
I remove the file (/etc/udev/rules.d/udev.rules) which duplicated call
to firmware.sh.

Cheer,
Keith


From bart.cerneels at essensium.com  Thu Nov  5 03:47:03 2009
From: bart.cerneels at essensium.com (Bart Cerneels)
Date: Thu, 5 Nov 2009 09:47:03 +0100
Subject: SDIO on AT91SAMPM9263
In-Reply-To: <1257365006.14545.52.camel@localhost.localdomain>
References: <dd7ac1430911040327n62a8c401id2f911a8059af8f8@mail.gmail.com> 
	<1257365006.14545.52.camel@localhost.localdomain>
Message-ID: <dd7ac1430911050047k23d42f81k544b7464dab617bf@mail.gmail.com>

On Wed, Nov 4, 2009 at 21:03, Dan Williams <dcbw at redhat.com> wrote:
> On Wed, 2009-11-04 at 12:27 +0100, Bart Cerneels wrote:
>> Hi all
>>
>> I've hit a problem with libertas and a marvell sd8385 using FW version
>> 5.0.11p0 and 5.0.20p0.
>>
>> It's the same timeout issues like [1] but with completely difference
>> processor architecture and MMC host controller.
>> While I suspected the host controller to be the problem, this makes me
>> think its the libertas-sdio driver again.
>>
>> So what is the most likely culprit here firmware (tried 2 versions),
>> libertas-core, libertas-sdio or perhaps it's the MMC host screwing
>> everything up.
>>
>> I'm not really experience with SD but I absolutely have to fix this
>> issue this month so if you can help me you can expect a patch if it
>> turns out to be a libertas bug.
>
> Does the SDHC have any quirks or errata with respect to DMA, block size,
> multi-block transfers, or interrupts?
>
> Dan
>

It does, but I have investigated each one and they are all handled in
the host controller driver (at91_mci). Also the hardware configuration
is correct w.r.t. the errata (one slot can not handle SDIO
interrupts).

Assuming this is padding or a different quirk fix that goes wrong: how
can one tell? i.e. are there specific commands that will surely fail
and I'll see show up in the logs?
The only consistent problem I'm seeing ATM is response timeouts, which
could be FW going belly up or SD host problems. Both can possibly be
avoided in libertas.

Bart


From daniel at caiaq.de  Thu Nov  5 07:05:49 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Thu, 5 Nov 2009 13:05:49 +0100
Subject: Libertas related kernel crash
Message-ID: <20091105120549.GQ14091@buzzloop.caiaq.de>

On an ARM (PXA300) embdedded platform with a libertas chip connected via
SDIO, we happen to see the kernel Ooops below once in a while.

Any pointer on where to dig?

Daniel


[ 2659.715112] Unable to handle kernel NULL pointer dereference at virtual address 00000001
[ 2659.723164] pgd = c5ca8000
[ 2659.725846] [00000001] *pgd=a5cbc031, *pte=00000000, *ppte=00000000
[ 2659.732062] Internal error: Oops: 13 [#4]
[ 2659.736041] last sysfs file: /sys/devices/platform/pxa2xx-mci.0/mmc_host/mmc0/mmc0:0001/mmc0:0001:1/net/wlan0/address
[ 2659.746573] Modules linked in: eeti_ts libertas_sdio pxamci ds2760_battery w1_ds2760 wire
[ 2659.754698] CPU: 0    Tainted: G      D     (2.6.32-rc6 #1)
[ 2659.760255] PC is at kmem_cache_alloc+0x30/0x90
[ 2659.764774] LR is at inet_bind_bucket_create+0x18/0x5c
[ 2659.769876] pc : [<c00a28d8>]    lr : [<c02a4b24>]    psr: 20000093
[ 2659.769887] sp : c5c27d88  ip : c78ae4a0  fp : 00006e49
[ 2659.781279] r10: 00008928  r9 : c04fcfac  r8 : c0532148
[ 2659.786466] r7 : 00000020  r6 : 00000020  r5 : 60000013  r4 : 00000001
[ 2659.792945] r3 : 00000000  r2 : c78ae4a0  r1 : 00000020  r0 : c04d42e4
[ 2659.799427] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment user
[ 2659.806602] Control: 0000397f  Table: a5ca8018  DAC: 00000015
[ 2659.812304] Process p0-renderer (pid: 1527, stack limit = 0xc5c26278)
[ 2659.818697] Stack: (0xc5c27d88 to 0xc5c28000)
[ 2659.823029] 7d80:                   c5cc5300 c5cb1000 c5c18800 c78ae4a0 00008928 00008928
[ 2659.831155] 7da0: 00000001 c02a4b24 c2388c2e 00000000 c7eb6200 c02a4c8c c02a4200 c2388c2d
[ 2659.839287] 7dc0: c04fcfac 00000000 0000ee48 00008000 fb0ca8c0 c7eb6200 c04fcfac 00000000
[ 2659.847412] 7de0: 000038e5 fb0ca8c0 fb0ca8c0 c7eb6200 00000000 c02a4e28 c02a40e4 00000000
[ 2659.855543] 7e00: 00000000 00000000 00000000 c02b99d4 00000001 00000000 c5c27f08 00000000
[ 2659.863669] 7e20: c5c7b500 000005a8 00000000 00000000 000200da c5c7b500 c0069a74 c5c27e3c
[ 2659.871802] 7e40: c5c27e3c c0049fdc be96a8fc c0275d70 c5c27e88 00000006 00000005 00000001
[ 2659.879933] 7e60: 00000000 00000000 00000000 fb0ca8c0 1d0ca8c0 00000000 00000000 00000000
[ 2659.888057] 7e80: 00000000 00000000 00000000 00000000 00000006 38e50000 00000000 c7ff6e00
[ 2659.896183] 7ea0: 000063f8 c5c27f08 00000010 c7eb6200 c5c27f08 c00440c4 c5c26000 c76cd2c0
[ 2659.904314] 7ec0: 00000802 c02c4f70 0000c1ff 00000001 00000000 00000000 00000000 00045108
[ 2659.912441] 7ee0: 00000010 c76cd2c0 00045108 00000010 c5c27f08 c00440c4 c5c26000 40343800
[ 2659.920573] 7f00: 00044440 c0276888 38e50002 fb0ca8c0 00000000 00000000 000063f8 00000000
[ 2659.928698] 7f20: 00000000 be96a858 c5c27f48 000450c0 000000c5 c00440c4 c5c26000 40343800
[ 2659.936829] 7f40: 00044440 c00a9864 000063f8 00000000 00000005 c047c1ff 00000001 00000000
[ 2659.944952] 7f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000003
[ 2659.953078] 7f80: 00000000 c7b5aa00 00000000 00000000 00000000 00046cb8 00045108 40370ef8
[ 2659.961203] 7fa0: 0000011b c0043f40 00046cb8 00045108 0000000a 00045108 00000010 0000001c
[ 2659.969328] 7fc0: 00046cb8 00045108 40370ef8 0000011b 00000000 00043178 40343800 00044440
[ 2659.977451] 7fe0: 40371050 be96a968 4035b3c8 40790638 60000010 0000000a 00000000 00000000
[ 2659.985599] [<c00a28d8>] (kmem_cache_alloc+0x30/0x90) from [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c)
[ 2659.995296] [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c) from [<c02a4c8c>] (__inet_hash_connect+0x124/0x280)
[ 2660.005415] [<c02a4c8c>] (__inet_hash_connect+0x124/0x280) from [<c02a4e28>] (inet_hash_connect+0x40/0x50)
[ 2660.015034] [<c02a4e28>] (inet_hash_connect+0x40/0x50) from [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420)
[ 2660.024211] [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420) from [<c02c4f70>] (inet_stream_connect+0xac/0x26c)
[ 2660.033653] [<c02c4f70>] (inet_stream_connect+0xac/0x26c) from [<c0276888>] (sys_connect+0x6c/0x90)
[ 2660.042662] [<c0276888>] (sys_connect+0x6c/0x90) from [<c0043f40>] (ret_fast_syscall+0x0/0x28)
[ 2660.051228] Code: e5904080 e5907090 e3540000 1590308c (17943103) [ 2660.057440] ---[ end trace 416b23b4578ffa42 ]---
[ 2660.062021] Kernel panic - not syncing: Fatal exception in interrupt
[ 2660.068400] [<c00486cc>] (unwind_backtrace+0x0/0xdc) from [<c0351758>] (panic+0x34/0x120)
[ 2660.076555] [<c0351758>] (panic+0x34/0x120) from [<c004758c>] (die+0x14c/0x178)
[ 2660.083823] [<c004758c>] (die+0x14c/0x178) from [<c0049900>] (__do_kernel_fault+0x68/0x80)
[ 2660.092060] [<c0049900>] (__do_kernel_fault+0x68/0x80) from [<c004b678>] (do_alignment+0x59c/0x700)
[ 2660.101067] [<c004b678>] (do_alignment+0x59c/0x700) from [<c00432c8>] (do_DataAbort+0x34/0x94)
[ 2660.109649] [<c00432c8>] (do_DataAbort+0x34/0x94) from [<c0043acc>] (__dabt_svc+0x4c/0x60)
[ 2660.117874] Exception stack(0xc5c27d40 to 0xc5c27d88)
[ 2660.122898] 7d40: c04d42e4 00000020 c78ae4a0 00000000 00000001 60000013 00000020 00000020
[ 2660.131046] 7d60: c0532148 c04fcfac 00008928 00006e49 c78ae4a0 c5c27d88 c02a4b24 c00a28d8
[ 2660.139189] 7d80: 20000093 ffffffff
[ 2660.142673] [<c0043acc>] (__dabt_svc+0x4c/0x60) from [<c00a28d8>] (kmem_cache_alloc+0x30/0x90)
[ 2660.151265] [<c00a28d8>] (kmem_cache_alloc+0x30/0x90) from [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c)
[ 2660.160998] [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c) from [<c02a4c8c>] (__inet_hash_connect+0x124/0x280)
[ 2660.171148] [<c02a4c8c>] (__inet_hash_connect+0x124/0x280) from [<c02a4e28>] (inet_hash_connect+0x40/0x50)
[ 2660.180780] [<c02a4e28>] (inet_hash_connect+0x40/0x50) from [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420)
[ 2660.189971] [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420) from [<c02c4f70>] (inet_stream_connect+0xac/0x26c)
[ 2660.199424] [<c02c4f70>] (inet_stream_connect+0xac/0x26c) from [<c0276888>] (sys_connect+0x6c/0x90)
[ 2660.208443] [<c0276888>] (sys_connect+0x6c/0x90) from [<c0043f40>] (ret_fast_syscall+0x0/0x28)



From dcbw at redhat.com  Thu Nov  5 16:36:51 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 05 Nov 2009 13:36:51 -0800
Subject: [PATCH] Libertas: Fix issues while configuring host sleep
In-Reply-To: <1257383195-951-1-git-send-email-bzhao@marvell.com>
References: <1257383195-951-1-git-send-email-bzhao@marvell.com>
Message-ID: <1257457011.16377.7.camel@localhost.localdomain>

On Wed, 2009-11-04 at 17:06 -0800, Bing Zhao wrote:
> From: Amitkumar Karwar <akarwar at marvell.com>
> 
> Configuration of wake-on-lan for unicast, multicast, broadcast, physical
> activity was not working. Kernel panic issue was there when user tries to
> disable WOL. Fixed them.
> 
> Signed-off-by: Amitkumar Karwar <akarwar at marvell.com>
> Signed-off-by: Bing Zhao <bzhao at marvell.com>

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

> ---
>  drivers/net/wireless/libertas/ethtool.c |   16 +++++++++++-----
>  1 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
> index 039b555..eeda6d7 100644
> --- a/drivers/net/wireless/libertas/ethtool.c
> +++ b/drivers/net/wireless/libertas/ethtool.c
> @@ -169,16 +169,22 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
>  	struct lbs_private *priv = dev->ml_priv;
>  	uint32_t criteria = 0;
>  
> -	if (priv->wol_criteria == 0xffffffff && wol->wolopts)
> +	if (priv->wol_criteria != 0xffffffff && wol->wolopts)
>  		return -EOPNOTSUPP;
>  
>  	if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
>  		return -EOPNOTSUPP;
>  
> -	if (wol->wolopts & WAKE_UCAST) criteria |= EHS_WAKE_ON_UNICAST_DATA;
> -	if (wol->wolopts & WAKE_MCAST) criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> -	if (wol->wolopts & WAKE_BCAST) criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> -	if (wol->wolopts & WAKE_PHY)   criteria |= EHS_WAKE_ON_MAC_EVENT;
> +	if (wol->wolopts & WAKE_UCAST)
> +		criteria |= EHS_WAKE_ON_UNICAST_DATA;
> +	if (wol->wolopts & WAKE_MCAST)
> +		criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> +	if (wol->wolopts & WAKE_BCAST)
> +		criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> +	if (wol->wolopts & WAKE_PHY)
> +		criteria |= EHS_WAKE_ON_MAC_EVENT;
> +	if (wol->wolopts == 0)
> +		criteria |= EHS_REMOVE_WAKEUP;
>  
>  	return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
>  }



From jiujin.hong at mid-fun.com  Thu Nov  5 21:08:12 2009
From: jiujin.hong at mid-fun.com (tommy)
Date: Fri, 06 Nov 2009 10:08:12 +0800
Subject: Libertas related kernel crash
In-Reply-To: <20091105120549.GQ14091@buzzloop.caiaq.de>
References: <20091105120549.GQ14091@buzzloop.caiaq.de>
Message-ID: <1257473292.5672.2.camel@tommy-desktop>

hi,daniel!
the question is "kmem_cache_alloc"!

I met similiar problem in android rt3070 2.6.24 kernel!
as there enough memory in your board ?


On ?, 2009-11-05 at 13:05 +0100, Daniel Mack wrote:
> On an ARM (PXA300) embdedded platform with a libertas chip connected via
> SDIO, we happen to see the kernel Ooops below once in a while.
> 
> Any pointer on where to dig?
> 
> Daniel
> 
> 
> [ 2659.715112] Unable to handle kernel NULL pointer dereference at virtual address 00000001
> [ 2659.723164] pgd = c5ca8000
> [ 2659.725846] [00000001] *pgd=a5cbc031, *pte=00000000, *ppte=00000000
> [ 2659.732062] Internal error: Oops: 13 [#4]
> [ 2659.736041] last sysfs file: /sys/devices/platform/pxa2xx-mci.0/mmc_host/mmc0/mmc0:0001/mmc0:0001:1/net/wlan0/address
> [ 2659.746573] Modules linked in: eeti_ts libertas_sdio pxamci ds2760_battery w1_ds2760 wire
> [ 2659.754698] CPU: 0    Tainted: G      D     (2.6.32-rc6 #1)
> [ 2659.760255] PC is at kmem_cache_alloc+0x30/0x90
> [ 2659.764774] LR is at inet_bind_bucket_create+0x18/0x5c
> [ 2659.769876] pc : [<c00a28d8>]    lr : [<c02a4b24>]    psr: 20000093
> [ 2659.769887] sp : c5c27d88  ip : c78ae4a0  fp : 00006e49
> [ 2659.781279] r10: 00008928  r9 : c04fcfac  r8 : c0532148
> [ 2659.786466] r7 : 00000020  r6 : 00000020  r5 : 60000013  r4 : 00000001
> [ 2659.792945] r3 : 00000000  r2 : c78ae4a0  r1 : 00000020  r0 : c04d42e4
> [ 2659.799427] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment user
> [ 2659.806602] Control: 0000397f  Table: a5ca8018  DAC: 00000015
> [ 2659.812304] Process p0-renderer (pid: 1527, stack limit = 0xc5c26278)
> [ 2659.818697] Stack: (0xc5c27d88 to 0xc5c28000)
> [ 2659.823029] 7d80:                   c5cc5300 c5cb1000 c5c18800 c78ae4a0 00008928 00008928
> [ 2659.831155] 7da0: 00000001 c02a4b24 c2388c2e 00000000 c7eb6200 c02a4c8c c02a4200 c2388c2d
> [ 2659.839287] 7dc0: c04fcfac 00000000 0000ee48 00008000 fb0ca8c0 c7eb6200 c04fcfac 00000000
> [ 2659.847412] 7de0: 000038e5 fb0ca8c0 fb0ca8c0 c7eb6200 00000000 c02a4e28 c02a40e4 00000000
> [ 2659.855543] 7e00: 00000000 00000000 00000000 c02b99d4 00000001 00000000 c5c27f08 00000000
> [ 2659.863669] 7e20: c5c7b500 000005a8 00000000 00000000 000200da c5c7b500 c0069a74 c5c27e3c
> [ 2659.871802] 7e40: c5c27e3c c0049fdc be96a8fc c0275d70 c5c27e88 00000006 00000005 00000001
> [ 2659.879933] 7e60: 00000000 00000000 00000000 fb0ca8c0 1d0ca8c0 00000000 00000000 00000000
> [ 2659.888057] 7e80: 00000000 00000000 00000000 00000000 00000006 38e50000 00000000 c7ff6e00
> [ 2659.896183] 7ea0: 000063f8 c5c27f08 00000010 c7eb6200 c5c27f08 c00440c4 c5c26000 c76cd2c0
> [ 2659.904314] 7ec0: 00000802 c02c4f70 0000c1ff 00000001 00000000 00000000 00000000 00045108
> [ 2659.912441] 7ee0: 00000010 c76cd2c0 00045108 00000010 c5c27f08 c00440c4 c5c26000 40343800
> [ 2659.920573] 7f00: 00044440 c0276888 38e50002 fb0ca8c0 00000000 00000000 000063f8 00000000
> [ 2659.928698] 7f20: 00000000 be96a858 c5c27f48 000450c0 000000c5 c00440c4 c5c26000 40343800
> [ 2659.936829] 7f40: 00044440 c00a9864 000063f8 00000000 00000005 c047c1ff 00000001 00000000
> [ 2659.944952] 7f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000003
> [ 2659.953078] 7f80: 00000000 c7b5aa00 00000000 00000000 00000000 00046cb8 00045108 40370ef8
> [ 2659.961203] 7fa0: 0000011b c0043f40 00046cb8 00045108 0000000a 00045108 00000010 0000001c
> [ 2659.969328] 7fc0: 00046cb8 00045108 40370ef8 0000011b 00000000 00043178 40343800 00044440
> [ 2659.977451] 7fe0: 40371050 be96a968 4035b3c8 40790638 60000010 0000000a 00000000 00000000
> [ 2659.985599] [<c00a28d8>] (kmem_cache_alloc+0x30/0x90) from [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c)
> [ 2659.995296] [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c) from [<c02a4c8c>] (__inet_hash_connect+0x124/0x280)
> [ 2660.005415] [<c02a4c8c>] (__inet_hash_connect+0x124/0x280) from [<c02a4e28>] (inet_hash_connect+0x40/0x50)
> [ 2660.015034] [<c02a4e28>] (inet_hash_connect+0x40/0x50) from [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420)
> [ 2660.024211] [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420) from [<c02c4f70>] (inet_stream_connect+0xac/0x26c)
> [ 2660.033653] [<c02c4f70>] (inet_stream_connect+0xac/0x26c) from [<c0276888>] (sys_connect+0x6c/0x90)
> [ 2660.042662] [<c0276888>] (sys_connect+0x6c/0x90) from [<c0043f40>] (ret_fast_syscall+0x0/0x28)
> [ 2660.051228] Code: e5904080 e5907090 e3540000 1590308c (17943103) [ 2660.057440] ---[ end trace 416b23b4578ffa42 ]---
> [ 2660.062021] Kernel panic - not syncing: Fatal exception in interrupt
> [ 2660.068400] [<c00486cc>] (unwind_backtrace+0x0/0xdc) from [<c0351758>] (panic+0x34/0x120)
> [ 2660.076555] [<c0351758>] (panic+0x34/0x120) from [<c004758c>] (die+0x14c/0x178)
> [ 2660.083823] [<c004758c>] (die+0x14c/0x178) from [<c0049900>] (__do_kernel_fault+0x68/0x80)
> [ 2660.092060] [<c0049900>] (__do_kernel_fault+0x68/0x80) from [<c004b678>] (do_alignment+0x59c/0x700)
> [ 2660.101067] [<c004b678>] (do_alignment+0x59c/0x700) from [<c00432c8>] (do_DataAbort+0x34/0x94)
> [ 2660.109649] [<c00432c8>] (do_DataAbort+0x34/0x94) from [<c0043acc>] (__dabt_svc+0x4c/0x60)
> [ 2660.117874] Exception stack(0xc5c27d40 to 0xc5c27d88)
> [ 2660.122898] 7d40: c04d42e4 00000020 c78ae4a0 00000000 00000001 60000013 00000020 00000020
> [ 2660.131046] 7d60: c0532148 c04fcfac 00008928 00006e49 c78ae4a0 c5c27d88 c02a4b24 c00a28d8
> [ 2660.139189] 7d80: 20000093 ffffffff
> [ 2660.142673] [<c0043acc>] (__dabt_svc+0x4c/0x60) from [<c00a28d8>] (kmem_cache_alloc+0x30/0x90)
> [ 2660.151265] [<c00a28d8>] (kmem_cache_alloc+0x30/0x90) from [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c)
> [ 2660.160998] [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c) from [<c02a4c8c>] (__inet_hash_connect+0x124/0x280)
> [ 2660.171148] [<c02a4c8c>] (__inet_hash_connect+0x124/0x280) from [<c02a4e28>] (inet_hash_connect+0x40/0x50)
> [ 2660.180780] [<c02a4e28>] (inet_hash_connect+0x40/0x50) from [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420)
> [ 2660.189971] [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420) from [<c02c4f70>] (inet_stream_connect+0xac/0x26c)
> [ 2660.199424] [<c02c4f70>] (inet_stream_connect+0xac/0x26c) from [<c0276888>] (sys_connect+0x6c/0x90)
> [ 2660.208443] [<c0276888>] (sys_connect+0x6c/0x90) from [<c0043f40>] (ret_fast_syscall+0x0/0x28)
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev
> 



From linville at tuxdriver.com  Fri Nov  6 15:19:24 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Fri, 6 Nov 2009 15:19:24 -0500
Subject: [PATCH] Libertas: Fix issues while configuring host sleep
In-Reply-To: <1257383195-951-1-git-send-email-bzhao@marvell.com>
References: <1257383195-951-1-git-send-email-bzhao@marvell.com>
Message-ID: <20091106201924.GH2782@tuxdriver.com>

On Wed, Nov 04, 2009 at 05:06:35PM -0800, Bing Zhao wrote:
> From: Amitkumar Karwar <akarwar at marvell.com>
> 
> Configuration of wake-on-lan for unicast, multicast, broadcast, physical
> activity was not working. Kernel panic issue was there when user tries to
> disable WOL. Fixed them.
> 
> Signed-off-by: Amitkumar Karwar <akarwar at marvell.com>
> Signed-off-by: Bing Zhao <bzhao at marvell.com>
> ---
>  drivers/net/wireless/libertas/ethtool.c |   16 +++++++++++-----
>  1 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
> index 039b555..eeda6d7 100644
> --- a/drivers/net/wireless/libertas/ethtool.c
> +++ b/drivers/net/wireless/libertas/ethtool.c
> @@ -169,16 +169,22 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
>  	struct lbs_private *priv = dev->ml_priv;
>  	uint32_t criteria = 0;
>  
> -	if (priv->wol_criteria == 0xffffffff && wol->wolopts)
> +	if (priv->wol_criteria != 0xffffffff && wol->wolopts)
>  		return -EOPNOTSUPP;
  
Are you sure about this?  This makes me think that you won't be able
to change WoL parameters without going through a disable step first.
Am I misreading?

>  	if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
>  		return -EOPNOTSUPP;
>  
> -	if (wol->wolopts & WAKE_UCAST) criteria |= EHS_WAKE_ON_UNICAST_DATA;
> -	if (wol->wolopts & WAKE_MCAST) criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> -	if (wol->wolopts & WAKE_BCAST) criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> -	if (wol->wolopts & WAKE_PHY)   criteria |= EHS_WAKE_ON_MAC_EVENT;
> +	if (wol->wolopts & WAKE_UCAST)
> +		criteria |= EHS_WAKE_ON_UNICAST_DATA;
> +	if (wol->wolopts & WAKE_MCAST)
> +		criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> +	if (wol->wolopts & WAKE_BCAST)
> +		criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> +	if (wol->wolopts & WAKE_PHY)
> +		criteria |= EHS_WAKE_ON_MAC_EVENT;
> +	if (wol->wolopts == 0)
> +		criteria |= EHS_REMOVE_WAKEUP;
>  
>  	return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
>  }

The reformatting is a distraction.  It would be better to do just
the fix part separately, especially if you are targetting 2.6.32.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


From bzhao at marvell.com  Fri Nov  6 16:27:50 2009
From: bzhao at marvell.com (Bing Zhao)
Date: Fri, 6 Nov 2009 13:27:50 -0800
Subject: [PATCH] Libertas: Fix issues while configuring host sleep
In-Reply-To: <20091106201924.GH2782@tuxdriver.com>
References: <1257383195-951-1-git-send-email-bzhao@marvell.com>
	<20091106201924.GH2782@tuxdriver.com>
Message-ID: <477F20668A386D41ADCC57781B1F704306E01F78F3@SC-VEXCH1.marvell.com>

Hi John,

> -----Original Message-----
> From: John W. Linville [mailto:linville at tuxdriver.com]
> Sent: Friday, November 06, 2009 12:19 PM
> To: Bing Zhao
> Cc: libertas-dev at lists.infradead.org; linux-wireless at vger.kernel.org; Amitkumar Karwar
> Subject: Re: [PATCH] Libertas: Fix issues while configuring host sleep
> 
> On Wed, Nov 04, 2009 at 05:06:35PM -0800, Bing Zhao wrote:
> > From: Amitkumar Karwar <akarwar at marvell.com>
> >
> > Configuration of wake-on-lan for unicast, multicast, broadcast, physical
> > activity was not working. Kernel panic issue was there when user tries to
> > disable WOL. Fixed them.
> >
> > Signed-off-by: Amitkumar Karwar <akarwar at marvell.com>
> > Signed-off-by: Bing Zhao <bzhao at marvell.com>
> > ---
> >  drivers/net/wireless/libertas/ethtool.c |   16 +++++++++++-----
> >  1 files changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
> > index 039b555..eeda6d7 100644
> > --- a/drivers/net/wireless/libertas/ethtool.c
> > +++ b/drivers/net/wireless/libertas/ethtool.c
> > @@ -169,16 +169,22 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
> >  	struct lbs_private *priv = dev->ml_priv;
> >  	uint32_t criteria = 0;
> >
> > -	if (priv->wol_criteria == 0xffffffff && wol->wolopts)
> > +	if (priv->wol_criteria != 0xffffffff && wol->wolopts)
> >  		return -EOPNOTSUPP;
> 
> Are you sure about this?  This makes me think that you won't be able
> to change WoL parameters without going through a disable step first.
> Am I misreading?

I'm not sure if this is the best fix or not. But without this change, "ethtool -s wlan0 wol u" would return "Cannot set new wake-on-lan settings: Operation not supported". Yes, you have to disable it first in order to change the WoL parameters.

> 
> >  	if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
> >  		return -EOPNOTSUPP;
> >
> > -	if (wol->wolopts & WAKE_UCAST) criteria |= EHS_WAKE_ON_UNICAST_DATA;
> > -	if (wol->wolopts & WAKE_MCAST) criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> > -	if (wol->wolopts & WAKE_BCAST) criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> > -	if (wol->wolopts & WAKE_PHY)   criteria |= EHS_WAKE_ON_MAC_EVENT;
> > +	if (wol->wolopts & WAKE_UCAST)
> > +		criteria |= EHS_WAKE_ON_UNICAST_DATA;
> > +	if (wol->wolopts & WAKE_MCAST)
> > +		criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> > +	if (wol->wolopts & WAKE_BCAST)
> > +		criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> > +	if (wol->wolopts & WAKE_PHY)
> > +		criteria |= EHS_WAKE_ON_MAC_EVENT;
> > +	if (wol->wolopts == 0)
> > +		criteria |= EHS_REMOVE_WAKEUP;
> >
> >  	return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
> >  }
> 
> The reformatting is a distraction.  It would be better to do just
> the fix part separately, especially if you are targetting 2.6.32.

Without the reformatting, the change would be like this:

+	if (wol->wolopts == 0)    criteria |= EHS_REMOVE_WAKEUP;

But the "checkpatch.pl" script gave me an error on that:
"ERROR: trailing statements should be on next line"


Thanks,

Bing

> John
> --
> John W. Linville		Someday the world will need a hero, and you
> linville at tuxdriver.com			might be all we have.  Be ready.


From colin.bates at gmx.co.uk  Sat Nov  7 03:00:33 2009
From: colin.bates at gmx.co.uk (Colin Bates)
Date: Sat, 7 Nov 2009 08:00:33 +0000
Subject: Firmware loads twice.
In-Reply-To: <69f617130911041659r4889f9e2gacf1c32706f137c0@mail.gmail.com>
References: <200911042325.18594.colin.bates@gmx.co.uk>
	<69f617130911041659r4889f9e2gacf1c32706f137c0@mail.gmail.com>
Message-ID: <200911070800.33844.colin.bates@gmx.co.uk>

On Thursday 05 November 2009 00:59:39 Mok Keith wrote:
> Hi,
>
> Check you udev rules, I encounter this before which finally found out
> to be a bug in the old version of udev which openembedded used.
> I remove the file (/etc/udev/rules.d/udev.rules) which duplicated call
> to firmware.sh.
>
> Cheer,
> Keith
>
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev

Thanks Keith,

I deleted the offending line in the udev.rules and now all is well. Obvious 
once you pointed it out. I never twigged that the udev.rule adding 
firmware.sh to the run queue when it was also hardcoded in the kernel would 
be a problem.

Cheers,

Colin


From kalle.valo at iki.fi  Sat Nov  7 05:53:51 2009
From: kalle.valo at iki.fi (Kalle Valo)
Date: Sat, 07 Nov 2009 12:53:51 +0200
Subject: [PATCH] Libertas: Fix issues while configuring host sleep
In-Reply-To: <477F20668A386D41ADCC57781B1F704306E01F78F3@SC-VEXCH1.marvell.com>
	(Bing Zhao's message of "Fri\, 6 Nov 2009 13\:27\:50 -0800")
References: <1257383195-951-1-git-send-email-bzhao@marvell.com>
	<20091106201924.GH2782@tuxdriver.com>
	<477F20668A386D41ADCC57781B1F704306E01F78F3@SC-VEXCH1.marvell.com>
Message-ID: <87hbt6fvwg.fsf@purkki.valot.fi>

Bing Zhao <bzhao at marvell.com> writes:

>> The reformatting is a distraction.  It would be better to do just
>> the fix part separately, especially if you are targetting 2.6.32.
>
> Without the reformatting, the change would be like this:
>
> +	if (wol->wolopts == 0)    criteria |= EHS_REMOVE_WAKEUP;
>
> But the "checkpatch.pl" script gave me an error on that:
> "ERROR: trailing statements should be on next line"

You can do the reformatting in the first patch and the second patch
would contain the actual fix.

-- 
Kalle Valo


From ben at decadent.org.uk  Sat Nov  7 17:00:03 2009
From: ben at decadent.org.uk (Ben Hutchings)
Date: Sat, 07 Nov 2009 22:00:03 +0000
Subject: [PATCH 50/75] libertas: declare MODULE_FIRMWARE
Message-ID: <1257631203.15927.462.camel@localhost>

Signed-off-by: Ben Hutchings <ben at decadent.org.uk>
---
 drivers/net/wireless/libertas/if_cs.c   |    1 +
 drivers/net/wireless/libertas/if_sdio.c |    6 ++++++
 drivers/net/wireless/libertas/if_spi.c  |    4 ++++
 drivers/net/wireless/libertas/if_usb.c  |    2 ++
 4 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/libertas/if_cs.c b/drivers/net/wireless/libertas/if_cs.c
index 9127d2a..9834e3f 100644
--- a/drivers/net/wireless/libertas/if_cs.c
+++ b/drivers/net/wireless/libertas/if_cs.c
@@ -48,6 +48,7 @@
 MODULE_AUTHOR("Holger Schurig <hs4233 at mail.mn-solutions.de>");
 MODULE_DESCRIPTION("Driver for Marvell 83xx compact flash WLAN cards");
 MODULE_LICENSE("GPL");
+MODULE_FIRMWARE("libertas_cs_helper.fw");
 


diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
index 9716728..09fcfad 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -99,6 +99,12 @@ static struct if_sdio_model if_sdio_models[] = {
 		.firmware = "sd8688.bin",
 	},
 };
+MODULE_FIRMWARE("sd8385_helper.bin");
+MODULE_FIRMWARE("sd8385.bin");
+MODULE_FIRMWARE("sd8686_helper.bin");
+MODULE_FIRMWARE("sd8686.bin");
+MODULE_FIRMWARE("sd8688_helper.bin");
+MODULE_FIRMWARE("sd8688.bin");
 
 struct if_sdio_packet {
 	struct if_sdio_packet	*next;
diff --git a/drivers/net/wireless/libertas/if_spi.c b/drivers/net/wireless/libertas/if_spi.c
index d6a48dd..bf4bfba 100644
--- a/drivers/net/wireless/libertas/if_spi.c
+++ b/drivers/net/wireless/libertas/if_spi.c
@@ -902,6 +902,10 @@ static int if_spi_calculate_fw_names(u16 card_id,
 		 chip_id_to_device_name[i].name);
 	return 0;
 }
+MODULE_FIRMWARE("libertas/gspi8385_hlp.bin");
+MODULE_FIRMWARE("libertas/gspi8385.bin");
+MODULE_FIRMWARE("libertas/gspi8686_hlp.bin");
+MODULE_FIRMWARE("libertas/gspi8686.bin");
 
 static int __devinit if_spi_probe(struct spi_device *spi)
 {
diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
index f12d667..65e1745 100644
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -28,6 +28,8 @@
 static char *lbs_fw_name = "usb8388.bin";
 module_param_named(fw_name, lbs_fw_name, charp, 0644);
 
+MODULE_FIRMWARE("usb8388.bin");
+
 static struct usb_device_id if_usb_table[] = {
 	/* Enter the device signature inside */
 	{ USB_DEVICE(0x1286, 0x2001) },
-- 
1.6.5.2





From holgerschurig at googlemail.com  Mon Nov  9 03:07:42 2009
From: holgerschurig at googlemail.com (Holger Schurig)
Date: Mon, 09 Nov 2009 09:07:42 +0100
Subject: [PATCH 50/75] libertas: declare MODULE_FIRMWARE
In-Reply-To: <1257631203.15927.462.camel@localhost>
References: <1257631203.15927.462.camel@localhost>
Message-ID: <m37hu09l4h.wl%holgerschurig@gmail.com>

At Sat, 07 Nov 2009 22:00:03 +0000,
Ben Hutchings wrote:
> diff --git a/drivers/net/wireless/libertas/if_cs.c b/drivers/net/wireless/libertas/if_cs.c
> index 9127d2a..9834e3f 100644
> --- a/drivers/net/wireless/libertas/if_cs.c
> +++ b/drivers/net/wireless/libertas/if_cs.c
> @@ -48,6 +48,7 @@
>  MODULE_AUTHOR("Holger Schurig <hs4233 at mail.mn-solutions.de>");
>  MODULE_DESCRIPTION("Driver for Marvell 83xx compact flash WLAN cards");
>  MODULE_LICENSE("GPL");
> +MODULE_FIRMWARE("libertas_cs_helper.fw");

Do you intentionally only define specify the helper firmware? The
device won't be working without loading "libertas_cs.fw" as well.

Do you have any pointer for me to what MDOULE_FIRMWARE does?  What
user-space tool does it it for what purpose?


--
http://www.holgerschurig.de


From daniel at caiaq.de  Mon Nov  9 10:53:54 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Mon, 9 Nov 2009 16:53:54 +0100
Subject: Libertas related kernel crash
In-Reply-To: <20091105120549.GQ14091@buzzloop.caiaq.de>
References: <20091105120549.GQ14091@buzzloop.caiaq.de>
Message-ID: <20091109155354.GC14091@buzzloop.caiaq.de>

On Thu, Nov 05, 2009 at 01:05:49PM +0100, Daniel Mack wrote:
> On an ARM (PXA300) embdedded platform with a libertas chip connected via
> SDIO, we happen to see the kernel Ooops below once in a while.
> 
> Any pointer on where to dig?

Some more input on this. Oopses similar to the one below are likely
triggered when switching from Ad-hoc to managed mode multiple times in a
row, and something seems corrupt the memory badly. I've searched for the
obvious (double frees, out-of-bound writes etc), but I couldn't find
anything yet. It is, however, related to the wireless core and/or the
libertas driver.

Any ideas, anyone?

Daniel


> [ 2659.715112] Unable to handle kernel NULL pointer dereference at virtual address 00000001
> [ 2659.723164] pgd = c5ca8000
> [ 2659.725846] [00000001] *pgd=a5cbc031, *pte=00000000, *ppte=00000000
> [ 2659.732062] Internal error: Oops: 13 [#4]
> [ 2659.736041] last sysfs file: /sys/devices/platform/pxa2xx-mci.0/mmc_host/mmc0/mmc0:0001/mmc0:0001:1/net/wlan0/address
> [ 2659.746573] Modules linked in: eeti_ts libertas_sdio pxamci ds2760_battery w1_ds2760 wire
> [ 2659.754698] CPU: 0    Tainted: G      D     (2.6.32-rc6 #1)
> [ 2659.760255] PC is at kmem_cache_alloc+0x30/0x90
> [ 2659.764774] LR is at inet_bind_bucket_create+0x18/0x5c
> [ 2659.769876] pc : [<c00a28d8>]    lr : [<c02a4b24>]    psr: 20000093
> [ 2659.769887] sp : c5c27d88  ip : c78ae4a0  fp : 00006e49
> [ 2659.781279] r10: 00008928  r9 : c04fcfac  r8 : c0532148
> [ 2659.786466] r7 : 00000020  r6 : 00000020  r5 : 60000013  r4 : 00000001
> [ 2659.792945] r3 : 00000000  r2 : c78ae4a0  r1 : 00000020  r0 : c04d42e4
> [ 2659.799427] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment user
> [ 2659.806602] Control: 0000397f  Table: a5ca8018  DAC: 00000015
> [ 2659.812304] Process p0-renderer (pid: 1527, stack limit = 0xc5c26278)
> [ 2659.818697] Stack: (0xc5c27d88 to 0xc5c28000)
> [ 2659.823029] 7d80:                   c5cc5300 c5cb1000 c5c18800 c78ae4a0 00008928 00008928
> [ 2659.831155] 7da0: 00000001 c02a4b24 c2388c2e 00000000 c7eb6200 c02a4c8c c02a4200 c2388c2d
> [ 2659.839287] 7dc0: c04fcfac 00000000 0000ee48 00008000 fb0ca8c0 c7eb6200 c04fcfac 00000000
> [ 2659.847412] 7de0: 000038e5 fb0ca8c0 fb0ca8c0 c7eb6200 00000000 c02a4e28 c02a40e4 00000000
> [ 2659.855543] 7e00: 00000000 00000000 00000000 c02b99d4 00000001 00000000 c5c27f08 00000000
> [ 2659.863669] 7e20: c5c7b500 000005a8 00000000 00000000 000200da c5c7b500 c0069a74 c5c27e3c
> [ 2659.871802] 7e40: c5c27e3c c0049fdc be96a8fc c0275d70 c5c27e88 00000006 00000005 00000001
> [ 2659.879933] 7e60: 00000000 00000000 00000000 fb0ca8c0 1d0ca8c0 00000000 00000000 00000000
> [ 2659.888057] 7e80: 00000000 00000000 00000000 00000000 00000006 38e50000 00000000 c7ff6e00
> [ 2659.896183] 7ea0: 000063f8 c5c27f08 00000010 c7eb6200 c5c27f08 c00440c4 c5c26000 c76cd2c0
> [ 2659.904314] 7ec0: 00000802 c02c4f70 0000c1ff 00000001 00000000 00000000 00000000 00045108
> [ 2659.912441] 7ee0: 00000010 c76cd2c0 00045108 00000010 c5c27f08 c00440c4 c5c26000 40343800
> [ 2659.920573] 7f00: 00044440 c0276888 38e50002 fb0ca8c0 00000000 00000000 000063f8 00000000
> [ 2659.928698] 7f20: 00000000 be96a858 c5c27f48 000450c0 000000c5 c00440c4 c5c26000 40343800
> [ 2659.936829] 7f40: 00044440 c00a9864 000063f8 00000000 00000005 c047c1ff 00000001 00000000
> [ 2659.944952] 7f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000003
> [ 2659.953078] 7f80: 00000000 c7b5aa00 00000000 00000000 00000000 00046cb8 00045108 40370ef8
> [ 2659.961203] 7fa0: 0000011b c0043f40 00046cb8 00045108 0000000a 00045108 00000010 0000001c
> [ 2659.969328] 7fc0: 00046cb8 00045108 40370ef8 0000011b 00000000 00043178 40343800 00044440
> [ 2659.977451] 7fe0: 40371050 be96a968 4035b3c8 40790638 60000010 0000000a 00000000 00000000
> [ 2659.985599] [<c00a28d8>] (kmem_cache_alloc+0x30/0x90) from [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c)
> [ 2659.995296] [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c) from [<c02a4c8c>] (__inet_hash_connect+0x124/0x280)
> [ 2660.005415] [<c02a4c8c>] (__inet_hash_connect+0x124/0x280) from [<c02a4e28>] (inet_hash_connect+0x40/0x50)
> [ 2660.015034] [<c02a4e28>] (inet_hash_connect+0x40/0x50) from [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420)
> [ 2660.024211] [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420) from [<c02c4f70>] (inet_stream_connect+0xac/0x26c)
> [ 2660.033653] [<c02c4f70>] (inet_stream_connect+0xac/0x26c) from [<c0276888>] (sys_connect+0x6c/0x90)
> [ 2660.042662] [<c0276888>] (sys_connect+0x6c/0x90) from [<c0043f40>] (ret_fast_syscall+0x0/0x28)
> [ 2660.051228] Code: e5904080 e5907090 e3540000 1590308c (17943103) [ 2660.057440] ---[ end trace 416b23b4578ffa42 ]---
> [ 2660.062021] Kernel panic - not syncing: Fatal exception in interrupt
> [ 2660.068400] [<c00486cc>] (unwind_backtrace+0x0/0xdc) from [<c0351758>] (panic+0x34/0x120)
> [ 2660.076555] [<c0351758>] (panic+0x34/0x120) from [<c004758c>] (die+0x14c/0x178)
> [ 2660.083823] [<c004758c>] (die+0x14c/0x178) from [<c0049900>] (__do_kernel_fault+0x68/0x80)
> [ 2660.092060] [<c0049900>] (__do_kernel_fault+0x68/0x80) from [<c004b678>] (do_alignment+0x59c/0x700)
> [ 2660.101067] [<c004b678>] (do_alignment+0x59c/0x700) from [<c00432c8>] (do_DataAbort+0x34/0x94)
> [ 2660.109649] [<c00432c8>] (do_DataAbort+0x34/0x94) from [<c0043acc>] (__dabt_svc+0x4c/0x60)
> [ 2660.117874] Exception stack(0xc5c27d40 to 0xc5c27d88)
> [ 2660.122898] 7d40: c04d42e4 00000020 c78ae4a0 00000000 00000001 60000013 00000020 00000020
> [ 2660.131046] 7d60: c0532148 c04fcfac 00008928 00006e49 c78ae4a0 c5c27d88 c02a4b24 c00a28d8
> [ 2660.139189] 7d80: 20000093 ffffffff
> [ 2660.142673] [<c0043acc>] (__dabt_svc+0x4c/0x60) from [<c00a28d8>] (kmem_cache_alloc+0x30/0x90)
> [ 2660.151265] [<c00a28d8>] (kmem_cache_alloc+0x30/0x90) from [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c)
> [ 2660.160998] [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c) from [<c02a4c8c>] (__inet_hash_connect+0x124/0x280)
> [ 2660.171148] [<c02a4c8c>] (__inet_hash_connect+0x124/0x280) from [<c02a4e28>] (inet_hash_connect+0x40/0x50)
> [ 2660.180780] [<c02a4e28>] (inet_hash_connect+0x40/0x50) from [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420)
> [ 2660.189971] [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420) from [<c02c4f70>] (inet_stream_connect+0xac/0x26c)
> [ 2660.199424] [<c02c4f70>] (inet_stream_connect+0xac/0x26c) from [<c0276888>] (sys_connect+0x6c/0x90)
> [ 2660.208443] [<c0276888>] (sys_connect+0x6c/0x90) from [<c0043f40>] (ret_fast_syscall+0x0/0x28)
> 


From bzhao at marvell.com  Mon Nov  9 19:00:55 2009
From: bzhao at marvell.com (Bing Zhao)
Date: Mon, 9 Nov 2009 16:00:55 -0800
Subject: [PATCH] Libertas: Fix issues while configuring host sleep
In-Reply-To: <87hbt6fvwg.fsf@purkki.valot.fi>
References: <1257383195-951-1-git-send-email-bzhao@marvell.com>
	<20091106201924.GH2782@tuxdriver.com>
	<477F20668A386D41ADCC57781B1F704306E01F78F3@SC-VEXCH1.marvell.com>
	<87hbt6fvwg.fsf@purkki.valot.fi>
Message-ID: <477F20668A386D41ADCC57781B1F704306E249DDDA@SC-VEXCH1.marvell.com>

Hi Kalle,

> -----Original Message-----
> From: Kalle Valo [mailto:kalle.valo at gmail.com] On Behalf Of Kalle Valo
> Sent: Saturday, November 07, 2009 2:54 AM
> To: Bing Zhao
> Cc: John W. Linville; libertas-dev at lists.infradead.org; linux-wireless at vger.kernel.org; Amitkumar
> Karwar
> Subject: Re: [PATCH] Libertas: Fix issues while configuring host sleep
> 
> Bing Zhao <bzhao at marvell.com> writes:
> 
> >> The reformatting is a distraction.  It would be better to do just
> >> the fix part separately, especially if you are targetting 2.6.32.
> >
> > Without the reformatting, the change would be like this:
> >
> > +	if (wol->wolopts == 0)    criteria |= EHS_REMOVE_WAKEUP;
> >
> > But the "checkpatch.pl" script gave me an error on that:
> > "ERROR: trailing statements should be on next line"
> 
> You can do the reformatting in the first patch and the second patch
> would contain the actual fix.

I will re-submit as suggested.

Thanks,

Bing

> 
> --
> Kalle Valo


From bzhao at marvell.com  Mon Nov  9 19:06:14 2009
From: bzhao at marvell.com (Bing Zhao)
Date: Mon, 9 Nov 2009 16:06:14 -0800
Subject: [PATCH] Libertas: Fix issues while configuring host sleep
In-Reply-To: <477F20668A386D41ADCC57781B1F704306E01F78F3@SC-VEXCH1.marvell.com>
References: <1257383195-951-1-git-send-email-bzhao@marvell.com>
	<20091106201924.GH2782@tuxdriver.com>
	<477F20668A386D41ADCC57781B1F704306E01F78F3@SC-VEXCH1.marvell.com>
Message-ID: <477F20668A386D41ADCC57781B1F704306E249DDDC@SC-VEXCH1.marvell.com>

Hi John,

> -----Original Message-----
> From: libertas-dev-bounces at lists.infradead.org [mailto:libertas-dev-bounces at lists.infradead.org] On
> Behalf Of Bing Zhao
> Sent: Friday, November 06, 2009 1:28 PM
> To: John W. Linville
> Cc: Amitkumar Karwar; linux-wireless at vger.kernel.org; libertas-dev at lists.infradead.org
> Subject: RE: [PATCH] Libertas: Fix issues while configuring host sleep
> 
> Hi John,
> 
> > -----Original Message-----
> > From: John W. Linville [mailto:linville at tuxdriver.com]
> > Sent: Friday, November 06, 2009 12:19 PM
> > To: Bing Zhao
> > Cc: libertas-dev at lists.infradead.org; linux-wireless at vger.kernel.org; Amitkumar Karwar
> > Subject: Re: [PATCH] Libertas: Fix issues while configuring host sleep
> >
> > On Wed, Nov 04, 2009 at 05:06:35PM -0800, Bing Zhao wrote:
> > > From: Amitkumar Karwar <akarwar at marvell.com>
> > >
> > > Configuration of wake-on-lan for unicast, multicast, broadcast, physical
> > > activity was not working. Kernel panic issue was there when user tries to
> > > disable WOL. Fixed them.
> > >
> > > Signed-off-by: Amitkumar Karwar <akarwar at marvell.com>
> > > Signed-off-by: Bing Zhao <bzhao at marvell.com>
> > > ---
> > >  drivers/net/wireless/libertas/ethtool.c |   16 +++++++++++-----
> > >  1 files changed, 11 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
> > > index 039b555..eeda6d7 100644
> > > --- a/drivers/net/wireless/libertas/ethtool.c
> > > +++ b/drivers/net/wireless/libertas/ethtool.c
> > > @@ -169,16 +169,22 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
> > >  	struct lbs_private *priv = dev->ml_priv;
> > >  	uint32_t criteria = 0;
> > >
> > > -	if (priv->wol_criteria == 0xffffffff && wol->wolopts)
> > > +	if (priv->wol_criteria != 0xffffffff && wol->wolopts)
> > >  		return -EOPNOTSUPP;
> >
> > Are you sure about this?  This makes me think that you won't be able
> > to change WoL parameters without going through a disable step first.
> > Am I misreading?
> 
> I'm not sure if this is the best fix or not. But without this change, "ethtool -s wlan0 wol u" would
> return "Cannot set new wake-on-lan settings: Operation not supported". Yes, you have to disable it
> first in order to change the WoL parameters.
> 

We can probably just remove the check so that we can change the WoL settings without disabling first.

-	if (priv->wol_criteria == 0xffffffff && wol->wolopts)
-  		return -EOPNOTSUPP;

I will re-send the patch.

Thanks,

Bing



From bzhao at marvell.com  Mon Nov  9 21:04:12 2009
From: bzhao at marvell.com (Bing Zhao)
Date: Mon,  9 Nov 2009 18:04:12 -0800
Subject: [PATCH 1/2] Libertas: coding style cleanup in ethtool.c
Message-ID: <1257818653-13460-1-git-send-email-bzhao@marvell.com>

Signed-off-by: Bing Zhao <bzhao at marvell.com>
---
 drivers/net/wireless/libertas/ethtool.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
index 039b555..6efa388 100644
--- a/drivers/net/wireless/libertas/ethtool.c
+++ b/drivers/net/wireless/libertas/ethtool.c
@@ -175,10 +175,14 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
 	if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
 		return -EOPNOTSUPP;
 
-	if (wol->wolopts & WAKE_UCAST) criteria |= EHS_WAKE_ON_UNICAST_DATA;
-	if (wol->wolopts & WAKE_MCAST) criteria |= EHS_WAKE_ON_MULTICAST_DATA;
-	if (wol->wolopts & WAKE_BCAST) criteria |= EHS_WAKE_ON_BROADCAST_DATA;
-	if (wol->wolopts & WAKE_PHY)   criteria |= EHS_WAKE_ON_MAC_EVENT;
+	if (wol->wolopts & WAKE_UCAST)
+		criteria |= EHS_WAKE_ON_UNICAST_DATA;
+	if (wol->wolopts & WAKE_MCAST)
+		criteria |= EHS_WAKE_ON_MULTICAST_DATA;
+	if (wol->wolopts & WAKE_BCAST)
+		criteria |= EHS_WAKE_ON_BROADCAST_DATA;
+	if (wol->wolopts & WAKE_PHY)
+		criteria |= EHS_WAKE_ON_MAC_EVENT;
 
 	return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
 }
-- 
1.5.3.6



From bzhao at marvell.com  Mon Nov  9 21:04:13 2009
From: bzhao at marvell.com (Bing Zhao)
Date: Mon,  9 Nov 2009 18:04:13 -0800
Subject: [PATCH 2/2] Libertas: fix issues while configuring host sleep using
	ethtool wol
In-Reply-To: <1257818653-13460-1-git-send-email-bzhao@marvell.com>
References: <1257818653-13460-1-git-send-email-bzhao@marvell.com>
Message-ID: <1257818653-13460-2-git-send-email-bzhao@marvell.com>

Configuration of wake-on-lan for unicast, multicast, broadcast, physical
activity was not working. Kernel panic issue was there when user tries to
disable WOL. Fixed them.

Signed-off-by: Amitkumar Karwar <akarwar at marvell.com>
Signed-off-by: Bing Zhao <bzhao at marvell.com>
---
 drivers/net/wireless/libertas/ethtool.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
index 6efa388..53d56ab 100644
--- a/drivers/net/wireless/libertas/ethtool.c
+++ b/drivers/net/wireless/libertas/ethtool.c
@@ -169,9 +169,6 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
 	struct lbs_private *priv = dev->ml_priv;
 	uint32_t criteria = 0;
 
-	if (priv->wol_criteria == 0xffffffff && wol->wolopts)
-		return -EOPNOTSUPP;
-
 	if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
 		return -EOPNOTSUPP;
 
@@ -183,6 +180,8 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
 		criteria |= EHS_WAKE_ON_BROADCAST_DATA;
 	if (wol->wolopts & WAKE_PHY)
 		criteria |= EHS_WAKE_ON_MAC_EVENT;
+	if (wol->wolopts == 0)
+		criteria |= EHS_REMOVE_WAKEUP;
 
 	return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
 }
-- 
1.5.3.6



From dcbw at redhat.com  Tue Nov 10 01:32:54 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 09 Nov 2009 22:32:54 -0800
Subject: [PATCH 50/75] libertas: declare MODULE_FIRMWARE
In-Reply-To: <m37hu09l4h.wl%holgerschurig@gmail.com>
References: <1257631203.15927.462.camel@localhost>
	<m37hu09l4h.wl%holgerschurig@gmail.com>
Message-ID: <1257834774.15493.34.camel@localhost.localdomain>

On Mon, 2009-11-09 at 09:07 +0100, Holger Schurig wrote:
> At Sat, 07 Nov 2009 22:00:03 +0000,
> Ben Hutchings wrote:
> > diff --git a/drivers/net/wireless/libertas/if_cs.c b/drivers/net/wireless/libertas/if_cs.c
> > index 9127d2a..9834e3f 100644
> > --- a/drivers/net/wireless/libertas/if_cs.c
> > +++ b/drivers/net/wireless/libertas/if_cs.c
> > @@ -48,6 +48,7 @@
> >  MODULE_AUTHOR("Holger Schurig <hs4233 at mail.mn-solutions.de>");
> >  MODULE_DESCRIPTION("Driver for Marvell 83xx compact flash WLAN cards");
> >  MODULE_LICENSE("GPL");
> > +MODULE_FIRMWARE("libertas_cs_helper.fw");
> 
> Do you intentionally only define specify the helper firmware? The
> device won't be working without loading "libertas_cs.fw" as well.
> 
> Do you have any pointer for me to what MDOULE_FIRMWARE does?  What
> user-space tool does it it for what purpose?

It's nice information to know from 'modinfo' or other uses so that we
might be able to find the firmware automatically.  Right now actually
PackageKit will figure out  missing firmware from udev when udev can't
find the right firmware, but having it in 'modinfo' is useful too.

Honestly I think we should actually reorganize the firmware and put it
in /lib/firmware/libertas or something.

Dan




From dcbw at redhat.com  Tue Nov 10 01:33:24 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 09 Nov 2009 22:33:24 -0800
Subject: [PATCH 1/2] Libertas: coding style cleanup in ethtool.c
In-Reply-To: <1257818653-13460-1-git-send-email-bzhao@marvell.com>
References: <1257818653-13460-1-git-send-email-bzhao@marvell.com>
Message-ID: <1257834804.15493.35.camel@localhost.localdomain>

On Mon, 2009-11-09 at 18:04 -0800, Bing Zhao wrote:
> Signed-off-by: Bing Zhao <bzhao at marvell.com>

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

> ---
>  drivers/net/wireless/libertas/ethtool.c |   12 ++++++++----
>  1 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
> index 039b555..6efa388 100644
> --- a/drivers/net/wireless/libertas/ethtool.c
> +++ b/drivers/net/wireless/libertas/ethtool.c
> @@ -175,10 +175,14 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
>  	if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
>  		return -EOPNOTSUPP;
>  
> -	if (wol->wolopts & WAKE_UCAST) criteria |= EHS_WAKE_ON_UNICAST_DATA;
> -	if (wol->wolopts & WAKE_MCAST) criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> -	if (wol->wolopts & WAKE_BCAST) criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> -	if (wol->wolopts & WAKE_PHY)   criteria |= EHS_WAKE_ON_MAC_EVENT;
> +	if (wol->wolopts & WAKE_UCAST)
> +		criteria |= EHS_WAKE_ON_UNICAST_DATA;
> +	if (wol->wolopts & WAKE_MCAST)
> +		criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> +	if (wol->wolopts & WAKE_BCAST)
> +		criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> +	if (wol->wolopts & WAKE_PHY)
> +		criteria |= EHS_WAKE_ON_MAC_EVENT;
>  
>  	return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
>  }



From dcbw at redhat.com  Tue Nov 10 01:33:53 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 09 Nov 2009 22:33:53 -0800
Subject: [PATCH 2/2] Libertas: fix issues while configuring host sleep
	using ethtool wol
In-Reply-To: <1257818653-13460-2-git-send-email-bzhao@marvell.com>
References: <1257818653-13460-1-git-send-email-bzhao@marvell.com>
	<1257818653-13460-2-git-send-email-bzhao@marvell.com>
Message-ID: <1257834833.15493.36.camel@localhost.localdomain>

On Mon, 2009-11-09 at 18:04 -0800, Bing Zhao wrote:
> Configuration of wake-on-lan for unicast, multicast, broadcast, physical
> activity was not working. Kernel panic issue was there when user tries to
> disable WOL. Fixed them.
> 
> Signed-off-by: Amitkumar Karwar <akarwar at marvell.com>
> Signed-off-by: Bing Zhao <bzhao at marvell.com>

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

> ---
>  drivers/net/wireless/libertas/ethtool.c |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
> index 6efa388..53d56ab 100644
> --- a/drivers/net/wireless/libertas/ethtool.c
> +++ b/drivers/net/wireless/libertas/ethtool.c
> @@ -169,9 +169,6 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
>  	struct lbs_private *priv = dev->ml_priv;
>  	uint32_t criteria = 0;
>  
> -	if (priv->wol_criteria == 0xffffffff && wol->wolopts)
> -		return -EOPNOTSUPP;
> -
>  	if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
>  		return -EOPNOTSUPP;
>  
> @@ -183,6 +180,8 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
>  		criteria |= EHS_WAKE_ON_BROADCAST_DATA;
>  	if (wol->wolopts & WAKE_PHY)
>  		criteria |= EHS_WAKE_ON_MAC_EVENT;
> +	if (wol->wolopts == 0)
> +		criteria |= EHS_REMOVE_WAKEUP;
>  
>  	return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
>  }



From dcbw at redhat.com  Tue Nov 10 01:51:33 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 09 Nov 2009 22:51:33 -0800
Subject: Libertas related kernel crash
In-Reply-To: <20091109155354.GC14091@buzzloop.caiaq.de>
References: <20091105120549.GQ14091@buzzloop.caiaq.de>
	<20091109155354.GC14091@buzzloop.caiaq.de>
Message-ID: <1257835893.15493.37.camel@localhost.localdomain>

On Mon, 2009-11-09 at 16:53 +0100, Daniel Mack wrote:
> On Thu, Nov 05, 2009 at 01:05:49PM +0100, Daniel Mack wrote:
> > On an ARM (PXA300) embdedded platform with a libertas chip connected via
> > SDIO, we happen to see the kernel Ooops below once in a while.
> > 
> > Any pointer on where to dig?
> 
> Some more input on this. Oopses similar to the one below are likely
> triggered when switching from Ad-hoc to managed mode multiple times in a
> row, and something seems corrupt the memory badly. I've searched for the
> obvious (double frees, out-of-bound writes etc), but I couldn't find
> anything yet. It is, however, related to the wireless core and/or the
> libertas driver.

Probably just libertas.  Any chance you can enable debugging options
(either in libertas, or in the kernel allocator) to help narrow down the
issue?

Dan

> Any ideas, anyone?
> 
> Daniel
> 
> 
> > [ 2659.715112] Unable to handle kernel NULL pointer dereference at virtual address 00000001
> > [ 2659.723164] pgd = c5ca8000
> > [ 2659.725846] [00000001] *pgd=a5cbc031, *pte=00000000, *ppte=00000000
> > [ 2659.732062] Internal error: Oops: 13 [#4]
> > [ 2659.736041] last sysfs file: /sys/devices/platform/pxa2xx-mci.0/mmc_host/mmc0/mmc0:0001/mmc0:0001:1/net/wlan0/address
> > [ 2659.746573] Modules linked in: eeti_ts libertas_sdio pxamci ds2760_battery w1_ds2760 wire
> > [ 2659.754698] CPU: 0    Tainted: G      D     (2.6.32-rc6 #1)
> > [ 2659.760255] PC is at kmem_cache_alloc+0x30/0x90
> > [ 2659.764774] LR is at inet_bind_bucket_create+0x18/0x5c
> > [ 2659.769876] pc : [<c00a28d8>]    lr : [<c02a4b24>]    psr: 20000093
> > [ 2659.769887] sp : c5c27d88  ip : c78ae4a0  fp : 00006e49
> > [ 2659.781279] r10: 00008928  r9 : c04fcfac  r8 : c0532148
> > [ 2659.786466] r7 : 00000020  r6 : 00000020  r5 : 60000013  r4 : 00000001
> > [ 2659.792945] r3 : 00000000  r2 : c78ae4a0  r1 : 00000020  r0 : c04d42e4
> > [ 2659.799427] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment user
> > [ 2659.806602] Control: 0000397f  Table: a5ca8018  DAC: 00000015
> > [ 2659.812304] Process p0-renderer (pid: 1527, stack limit = 0xc5c26278)
> > [ 2659.818697] Stack: (0xc5c27d88 to 0xc5c28000)
> > [ 2659.823029] 7d80:                   c5cc5300 c5cb1000 c5c18800 c78ae4a0 00008928 00008928
> > [ 2659.831155] 7da0: 00000001 c02a4b24 c2388c2e 00000000 c7eb6200 c02a4c8c c02a4200 c2388c2d
> > [ 2659.839287] 7dc0: c04fcfac 00000000 0000ee48 00008000 fb0ca8c0 c7eb6200 c04fcfac 00000000
> > [ 2659.847412] 7de0: 000038e5 fb0ca8c0 fb0ca8c0 c7eb6200 00000000 c02a4e28 c02a40e4 00000000
> > [ 2659.855543] 7e00: 00000000 00000000 00000000 c02b99d4 00000001 00000000 c5c27f08 00000000
> > [ 2659.863669] 7e20: c5c7b500 000005a8 00000000 00000000 000200da c5c7b500 c0069a74 c5c27e3c
> > [ 2659.871802] 7e40: c5c27e3c c0049fdc be96a8fc c0275d70 c5c27e88 00000006 00000005 00000001
> > [ 2659.879933] 7e60: 00000000 00000000 00000000 fb0ca8c0 1d0ca8c0 00000000 00000000 00000000
> > [ 2659.888057] 7e80: 00000000 00000000 00000000 00000000 00000006 38e50000 00000000 c7ff6e00
> > [ 2659.896183] 7ea0: 000063f8 c5c27f08 00000010 c7eb6200 c5c27f08 c00440c4 c5c26000 c76cd2c0
> > [ 2659.904314] 7ec0: 00000802 c02c4f70 0000c1ff 00000001 00000000 00000000 00000000 00045108
> > [ 2659.912441] 7ee0: 00000010 c76cd2c0 00045108 00000010 c5c27f08 c00440c4 c5c26000 40343800
> > [ 2659.920573] 7f00: 00044440 c0276888 38e50002 fb0ca8c0 00000000 00000000 000063f8 00000000
> > [ 2659.928698] 7f20: 00000000 be96a858 c5c27f48 000450c0 000000c5 c00440c4 c5c26000 40343800
> > [ 2659.936829] 7f40: 00044440 c00a9864 000063f8 00000000 00000005 c047c1ff 00000001 00000000
> > [ 2659.944952] 7f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000003
> > [ 2659.953078] 7f80: 00000000 c7b5aa00 00000000 00000000 00000000 00046cb8 00045108 40370ef8
> > [ 2659.961203] 7fa0: 0000011b c0043f40 00046cb8 00045108 0000000a 00045108 00000010 0000001c
> > [ 2659.969328] 7fc0: 00046cb8 00045108 40370ef8 0000011b 00000000 00043178 40343800 00044440
> > [ 2659.977451] 7fe0: 40371050 be96a968 4035b3c8 40790638 60000010 0000000a 00000000 00000000
> > [ 2659.985599] [<c00a28d8>] (kmem_cache_alloc+0x30/0x90) from [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c)
> > [ 2659.995296] [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c) from [<c02a4c8c>] (__inet_hash_connect+0x124/0x280)
> > [ 2660.005415] [<c02a4c8c>] (__inet_hash_connect+0x124/0x280) from [<c02a4e28>] (inet_hash_connect+0x40/0x50)
> > [ 2660.015034] [<c02a4e28>] (inet_hash_connect+0x40/0x50) from [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420)
> > [ 2660.024211] [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420) from [<c02c4f70>] (inet_stream_connect+0xac/0x26c)
> > [ 2660.033653] [<c02c4f70>] (inet_stream_connect+0xac/0x26c) from [<c0276888>] (sys_connect+0x6c/0x90)
> > [ 2660.042662] [<c0276888>] (sys_connect+0x6c/0x90) from [<c0043f40>] (ret_fast_syscall+0x0/0x28)
> > [ 2660.051228] Code: e5904080 e5907090 e3540000 1590308c (17943103) [ 2660.057440] ---[ end trace 416b23b4578ffa42 ]---
> > [ 2660.062021] Kernel panic - not syncing: Fatal exception in interrupt
> > [ 2660.068400] [<c00486cc>] (unwind_backtrace+0x0/0xdc) from [<c0351758>] (panic+0x34/0x120)
> > [ 2660.076555] [<c0351758>] (panic+0x34/0x120) from [<c004758c>] (die+0x14c/0x178)
> > [ 2660.083823] [<c004758c>] (die+0x14c/0x178) from [<c0049900>] (__do_kernel_fault+0x68/0x80)
> > [ 2660.092060] [<c0049900>] (__do_kernel_fault+0x68/0x80) from [<c004b678>] (do_alignment+0x59c/0x700)
> > [ 2660.101067] [<c004b678>] (do_alignment+0x59c/0x700) from [<c00432c8>] (do_DataAbort+0x34/0x94)
> > [ 2660.109649] [<c00432c8>] (do_DataAbort+0x34/0x94) from [<c0043acc>] (__dabt_svc+0x4c/0x60)
> > [ 2660.117874] Exception stack(0xc5c27d40 to 0xc5c27d88)
> > [ 2660.122898] 7d40: c04d42e4 00000020 c78ae4a0 00000000 00000001 60000013 00000020 00000020
> > [ 2660.131046] 7d60: c0532148 c04fcfac 00008928 00006e49 c78ae4a0 c5c27d88 c02a4b24 c00a28d8
> > [ 2660.139189] 7d80: 20000093 ffffffff
> > [ 2660.142673] [<c0043acc>] (__dabt_svc+0x4c/0x60) from [<c00a28d8>] (kmem_cache_alloc+0x30/0x90)
> > [ 2660.151265] [<c00a28d8>] (kmem_cache_alloc+0x30/0x90) from [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c)
> > [ 2660.160998] [<c02a4b24>] (inet_bind_bucket_create+0x18/0x5c) from [<c02a4c8c>] (__inet_hash_connect+0x124/0x280)
> > [ 2660.171148] [<c02a4c8c>] (__inet_hash_connect+0x124/0x280) from [<c02a4e28>] (inet_hash_connect+0x40/0x50)
> > [ 2660.180780] [<c02a4e28>] (inet_hash_connect+0x40/0x50) from [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420)
> > [ 2660.189971] [<c02b99d4>] (tcp_v4_connect+0x2a8/0x420) from [<c02c4f70>] (inet_stream_connect+0xac/0x26c)
> > [ 2660.199424] [<c02c4f70>] (inet_stream_connect+0xac/0x26c) from [<c0276888>] (sys_connect+0x6c/0x90)
> > [ 2660.208443] [<c0276888>] (sys_connect+0x6c/0x90) from [<c0043f40>] (ret_fast_syscall+0x0/0x28)
> > 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From daniel at caiaq.de  Tue Nov 10 01:54:57 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Tue, 10 Nov 2009 07:54:57 +0100
Subject: Libertas related kernel crash
In-Reply-To: <1257835893.15493.37.camel@localhost.localdomain>
References: <20091105120549.GQ14091@buzzloop.caiaq.de>
	<20091109155354.GC14091@buzzloop.caiaq.de>
	<1257835893.15493.37.camel@localhost.localdomain>
Message-ID: <20091110065457.GL14091@buzzloop.caiaq.de>

On Mon, Nov 09, 2009 at 10:51:33PM -0800, Dan Williams wrote:
> On Mon, 2009-11-09 at 16:53 +0100, Daniel Mack wrote:
> > On Thu, Nov 05, 2009 at 01:05:49PM +0100, Daniel Mack wrote:
> > > On an ARM (PXA300) embdedded platform with a libertas chip connected via
> > > SDIO, we happen to see the kernel Ooops below once in a while.
> > > 
> > > Any pointer on where to dig?
> > 
> > Some more input on this. Oopses similar to the one below are likely
> > triggered when switching from Ad-hoc to managed mode multiple times in a
> > row, and something seems corrupt the memory badly. I've searched for the
> > obvious (double frees, out-of-bound writes etc), but I couldn't find
> > anything yet. It is, however, related to the wireless core and/or the
> > libertas driver.
> 
> Probably just libertas.  Any chance you can enable debugging options
> (either in libertas, or in the kernel allocator) to help narrow down the
> issue?

Sure. I already enabled DEBUG_VM, but that didn't spit out anything
before it crashes. Which other debug flags would you recommend to set?

Daniel


From dcbw at redhat.com  Tue Nov 10 02:02:36 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 09 Nov 2009 23:02:36 -0800
Subject: [PATCH] libertas if_usb: tiny usb-rx overhaul
In-Reply-To: <200911042313.00089.chunkeey@googlemail.com>
References: <1256924714.4030.44.camel@macbook.infradead.org>
	<1257364903.14545.51.camel@localhost.localdomain>
	<20091104211600.GE10786@tuxdriver.com>
	<200911042313.00089.chunkeey@googlemail.com>
Message-ID: <1257836556.19597.1.camel@localhost.localdomain>

On Wed, 2009-11-04 at 23:12 +0100, Christian Lamparter wrote:
> This patch reorganizes libertas' if_usb rx routines.
> 
>  - URB_ZERO_PACKET flag has no use for urbs for 
>    incoming endpoints.
>     
>  - skb_tail_pointer(skb) should be used to get
>    the right rx_buf pointer.
> 
>  - most + IPFIELD_ALIGN_OFFSET can be prevented by
>    moving skb_reserve up right after allocation.
> 
> Signed-off-by: Christian Lamparter <chunkeey at googlemail.com>

With 5.110.22p23 firmware if anyone cares...  Thanks!

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

> ---
> any Tested-by: ?
> ---
> diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
> index a8262de..f220db9 100644
> --- a/drivers/net/wireless/libertas/if_usb.c
> +++ b/drivers/net/wireless/libertas/if_usb.c
> @@ -506,17 +506,16 @@ static int __if_usb_submit_rx_urb(struct if_usb_card *cardp,
>  		goto rx_ret;
>  	}
>  
> +	skb_reserve(skb, IPFIELD_ALIGN_OFFSET);
>  	cardp->rx_skb = skb;
>  
>  	/* Fill the receive configuration URB and initialise the Rx call back */
>  	usb_fill_bulk_urb(cardp->rx_urb, cardp->udev,
>  			  usb_rcvbulkpipe(cardp->udev, cardp->ep_in),
> -			  skb->data + IPFIELD_ALIGN_OFFSET,
> +			  skb_tail_pointer(skb),
>  			  MRVDRV_ETH_RX_PACKET_BUFFER_SIZE, callbackfn,
>  			  cardp);
>  
> -	cardp->rx_urb->transfer_flags |= URB_ZERO_PACKET;
> -
>  	lbs_deb_usb2(&cardp->udev->dev, "Pointer for rx_urb %p\n", cardp->rx_urb);
>  	if ((ret = usb_submit_urb(cardp->rx_urb, GFP_ATOMIC))) {
>  		lbs_deb_usbd(&cardp->udev->dev, "Submit Rx URB failed: %d\n", ret);
> @@ -557,7 +556,7 @@ static void if_usb_receive_fwload(struct urb *urb)
>  	}
>  
>  	if (cardp->fwdnldover) {
> -		__le32 *tmp = (__le32 *)(skb->data + IPFIELD_ALIGN_OFFSET);
> +		__le32 *tmp = (__le32 *)skb->data;
>  
>  		if (tmp[0] == cpu_to_le32(CMD_TYPE_INDICATION) &&
>  		    tmp[1] == cpu_to_le32(MACREG_INT_CODE_FIRMWARE_READY)) {
> @@ -572,8 +571,7 @@ static void if_usb_receive_fwload(struct urb *urb)
>  		return;
>  	}
>  	if (cardp->bootcmdresp <= 0) {
> -		memcpy (&bootcmdresp, skb->data + IPFIELD_ALIGN_OFFSET,
> -			sizeof(bootcmdresp));
> +		memcpy(&bootcmdresp, skb->data, sizeof(bootcmdresp));
>  
>  		if (le16_to_cpu(cardp->udev->descriptor.bcdDevice) < 0x3106) {
>  			kfree_skb(skb);
> @@ -619,8 +617,7 @@ static void if_usb_receive_fwload(struct urb *urb)
>  		return;
>  	}
>  
> -	memcpy(syncfwheader, skb->data + IPFIELD_ALIGN_OFFSET,
> -	       sizeof(struct fwsyncheader));
> +	memcpy(syncfwheader, skb->data, sizeof(struct fwsyncheader));
>  
>  	if (!syncfwheader->cmd) {
>  		lbs_deb_usb2(&cardp->udev->dev, "FW received Blk with correct CRC\n");
> @@ -665,7 +662,6 @@ static inline void process_cmdtypedata(int recvlength, struct sk_buff *skb,
>  		return;
>  	}
>  
> -	skb_reserve(skb, IPFIELD_ALIGN_OFFSET);
>  	skb_put(skb, recvlength);
>  	skb_pull(skb, MESSAGE_HEADER_LEN);
>  
> @@ -719,7 +715,7 @@ static void if_usb_receive(struct urb *urb)
>  	int recvlength = urb->actual_length;
>  	uint8_t *recvbuff = NULL;
>  	uint32_t recvtype = 0;
> -	__le32 *pkt = (__le32 *)(skb->data + IPFIELD_ALIGN_OFFSET);
> +	__le32 *pkt = (__le32 *)skb->data;
>  	uint32_t event;
>  
>  	lbs_deb_enter(LBS_DEB_USB);
> @@ -732,7 +728,7 @@ static void if_usb_receive(struct urb *urb)
>  			goto setup_for_next;
>  		}
>  
> -		recvbuff = skb->data + IPFIELD_ALIGN_OFFSET;
> +		recvbuff = skb->data;
>  		recvtype = le32_to_cpu(pkt[0]);
>  		lbs_deb_usbd(&cardp->udev->dev,
>  			    "Recv length = 0x%x, Recv type = 0x%X\n",
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From dcbw at redhat.com  Tue Nov 10 02:04:25 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 09 Nov 2009 23:04:25 -0800
Subject: Libertas related kernel crash
In-Reply-To: <20091110065457.GL14091@buzzloop.caiaq.de>
References: <20091105120549.GQ14091@buzzloop.caiaq.de>
	<20091109155354.GC14091@buzzloop.caiaq.de>
	<1257835893.15493.37.camel@localhost.localdomain>
	<20091110065457.GL14091@buzzloop.caiaq.de>
Message-ID: <1257836665.19597.3.camel@localhost.localdomain>

On Tue, 2009-11-10 at 07:54 +0100, Daniel Mack wrote:
> On Mon, Nov 09, 2009 at 10:51:33PM -0800, Dan Williams wrote:
> > On Mon, 2009-11-09 at 16:53 +0100, Daniel Mack wrote:
> > > On Thu, Nov 05, 2009 at 01:05:49PM +0100, Daniel Mack wrote:
> > > > On an ARM (PXA300) embdedded platform with a libertas chip connected via
> > > > SDIO, we happen to see the kernel Ooops below once in a while.
> > > > 
> > > > Any pointer on where to dig?
> > > 
> > > Some more input on this. Oopses similar to the one below are likely
> > > triggered when switching from Ad-hoc to managed mode multiple times in a
> > > row, and something seems corrupt the memory badly. I've searched for the
> > > obvious (double frees, out-of-bound writes etc), but I couldn't find
> > > anything yet. It is, however, related to the wireless core and/or the
> > > libertas driver.
> > 
> > Probably just libertas.  Any chance you can enable debugging options
> > (either in libertas, or in the kernel allocator) to help narrow down the
> > issue?
> 
> Sure. I already enabled DEBUG_VM, but that didn't spit out anything
> before it crashes. Which other debug flags would you recommend to set?

Offhand I don't actually know; but ISTR there used to be slab debugging
options in the kernel that could help find memory corruption issues.  I
can't think of anything in libertas offhand that would trigger this, but
maybe something is not getting properly cleaned up when switching modes?

Dan




From jackylam.gsl at gmail.com  Fri Nov 13 00:12:05 2009
From: jackylam.gsl at gmail.com (Jacky Lam)
Date: Fri, 13 Nov 2009 13:12:05 +0800
Subject: Libertas driver performance on Samsung platform
Message-ID: <39811fe10911122112r61c03075o37b439d52bc32bc9@mail.gmail.com>

Dear all,

	I have read the previous mail about the low performance of Samsung
BSP's SDIO platform driver when working with Libertas. I want to know if
anyone have tried the kernel mainstream's Samsung driver and have any
improvement on that?

	Thanks.

BR,
Jacky


From dcbw at redhat.com  Fri Nov 13 21:06:08 2009
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 13 Nov 2009 18:06:08 -0800
Subject: Libertas driver performance on Samsung platform
In-Reply-To: <39811fe10911122112r61c03075o37b439d52bc32bc9@mail.gmail.com>
References: <39811fe10911122112r61c03075o37b439d52bc32bc9@mail.gmail.com>
Message-ID: <1258164368.20338.11.camel@localhost.localdomain>

On Fri, 2009-11-13 at 13:12 +0800, Jacky Lam wrote:
> Dear all,
> 
> 	I have read the previous mail about the low performance of Samsung
> BSP's SDIO platform driver when working with Libertas. I want to know if
> anyone have tried the kernel mainstream's Samsung driver and have any
> improvement on that?

Does the Samsung SDHC have quirks or limitations with respect to DMA,
block size, transfer width, etc?

Dan




From ramkumar.research at gmail.com  Sat Nov 14 14:53:27 2009
From: ramkumar.research at gmail.com (Ram kumar)
Date: Sun, 15 Nov 2009 01:23:27 +0530
Subject: Hi Surprise!!!!!!
Message-ID: <6306c640911141153m7034dd6asa552a602d7c0a878@mail.gmail.com>

http://allmiamimix.com/oWPL8ihBWP.html


From jackylam.gsl at gmail.com  Sun Nov 15 20:43:44 2009
From: jackylam.gsl at gmail.com (Jacky Lam)
Date: Mon, 16 Nov 2009 09:43:44 +0800
Subject: Libertas driver performance on Samsung platform
Message-ID: <39811fe10911151743n7e04a5e6nb30175cb1caf3015@mail.gmail.com>

Dan Williams ??:
> On Fri, 2009-11-13 at 13:12 +0800, Jacky Lam wrote:
>> Dear all,
>>
>> 	I have read the previous mail about the low performance of Samsung
>> BSP's SDIO platform driver when working with Libertas. I want to know if
>> anyone have tried the kernel mainstream's Samsung driver and have any
>> improvement on that?
>
> Does the Samsung SDHC have quirks or limitations with respect to DMA,
> block size, transfer width, etc?
>
> Dan
>
>
>
>
Dear Dan,

	I look through the source code and can't find any "special" limitation
for the DMA, block size, transfer width.....Maybe I am not familiar
enough with Linux MMC stack. Could you tell me if there is any
requirement for the MMC stack on the host's DMA, block size, transfer
width..etc? So, I can pinpoint my investigation?

	Thanks a lot.

BR,
Jacky


From dcbw at redhat.com  Mon Nov 16 01:32:04 2009
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 15 Nov 2009 22:32:04 -0800
Subject: Libertas driver performance on Samsung platform
In-Reply-To: <39811fe10911151743n7e04a5e6nb30175cb1caf3015@mail.gmail.com>
References: <39811fe10911151743n7e04a5e6nb30175cb1caf3015@mail.gmail.com>
Message-ID: <1258353124.22827.5.camel@localhost.localdomain>

On Mon, 2009-11-16 at 09:43 +0800, Jacky Lam wrote:
> Dan Williams ??:
> > On Fri, 2009-11-13 at 13:12 +0800, Jacky Lam wrote:
> >> Dear all,
> >>
> >> 	I have read the previous mail about the low performance of Samsung
> >> BSP's SDIO platform driver when working with Libertas. I want to know if
> >> anyone have tried the kernel mainstream's Samsung driver and have any
> >> improvement on that?
> >
> > Does the Samsung SDHC have quirks or limitations with respect to DMA,
> > block size, transfer width, etc?
> >
> > Dan
> >
> >
> >
> >
> Dear Dan,
> 
> 	I look through the source code and can't find any "special" limitation
> for the DMA, block size, transfer width.....Maybe I am not familiar
> enough with Linux MMC stack. Could you tell me if there is any
> requirement for the MMC stack on the host's DMA, block size, transfer
> width..etc? So, I can pinpoint my investigation?

There's no requirement in the stack, but the libertas driver and
firmware expect multi-block transfer ability and interrupt support.  The
libertas firmware will fail to load if if the host controller doesn't
support multi-block, which we just found to be a limitation of one of
the i.MX platform for example.

Dan




From jackylam.gsl at gmail.com  Mon Nov 16 01:43:38 2009
From: jackylam.gsl at gmail.com (Jacky Lam)
Date: Mon, 16 Nov 2009 14:43:38 +0800
Subject: Libertas driver performance on Samsung platform
Message-ID: <39811fe10911152243y127e9c87meaeeed767bb6059e@mail.gmail.com>

Dear Dan,

	I just talk to tommy and find that the problem really happened in the
interrupt support as you said. Thanks for all advice from you.

BR,
Jacky

Dan Williams ??:
> On Mon, 2009-11-16 at 09:43 +0800, Jacky Lam wrote:
>> Dan Williams ??:
>>> On Fri, 2009-11-13 at 13:12 +0800, Jacky Lam wrote:
>>>> Dear all,
>>>>
>>>> 	I have read the previous mail about the low performance of Samsung
>>>> BSP's SDIO platform driver when working with Libertas. I want to know if
>>>> anyone have tried the kernel mainstream's Samsung driver and have any
>>>> improvement on that?
>>> Does the Samsung SDHC have quirks or limitations with respect to DMA,
>>> block size, transfer width, etc?
>>>
>>> Dan
>>>
>>>
>>>
>>>
>> Dear Dan,
>>
>> 	I look through the source code and can't find any "special" limitation
>> for the DMA, block size, transfer width.....Maybe I am not familiar
>> enough with Linux MMC stack. Could you tell me if there is any
>> requirement for the MMC stack on the host's DMA, block size, transfer
>> width..etc? So, I can pinpoint my investigation?
>
> There's no requirement in the stack, but the libertas driver and
> firmware expect multi-block transfer ability and interrupt support.  The
> libertas firmware will fail to load if if the host controller doesn't
> support multi-block, which we just found to be a limitation of one of
> the i.MX platform for example.
>
> Dan
>
>
>
>


From rulxe at camaq.com.br  Tue Nov 17 01:57:59 2009
From: rulxe at camaq.com.br (Irving T Mcintyre)
Date: 17 Nov 2009 07:57:59 +0100
Subject: Why pay thousands for a marketing list
Message-ID: <SERVERLrXWq0GPlrwAn000014f3@olymp-klatovy.cz>




Here is a catalog of US contact lists we have for sale:

+Physicians
+Chiropractors
+Alternative Medicine
+Dentists
+Veterinarians
+Hospitals
+Nursing Homes
+Pharmaceutical Companies
+Physical Therapists
+Acupuncturists
+Massage Therapists
+Medical Equipment Suppliers
+Mental Health Counselors
+Visiting Nurses & RN's
+Optometrists
+Psychologists

The lists have many different fields including phone, fax, postal address, email and much more. This week you can buy any 4 of the above lists for just $349.
Please contact me here: Robert at bestmarketlists.be. (please include this email when responding)
























To stop receiving this email correspondence please send an email to rembox at bestmarketlists.be



From dcbw at redhat.com  Sun Nov 22 17:46:51 2009
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 22 Nov 2009 14:46:51 -0800
Subject: Libertas driver performance on Samsung platform
In-Reply-To: <4B0825BE.7030904@gmail.com>
References: <39811fe10911152243y127e9c87meaeeed767bb6059e@mail.gmail.com>
	<4B0825BE.7030904@gmail.com>
Message-ID: <1258930011.12095.18.camel@localhost.localdomain>

On Sat, 2009-11-21 at 09:39 -0800, Ravi Mahadevappa wrote:
> Hi Dan, Jacky,
> 
> We are facing the same problem. Could you please elaborate a bit on
> this issue. 
> What is the firmware version and the driver version I should use? 

Latest driver from 2.6.31, which should also be pretty trivial to
backport to older kernels as well, since it doesn't change too much.
Either firmware v9 or firmware v8 can be used.  There is firmware
available here:

http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=libertas;h=c9d61b10b750ccbfb8a6f26d8a762f4ca95df0e7;hb=HEAD

please use git to clone that repository to grab the firmware, since
trying to download the blob from gitweb over HTTP itself will likely
mess up the file.

> Where do I look to verify that the interrupt support is enabled?

In your SD host controller code.  You can also enable MMC/SD stack
debugging in your kernel config and get a lot more output about what's
going on.

Dan

> 
> Thanks,
> Ravi
> 
> On 11/15/2009 10:43 PM, Jacky Lam wrote: 
> > Dear Dan,
> > 
> > 	I just talk to tommy and find that the problem really happened in the
> > interrupt support as you said. Thanks for all advice from you.
> > 
> > BR,
> > Jacky
> > 
> > Dan Williams ??:
> >   
> > > On Mon, 2009-11-16 at 09:43 +0800, Jacky Lam wrote:
> > >     
> > > > Dan Williams ??:
> > > >       
> > > > > On Fri, 2009-11-13 at 13:12 +0800, Jacky Lam wrote:
> > > > >         
> > > > > > Dear all,
> > > > > > 
> > > > > > 	I have read the previous mail about the low performance of Samsung
> > > > > > BSP's SDIO platform driver when working with Libertas. I want to know if
> > > > > > anyone have tried the kernel mainstream's Samsung driver and have any
> > > > > > improvement on that?
> > > > > >           
> > > > > Does the Samsung SDHC have quirks or limitations with respect to DMA,
> > > > > block size, transfer width, etc?
> > > > > 
> > > > > Dan
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >         
> > > > Dear Dan,
> > > > 
> > > > 	I look through the source code and can't find any "special" limitation
> > > > for the DMA, block size, transfer width.....Maybe I am not familiar
> > > > enough with Linux MMC stack. Could you tell me if there is any
> > > > requirement for the MMC stack on the host's DMA, block size, transfer
> > > > width..etc? So, I can pinpoint my investigation?
> > > >       
> > > There's no requirement in the stack, but the libertas driver and
> > > firmware expect multi-block transfer ability and interrupt support.  The
> > > libertas firmware will fail to load if if the host controller doesn't
> > > support multi-block, which we just found to be a limitation of one of
> > > the i.MX platform for example.
> > > 
> > > Dan
> > > 
> > > 
> > > 
> > > 
> > >     
> > 
> > _______________________________________________
> > libertas-dev mailing list
> > libertas-dev at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/libertas-dev
> >   



From hmravi at gmail.com  Sun Nov 22 18:25:07 2009
From: hmravi at gmail.com (Ravi Mahadevappa)
Date: Sun, 22 Nov 2009 15:25:07 -0800
Subject: Libertas driver performance on Samsung platform
In-Reply-To: <1258930011.12095.18.camel@localhost.localdomain>
References: <39811fe10911152243y127e9c87meaeeed767bb6059e@mail.gmail.com>
	<4B0825BE.7030904@gmail.com>
	<1258930011.12095.18.camel@localhost.localdomain>
Message-ID: <30fdd8d80911221525j1db82bb8m50740801eb8758a7@mail.gmail.com>

Hi Dan,

Thanks for the response. I have attached debug logs from enabling mmc
debug and libertas debug separately after initiating a tftp command.
Could you please take a quick look to see if there is any obvious
issues. I'd greatly appreciate it. To me it looks like the interrupt
is enabled and multi-block transfer is also enabled. I am using a
2.6.28 driver with 9.70.7 firmware.

Best Regards,
Ravi

On Sun, Nov 22, 2009 at 2:46 PM, Dan Williams <dcbw at redhat.com> wrote:
> On Sat, 2009-11-21 at 09:39 -0800, Ravi Mahadevappa wrote:
>> Hi Dan, Jacky,
>>
>> We are facing the same problem. Could you please elaborate a bit on
>> this issue.
>> What is the firmware version and the driver version I should use?
>
> Latest driver from 2.6.31, which should also be pretty trivial to
> backport to older kernels as well, since it doesn't change too much.
> Either firmware v9 or firmware v8 can be used. ?There is firmware
> available here:
>
> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=libertas;h=c9d61b10b750ccbfb8a6f26d8a762f4ca95df0e7;hb=HEAD
>
> please use git to clone that repository to grab the firmware, since
> trying to download the blob from gitweb over HTTP itself will likely
> mess up the file.
>
>> Where do I look to verify that the interrupt support is enabled?
>
> In your SD host controller code. ?You can also enable MMC/SD stack
> debugging in your kernel config and get a lot more output about what's
> going on.
>
> Dan
>
>>
>> Thanks,
>> Ravi
>>
>> On 11/15/2009 10:43 PM, Jacky Lam wrote:
>> > Dear Dan,
>> >
>> > ? ? I just talk to tommy and find that the problem really happened in the
>> > interrupt support as you said. Thanks for all advice from you.
>> >
>> > BR,
>> > Jacky
>> >
>> > Dan Williams ??:
>> >
>> > > On Mon, 2009-11-16 at 09:43 +0800, Jacky Lam wrote:
>> > >
>> > > > Dan Williams ??:
>> > > >
>> > > > > On Fri, 2009-11-13 at 13:12 +0800, Jacky Lam wrote:
>> > > > >
>> > > > > > Dear all,
>> > > > > >
>> > > > > > ? ? I have read the previous mail about the low performance of Samsung
>> > > > > > BSP's SDIO platform driver when working with Libertas. I want to know if
>> > > > > > anyone have tried the kernel mainstream's Samsung driver and have any
>> > > > > > improvement on that?
>> > > > > >
>> > > > > Does the Samsung SDHC have quirks or limitations with respect to DMA,
>> > > > > block size, transfer width, etc?
>> > > > >
>> > > > > Dan
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > Dear Dan,
>> > > >
>> > > > ? ? ? ? I look through the source code and can't find any "special" limitation
>> > > > for the DMA, block size, transfer width.....Maybe I am not familiar
>> > > > enough with Linux MMC stack. Could you tell me if there is any
>> > > > requirement for the MMC stack on the host's DMA, block size, transfer
>> > > > width..etc? So, I can pinpoint my investigation?
>> > > >
>> > > There's no requirement in the stack, but the libertas driver and
>> > > firmware expect multi-block transfer ability and interrupt support. ?The
>> > > libertas firmware will fail to load if if the host controller doesn't
>> > > support multi-block, which we just found to be a limitation of one of
>> > > the i.MX platform for example.
>> > >
>> > > Dan
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> > _______________________________________________
>> > libertas-dev mailing list
>> > libertas-dev at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/libertas-dev
>> >
>
>
-------------- next part --------------
tftp -g -r ftp_test_13MB 192.168.1.68


libertas enter: if_sdio_interrupt()
libertas sdio: interrupt: 0x1
libertas enter: if_sdio_card_to_host()
libertas sdio: packet of type 0 and size 74 bytes
libertas enter: if_sdio_handle_data()
libertas enter: lbs_process_rxed_packet()
libertas RX Data: Before chop rxpd: 01 00 1f 00 32 00 60 00 14 00 00 00 00 00 00 00 
libertas RX Data: Before chop rxpd: 00 00 00 00 ff ff ff ff ff ff 00 24 56 8a d4 99 
libertas RX Data: Before chop rxpd: 00 24 aa aa 03 00 00 00 08 06 00 01 08 00 06 04 
libertas RX Data: Before chop rxpd: 00 01 00 24 56 8a d4 99 c0 a8 01 fe ff ff ff ff 
libertas RX Data: Before chop rxpd: ff ff c0 a8 01 42 
libertas rx: rx data: skb->len-sizeof(RxPd) = 70-20 = 50
libertas RX Data: Dest: ff ff ff ff ff ff 
libertas RX Data: Src: 00 24 56 8a d4 99 
libertas enter: lbs_compute_rssi()
libertas rx: rxpd: SNR 31, NF 96
libertas rx: before computing SNR: SNR-avg = 31, NF-avg = 95
libertas rx: after computing SNR: SNR-avg = 31, NF-avg = 95
libertas leave: lbs_compute_rssi()
libertas rx: rx data: size of actual packet 42
libertas leave: lbs_process_rxed_packet(), ret 0
libertas leave: if_sdio_handle_data(), ret 0
libertas leave: if_sdio_card_to_host(), ret 0
libertas leave: if_sdio_interrupt(), ret 0

ARP transmitted
libertas enter (INT): lbs_hard_start_xmit()
libertas TX Data: ff ff ff ff ff ff 00 23 06 56 03 ef 08 06 00 01 
libertas TX Data: 08 00 06 04 00 01 00 23 06 56 03 ef c0 a8 01 14 
libertas TX Data: 00 00 00 00 00 00 c0 a8 01 44 
libertas txpd: 90 45 47 c7 dc f9 5b c7 00 8d 3f c7 c0 59 5f c7 
libertas txpd: 00 29 01 c7 00 40 47 c7 
libertas Tx Data: ff ff ff ff ff ff 00 23 06 56 03 ef 08 06 00 01 
libertas Tx Data: 08 00 06 04 00 01 00 23 06 56 03 ef c0 a8 01 14 
libertas Tx Data: 00 00 00 00 00 00 c0 a8 01 44 
libertas tx (INT): lbs_hard_start_xmit lined up packet
libertas leave (INT): lbs_hard_start_xmit(), ret 0

libertas thread: 2: currenttxskb 00000000, dnld_send 0
libertas thread: 3: currenttxskb 00000000, dnld_sent 0
libertas thread: 4: currenttxskb 00000000, dnld_sent 0
libertas enter: lbs_execute_next_command()
libertas leave: lbs_execute_next_command()
libertas enter: if_sdio_host_to_card(type 0, bytes 66)
libertas leave: if_sdio_host_to_card(), ret 0
libertas thread: 1: currenttxskb 00000000, dnld_sent 1
libertas thread: sleeping, connect_status 0, psmode 0, psstate 0
libertas enter: if_sdio_host_to_card_worker()
libertas leave: if_sdio_host_to_card_worker()

ARP reply
libertas enter: if_sdio_interrupt()
libertas sdio: interrupt: 0x3
libertas enter: lbs_host_to_card_done()
libertas leave: lbs_host_to_card_done()
libertas enter: if_sdio_card_to_host()
libertas sdio: packet of type 0 and size 74 bytes
libertas enter: if_sdio_handle_data()
libertas enter: lbs_process_rxed_packet()
libertas RX Data: Before chop rxpd: 01 00 20 00 32 00 60 0b 14 00 00 00 00 00 00 00 
libertas RX Data: Before chop rxpd: 00 00 00 00 00 23 06 56 03 ef 00 21 00 df 72 2d 
libertas RX Data: Before chop rxpd: 00 24 aa aa 03 00 00 00 08 06 00 01 08 00 06 04 
libertas RX Data: Before chop rxpd: 00 02 00 21 00 df 72 2d c0 a8 01 44 00 23 06 56 
libertas RX Data: Before chop rxpd: 03 ef c0 a8 01 14 
libertas rx: rx data: skb->len-sizeof(RxPd) = 70-20 = 50
libertas RX Data: Dest: 00 23 06 56 03 ef 
libertas RX Data: Src: 00 21 00 df 72 2d 
libertas enter: lbs_compute_rssi()
libertas rx: rxpd: SNR 32, NF 96
libertas rx: before computing SNR: SNR-avg = 31, NF-avg = 95
libertas rx: after computing SNR: SNR-avg = 31, NF-avg = 95
libertas leave: lbs_compute_rssi()
libertas rx: rx data: size of actual packet 42

Read request, File: ftp_test_13MB, TFTP 
libertas enter (INT): lbs_hard_start_xmit()
libertas TX Data: 00 21 00 df 72 2d 00 23 06 56 03 ef 08 00 45 00 
libertas TX Data: 00 32 00 00 40 00 40 11 b7 12 c0 a8 01 14 c0 a8 
libertas TX Data: 01 44 c9 da 00 45 00 1e c6 f2 00 01 66 74 70 5f 
libertas TX Data: 74 65 73 74 5f 31 33 4d 42 00 6f 63 74 65 74 00 
libertas txpd: 90 45 47 c7 68 4b 42 c0 00 8d 3f c7 80 54 5f c7 
libertas txpd: 00 29 01 c7 00 40 47 c7 
libertas Tx Data: 00 21 00 df 72 2d 00 23 06 56 03 ef 08 00 45 00 
libertas Tx Data: 00 32 00 00 40 00 40 11 b7 12 c0 a8 01 14 c0 a8 
libertas Tx Data: 01 44 c9 da 00 45 00 1e c6 f2 00 01 66 74 70 5f 
libertas Tx Data: 74 65 73 74 5f 31 33 4d 42 00 6f 63 74 65 74 00 
libertas tx (INT): lbs_hard_start_xmit lined up packet
libertas leave (INT): lbs_hard_start_xmit(), ret 0

libertas leave: lbs_process_rxed_packet(), ret 0
libertas leave: if_sdio_handle_data(), ret 0
libertas leave: if_sdio_card_to_host(), ret 0
libertas leave: if_sdio_interrupt(), ret 0

libertas thread: 2: currenttxskb 00000000, dnld_send 0
libertas thread: 3: currenttxskb 00000000, dnld_sent 0
libertas thread: 4: currenttxskb 00000000, dnld_sent 0
libertas enter: lbs_execute_next_command()
libertas leave: lbs_execute_next_command()
libertas enter: if_sdio_host_to_card(type 0, bytes 88)
libertas leave: if_sdio_host_to_card(), ret 0
libertas thread: 1: currenttxskb 00000000, dnld_sent 1
libertas thread: sleeping, connect_status 0, psmode 0, psstate 0
libertas enter: if_sdio_host_to_card_worker()
libertas leave: if_sdio_host_to_card_worker()
libertas enter: if_sdio_interrupt()
libertas sdio: interrupt: 0x2
libertas enter: lbs_host_to_card_done()
libertas leave: lbs_host_to_card_done()
libertas leave: if_sdio_interrupt(), ret 0
libertas enter: if_sdio_interrupt()
libertas sdio: interrupt: 0x1
libertas enter: if_sdio_card_to_host()
libertas sdio: packet of type 0 and size 590 bytes
libertas enter: if_sdio_handle_data()
libertas enter: lbs_process_rxed_packet()
libertas RX Data: Before chop rxpd: 01 00 1e 00 36 02 60 0c 14 00 00 00 00 00 00 00 
libertas RX Data: Before chop rxpd: 00 00 00 00 00 23 06 56 03 ef 00 21 00 df 72 2d 
libertas RX Data: Before chop rxpd: 02 28 aa aa 03 00 00 00 08 00 45 00 02 20 e2 f7 
libertas RX Data: Before chop rxpd: 00 00 40 11 12 2d c0 a8 01 44 c0 a8 01 14 9d 7c 
libertas RX Data: Before chop rxpd: c9 da 02 0c 7d 47 00 03 00 01 25 50 44 46 2d 31 
libertas RX Data: Before chop rxpd: 2e 36 0d 25 e2 e3 cf d3 0d 0a 31 33 35 34 31 20 
libertas RX Data: Before chop rxpd: 30 20 6f 62 
libertas rx: rx data: skb->len-sizeof(RxPd) = 586-20 = 566
libertas RX Data: Dest: 00 23 06 56 03 ef 
libertas RX Data: Src: 00 21 00 df 72 2d 
libertas enter: lbs_compute_rssi()
libertas rx: rxpd: SNR 30, NF 96
libertas rx: before computing SNR: SNR-avg = 31, NF-avg = 95
libertas rx: after computing SNR: SNR-avg = 31, NF-avg = 95
libertas leave: lbs_compute_rssi()
libertas rx: rx data: size of actual packet 558
libertas leave: lbs_process_rxed_packet(), ret 0
libertas leave: if_sdio_handle_data(), ret 0
libertas leave: if_sdio_card_to_host(), ret 0
libertas leave: if_sdio_interrupt(), ret 0
libertas thread: 2: currenttxskb 00000000, dnld_send 0
libertas thread: 3: currenttxskb 00000000, dnld_sent 0
libertas thread: 4: currenttxskb 00000000, dnld_sent 0
libertas enter: lbs_execute_next_command()
libertas leave: lbs_execute_next_command()
libertas thread: 1: currenttxskb 00000000, dnld_sent 0
libertas thread: sleeping, connect_status 0, psmode 0, psstate 0

libertas enter (INT): lbs_hard_start_xmit()
libertas TX Data: 00 21 00 df 72 2d 00 23 06 56 03 ef 08 00 45 00 
libertas TX Data: 00 20 00 00 40 00 40 11 b7 24 c0 a8 01 14 c0 a8 
libertas TX Data: 01 44 c9 da 9d 7c 00 0c 14 d1 00 04 00 01 
libertas txpd: 90 45 47 c7 01 00 00 00 00 8d 3f c7 c0 50 5f c7 
libertas txpd: 00 29 01 c7 00 40 47 c7 
libertas Tx Data: 00 21 00 df 72 2d 00 23 06 56 03 ef 08 00 45 00 
libertas Tx Data: 00 20 00 00 40 00 40 11 b7 24 c0 a8 01 14 c0 a8 
libertas Tx Data: 01 44 c9 da 9d 7c 00 0c 14 d1 00 04 00 01 
libertas tx (INT): lbs_hard_start_xmit lined up packet
libertas leave (INT): lbs_hard_start_xmit(), ret 0
libertas thread: 2: currenttxskb 00000000, dnld_send 0
libertas thread: 3: currenttxskb 00000000, dnld_sent 0
libertas thread: 4: currenttxskb 00000000, dnld_sent 0
libertas enter: lbs_execute_next_command()
libertas leave: lbs_execute_next_command()
libertas enter: if_sdio_host_to_card(type 0, bytes 70)
libertas leave: if_sdio_host_to_card(), ret 0
libertas thread: 1: currenttxskb 00000000, dnld_sent 1
libertas thread: sleeping, connect_status 0, psmode 0, psstate 0
libertas enter: if_sdio_host_to_card_worker()
libertas leave: if_sdio_host_to_card_worker()
libertas enter: if_sdio_interrupt()
libertas sdio: interrupt: 0x2
libertas enter: lbs_host_to_card_done()
libertas leave: lbs_host_to_card_done()
libertas leave: if_sdio_interrupt(), ret 0
libertas enter: if_sdio_interrupt()
libertas sdio: interrupt: 0x1
libertas enter: if_sdio_card_to_host()
libertas sdio: packet of type 0 and size 590 bytes
libertas enter: if_sdio_handle_data()
libertas enter: lbs_process_rxed_packet()
libertas RX Data: Before chop rxpd: 01 00 1f 00 36 02 60 0c 14 00 00 00 00 00 00 00 
libertas RX Data: Before chop rxpd: 00 00 00 00 00 23 06 56 03 ef 00 21 00 df 72 2d 
libertas RX Data: Before chop rxpd: 02 28 aa aa 03 00 00 00 08 00 45 00 02 20 e2 f8 
libertas RX Data: Before chop rxpd: 00 00 40 11 12 2c c0 a8 01 44 c0 a8 01 14 9d 7c 
libertas RX Data: Before chop rxpd: c9 da 02 0c a2 7c 00 03 00 02 61 78 2d 6e 73 23 
libertas RX Data: Before chop rxpd: 22 3e 0a 20 20 20 20 20 20 3c 72 64 66 3a 44 65 
libertas RX Data: Before chop rxpd: 73 63 72 69 
libertas rx: rx data: skb->len-sizeof(RxPd) = 586-20 = 566
libertas RX Data: Dest: 00 23 06 56 03 ef 
libertas RX Data: Src: 00 21 00 df 72 2d 
libertas enter: lbs_compute_rssi()
libertas rx: rxpd: SNR 31, NF 96
libertas rx: before computing SNR: SNR-avg = 31, NF-avg = 95
libertas rx: after computing SNR: SNR-avg = 30, NF-avg = 95
libertas leave: lbs_compute_rssi()
libertas rx: rx data: size of actual packet 558
libertas leave: lbs_process_rxed_packet(), ret 0
libertas leave: if_sdio_handle_data(), ret 0
libertas leave: if_sdio_card_to_host(), ret 0
libertas leave: if_sdio_interrupt(), ret 0
libertas thread: 2: currenttxskb 00000000, dnld_send 0
libertas thread: 3: currenttxskb 00000000, dnld_sent 0
libertas thread: 4: currenttxskb 00000000, dnld_sent 0
libertas enter: lbs_execute_next_command()
libertas leave: lbs_execute_next_command()
libertas thread: 1: currenttxskb 00000000, dnld_sent 0
libertas thread: sleeping, connect_status 0, psmode 0, psstate 0
libertas enter (INT): lbs_hard_start_xmit()
libertas TX Data: 00 21 00 df 72 2d 00 23 06 56 03 ef 08 00 45 00 
libertas TX Data: 00 20 00 00 40 00 40 11 b7 24 c0 a8 01 14 c0 a8 
libertas TX Data: 01 44 c9 da 9d 7c 00 0c 14 d0 00 04 00 02 
libertas txpd: 90 45 47 c7 01 00 00 00 00 8d 3f c7 00 50 5f c7 
libertas txpd: 00 29 01 c7 00 40 47 c7 
libertas Tx Data: 00 21 00 df 72 2d 00 23 06 56 03 ef 08 00 45 00 
libertas Tx Data: 00 20 00 00 40 00 40 11 b7 24 c0 a8 01 14 c0 a8 
libertas Tx Data: 01 44 c9 da 9d 7c 00 0c 14 d0 00 04 00 02 
libertas tx (INT): lbs_hard_start_xmit lined up packet
libertas leave (INT): lbs_hard_start_xmit(), ret 0
libertas enter: if_sdio_interrupt()
libertas sdio: interrupt: 0x1
libertas enter: if_sdio_card_to_host()
libertas sdio: packet of type 0 and size 74 bytes
libertas enter: if_sdio_handle_data()
libertas enter: lbs_process_rxed_packet()
libertas RX Data: Before chop rxpd: 01 00 1e 00 32 00 5f 00 14 00 00 00 00 00 00 00 
libertas RX Data: Before chop rxpd: 00 00 00 00 ff ff ff ff ff ff 00 24 56 8a d4 99 
libertas RX Data: Before chop rxpd: 00 24 aa aa 03 00 00 00 08 06 00 01 08 00 06 04 
libertas RX Data: Before chop rxpd: 00 01 00 24 56 8a d4 99 c0 a8 01 fe ff ff ff ff 
libertas RX Data: Before chop rxpd: ff ff c0 a8 01 43 
libertas rx: rx data: skb->len-sizeof(RxPd) = 70-20 = 50
libertas RX Data: Dest: ff ff ff ff ff ff 
libertas RX Data: Src: 00 24 56 8a d4 99 
libertas enter: lbs_compute_rssi()
libertas rx: rxpd: SNR 30, NF 95
libertas rx: before computing SNR: SNR-avg = 30, NF-avg = 95
libertas rx: after computing SNR: SNR-avg = 30, NF-avg = 95
libertas leave: lbs_compute_rssi()
libertas rx: rx data: size of actual packet 42
libertas leave: lbs_process_rxed_packet(), ret 0
libertas leave: if_sdio_handle_data(), ret 0
libertas leave: if_sdio_card_to_host(), ret 0
libertas leave: if_sdio_interrupt(), ret 0
libertas thread: 2: currenttxskb 00000000, dnld_send 0
libertas thread: 3: currenttxskb 00000000, dnld_sent 0
libertas thread: 4: currenttxskb 00000000, dnld_sent 0
libertas enter: lbs_execute_next_command()
libertas leave: lbs_execute_next_command()
libertas enter: if_sdio_host_to_card(type 0, bytes 70)
libertas leave: if_sdio_host_to_card(), ret 0
libertas thread: 1: currenttxskb 00000000, dnld_sent 1
libertas thread: sleeping, connect_status 0, psmode 0, psstate 0
libertas enter: if_sdio_host_to_card_worker()
libertas leave: if_sdio_host_to_card_worker()
libertas enter: if_sdio_interrupt()
libertas sdio: interrupt: 0x2
libertas enter: lbs_host_to_card_done()
libertas leave: lbs_host_to_card_done()
libertas leave: if_sdio_interrupt(), ret 0
libertas enter: if_sdio_interrupt()
libertas sdio: interrupt: 0x1
libertas enter: if_sdio_card_to_host()
libertas sdio: packet of type 0 and size 590 bytes
libertas enter: if_sdio_handle_data()
libertas enter: lbs_process_rxed_packet()
libertas RX Data: Before chop rxpd: 01 00 1e 00 36 02 5f 0c 14 00 00 00 00 00 00 00 
libertas RX Data: Before chop rxpd: 00 00 00 00 00 23 06 56 03 ef 00 21 00 df 72 2d 
libertas RX Data: Before chop rxpd: 02 28 aa aa 03 00 00 00 08 00 45 00 02 20 e2 f9 
libertas RX Data: Before chop rxpd: 00 00 40 11 12 2b c0 a8 01 44 c0 a8 01 14 9d 7c 
libertas RX Data: Before chop rxpd: c9 da 02 0c bf 38 00 03 00 03 63 3a 66 6f 72 6d 
libertas RX Data: Before chop rxpd: 61 74 3e 61 70 70 6c 69 63 61 74 69 6f 6e 2f 70 
libertas RX Data: Before chop rxpd: 64 66 3c 2f 
libertas rx: rx data: skb->len-sizeof(RxPd) = 586-20 = 566
libertas RX Data: Dest: 00 23 06 56 03 ef 
libertas RX Data: Src: 00 21 00 df 72 2d 
libertas enter: lbs_compute_rssi()
libertas rx: rxpd: SNR 30, NF 95
libertas rx: before computing SNR: SNR-avg = 30, NF-avg = 95
libertas rx: after computing SNR: SNR-avg = 30, NF-avg = 95
libertas leave: lbs_compute_rssi()
libertas rx: rx data: size of actual packet 558
libertas leave: lbs_process_rxed_packet(), ret 0
libertas leave: if_sdio_handle_data(), ret 0
libertas leave: if_sdio_card_to_host(), ret 0
libertas leave: if_sdio_interrupt(), ret 0
libertas thread: 2: currenttxskb 00000000, dnld_send 0
libertas thread: 3: currenttxskb 00000000, dnld_sent 0
libertas thread: 4: currenttxskb 00000000, dnld_sent 0
libertas enter: lbs_execute_next_command()
libertas leave: lbs_execute_next_command()
libertas thread: 1: currenttxskb 00000000, dnld_sent 0
libertas thread: sleeping, connect_status 0, psmode 0, psstate 0
libertas enter (INT): lbs_hard_start_xmit()
libertas TX Data: 00 21 00 df 72 2d 00 23 06 56 03 ef 08 00 45 00 
libertas TX Data: 00 20 00 00 40 00 40 11 b7 24 c0 a8 01 14 c0 a8 
libertas TX Data: 01 44 c9 da 9d 7c 00 0c 14 cf 00 04 00 03 
libertas txpd: 90 45 47 c7 01 00 00 00 00 8d 3f c7 40 5b 5f c7 
libertas txpd: 00 29 01 c7 00 40 47 c7 
libertas Tx Data: 00 21 00 df 72 2d 00 23 06 56 03 ef 08 00 45 00 
libertas Tx Data: 00 20 00 00 40 00 40 11 b7 24 c0 a8 01 14 c0 a8 
libertas Tx Data: 01 44 c9 da 9d 7c 00 0c 14 cf 00 04 00 03 
libertas tx (INT): lbs_hard_start_xmit lined up packet
libertas leave (INT): lbs_hard_start_xmit(), ret 0
libertas thread: 2: currenttxskb 00000000, dnld_send 0
libertas thread: 3: currenttxskb 00000000, dnld_sent 0
libertas thread: 4: currenttxskb 00000000, dnld_sent 0
libertas enter: lbs_execute_next_command()
libertas leave: lbs_execute_next_command()
libertas enter: if_sdio_host_to_card(type 0, bytes 70)
libertas leave: if_sdio_host_to_card(), ret 0
libertas thread: 1: currenttxskb 00000000, dnld_sent 1
libertas thread: sleeping, connect_status 0, psmode 0, psstate 0
libertas enter: if_sdio_host_to_card_worker()
libertas leave: if_sdio_host_to_card_worker()
libertas enter: if_sdio_interrupt()
libertas sdio: interrupt: 0x2
libertas enter: lbs_host_to_card_done()
libertas leave: lbs_host_to_card_done()
libertas leave: if_sdio_interrupt(), ret 0
libertas enter: if_sdio_interrupt()
libertas sdio: interrupt: 0x1
libertas enter: if_sdio_card_to_host()
libertas sdio: packet of type 0 and size 590 bytes
libertas enter: if_sdio_handle_data()
libertas enter: lbs_process_rxed_packet()
libertas RX Data: Before chop rxpd: 01 00 1d 00 36 02 5f 0c 14 00 00 00 00 00 00 00 
libertas RX Data: Before chop rxpd: 00 00 00 00 00 23 06 56 03 ef 00 21 00 df 72 2d 
libertas RX Data: Before chop rxpd: 02 28 aa aa 03 00 00 00 08 00 45 00 02 20 e2 fa 
libertas RX Data: Before chop rxpd: 00 00 40 11 12 2a c0 a8 01 44 c0 a8 01 14 9d 7c 
libertas RX Data: Before chop rxpd: c9 da 02 0c bb ab 00 03 00 04 72 64 66 3a 44 65 
libertas RX Data: Before chop rxpd: 73 63 72 69 70 74 69 6f 6e 3e 0a 20 20 20 3c 2f 
libertas RX Data: Before chop rxpd: 72 64 66 3a 
libertas rx: rx data: skb->len-sizeof(RxPd) = 586-20 = 566
libertas RX Data: Dest: 00 23 06 56 03 ef 
libertas RX Data: Src: 00 21 00 df 72 2d 
libertas enter: lbs_compute_rssi()
libertas rx: rxpd: SNR 29, NF 95
libertas rx: before computing SNR: SNR-avg = 30, NF-avg = 95
libertas rx: after computing SNR: SNR-avg = 30, NF-avg = 95
libertas leave: lbs_compute_rssi()
libertas rx: rx data: size of actual packet 558
libertas leave: lbs_process_rxed_packet(), ret 0
libertas leave: if_sdio_handle_data(), ret 0
libertas leave: if_sdio_card_to_host(), ret 0
libertas leave: if_sdio_interrupt(), ret 0
libertas thread: 2: currenttxskb 00000000, dnld_send 0
libertas thread: 3: currenttxskb 00000000, dnld_sent 0
libertas thread: 4: currenttxskb 00000000, dnld_sent 0
libertas enter: lbs_execute_next_command()
libertas leave: lbs_execute_next_command()
libertas thread: 1: currenttxskb 00000000, dnld_sent 0
libertas thread: sleeping, connect_status 0, psmode 0, psstate 0
libertas enter (INT): lbs_hard_start_xmit()
-------------- next part --------------
tftp -g -r ftp_test_13MB 192.168.1.68
mmc0: starting CMD52 arg 10004000 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
mmc0: req done (CMD52): 0: 00001008 00000000 00000000 00000000
mmc0: starting CMD53 arg 92000048 flags 000001b5
mmc0:     blksz 72 blocks 1 flags 00000100 tsac 1000 ms nsac 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000003
mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc0:     72 bytes transferred: 0
mmc0: starting CMD52 arg 00000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
mmc0: starting CMD52 arg 10000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001003 00000000 00000000 00000000
mmc0: starting CMD52 arg 90000afc flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 000010fc 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006800 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 0000104a 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001000 00000000 00000000 00000000
mmc0: starting CMD52 arg 10004000 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 0000100a 00000000 00000000 00000000
mmc0: starting CMD53 arg 1200004c flags 000001b5
mmc0:     blksz 76 blocks 1 flags 00000200 tsac 1000 ms nsac 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000103
mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc0:     76 bytes transferred: 0
mmc0: starting CMD52 arg 10004000 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
mmc0: req done (CMD52): 0: 00001008 00000000 00000000 00000000
mmc0: starting CMD53 arg 9200005c flags 000001b5
mmc0:     blksz 92 blocks 1 flags 00000100 tsac 1000 ms nsac 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000003
mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc0:     92 bytes transferred: 0
mmc0: starting CMD52 arg 00000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
mmc0: starting CMD52 arg 10000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001003 00000000 00000000 00000000
mmc0: starting CMD52 arg 90000afc flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 000010fc 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006800 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 0000104e 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
mmc0: starting CMD52 arg 10004000 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 0000100a 00000000 00000000 00000000
mmc0: starting CMD53 arg 1a000003 flags 000001b5
mmc0:     blksz 256 blocks 3 flags 00000200 tsac 1000 ms nsac 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc0:     768 bytes transferred: 0
mmc0: starting CMD52 arg 10004000 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
mmc0: req done (CMD52): 0: 00001008 00000000 00000000 00000000
mmc0: starting CMD53 arg 9200004c flags 000001b5
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000100
mmc0:     blksz 76 blocks 1 flags 00000100 tsac 1000 ms nsac 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000103
mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc0:     76 bytes transferred: 0
mmc0: starting CMD52 arg 00000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
mmc0: starting CMD52 arg 10000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001003 00000000 00000000 00000000
mmc0: starting CMD52 arg 90000afc flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 000010fc 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006800 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 0000104a 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001000 00000000 00000000 00000000
mmc0: starting CMD52 arg 10004000 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001009 00000000 00000000 00000000
mmc0: starting CMD53 arg 1200004c flags 000001b5
mmc0:     blksz 76 blocks 1 flags 00000200 tsac 1000 ms nsac 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000103
mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc0:     76 bytes transferred: 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000100
mmc0: starting CMD52 arg 00000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
mmc0: starting CMD52 arg 10000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001001 00000000 00000000 00000000
mmc0: starting CMD52 arg 90000afe flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 000010fe 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006800 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 0000104a 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001000 00000000 00000000 00000000
mmc0: starting CMD52 arg 10004000 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 0000100a 00000000 00000000 00000000
mmc0: starting CMD53 arg 1200004c flags 000001b5
mmc0:     blksz 76 blocks 1 flags 00000200 tsac 1000 ms nsac 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000103
mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc0:     76 bytes transferred: 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000100
mmc0: starting CMD52 arg 00000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
mmc0: starting CMD52 arg 10000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001001 00000000 00000000 00000000
mmc0: starting CMD52 arg 90000afe flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 000010fe 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006800 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 0000104e 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
mmc0: starting CMD52 arg 10004000 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 0000100a 00000000 00000000 00000000
mmc0: starting CMD53 arg 1a000003 flags 000001b5
mmc0:     blksz 256 blocks 3 flags 00000200 tsac 1000 ms nsac 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc0:     768 bytes transferred: 0
mmc0: starting CMD52 arg 10004000 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
mmc0: req done (CMD52): 0: 00001008 00000000 00000000 00000000
mmc0: starting CMD53 arg 9200004c flags 000001b5
mmc0:     blksz 76 blocks 1 flags 00000100 tsac 1000 ms nsac 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000003
mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc0:     76 bytes transferred: 0
mmc0: starting CMD52 arg 00000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
mmc0: starting CMD52 arg 10000a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001003 00000000 00000000 00000000
mmc0: starting CMD52 arg 90000afc flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 000010fc 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006800 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 0000104e 00000000 00000000 00000000
mmc0: starting CMD52 arg 10006a00 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
mmc0: starting CMD52 arg 10004000 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD52): 0: 0000100a 00000000 00000000 00000000
mmc0: starting CMD53 arg 1a000003 flags 000001b5
mmc0:     blksz 256 blocks 3 flags 00000200 tsac 1000 ms nsac 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000101
mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc0:     768 bytes transferred: 0
mmc0: starting CMD52 arg 10004000 flags 00000195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
mmc0: req done (CMD52): 0: 00001008 00000000 00000000 00000000
mmc0: starting CMD53 arg 9200004c flags 000001b5
mmc0:     blksz 76 blocks 1 flags 00000100 tsac 1000 ms nsac 0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000003
mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc0:     76 bytes transferred: 0

From hmravi at gmail.com  Sun Nov 22 21:20:31 2009
From: hmravi at gmail.com (Ravi Mahadevappa)
Date: Sun, 22 Nov 2009 18:20:31 -0800
Subject: Libertas driver performance on Samsung platform
In-Reply-To: <39811fe10911221740w89f25e6m7178af9114a98d21@mail.gmail.com>
References: <39811fe10911221740w89f25e6m7178af9114a98d21@mail.gmail.com>
Message-ID: <30fdd8d80911221820k543b9dc2n6401d6114d3d74bc@mail.gmail.com>

Hi Jacky,

Thanks for the response. In our case, these are in place already.
Maybe I am not using the right tools to measure the throughput. I will
try to check with iperf.

Best Regards,
Ravi

On Sun, Nov 22, 2009 at 5:40 PM, Jacky Lam <jackylam.gsl at gmail.com> wrote:
> Dear Ravi,
>
> ? ? ? ?The problem we have met is our platform driver use polling when dealing
> SDIO interrupt. The solution is provided by tommy. I will describe the
> solution as follows:
>
> ? ? ? ?1) Your mmc host capability need to enable MMC_CAP_SDIO_IRQ.
> ? ? ? ?2) In mmc host operations (struct mmc_host_ops), you have to implement
> the callback enable_sdio_irq.
>
> ? ? ? ?Also, the firmware version we are using is v9 as Dan said.
>
> ? ? ? ?Hope this help.
>
> Br,
> Jacky
>
> Ravi Mahadevappa ??:
>> Hi Dan, Jacky,
>>
>> We are facing the same problem. Could you please elaborate a bit on this
>> issue.
>> What is the firmware version and the driver version I should use?
>> Where do I look to verify that the interrupt support is enabled?
>>
>> Thanks,
>> Ravi
>>
>> On 11/15/2009 10:43 PM, Jacky Lam wrote:
>>> Dear Dan,
>>>
>>> ? ? ?I just talk to tommy and find that the problem really happened in the
>>> interrupt support as you said. Thanks for all advice from you.
>>>
>>> BR,
>>> Jacky
>>>
>>> Dan Williams ??:
>>>
>>>> On Mon, 2009-11-16 at 09:43 +0800, Jacky Lam wrote:
>>>>
>>>>> Dan Williams ??:
>>>>>
>>>>>> On Fri, 2009-11-13 at 13:12 +0800, Jacky Lam wrote:
>>>>>>
>>>>>>> Dear all,
>>>>>>>
>>>>>>> ?I have read the previous mail about the low performance of Samsung
>>>>>>> BSP's SDIO platform driver when working with Libertas. I want to know if
>>>>>>> anyone have tried the kernel mainstream's Samsung driver and have any
>>>>>>> improvement on that?
>>>>>>>
>>>>>> Does the Samsung SDHC have quirks or limitations with respect to DMA,
>>>>>> block size, transfer width, etc?
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Dear Dan,
>>>>>
>>>>> ? ?I look through the source code and can't find any "special" limitation
>>>>> for the DMA, block size, transfer width.....Maybe I am not familiar
>>>>> enough with Linux MMC stack. Could you tell me if there is any
>>>>> requirement for the MMC stack on the host's DMA, block size, transfer
>>>>> width..etc? So, I can pinpoint my investigation?
>>>>>
>>>> There's no requirement in the stack, but the libertas driver and
>>>> firmware expect multi-block transfer ability and interrupt support. ?The
>>>> libertas firmware will fail to load if if the host controller doesn't
>>>> support multi-block, which we just found to be a limitation of one of
>>>> the i.MX platform for example.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> libertas-dev mailing list
>>> libertas-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/libertas-dev
>>>
>


From jackylam.gsl at gmail.com  Sun Nov 22 20:40:53 2009
From: jackylam.gsl at gmail.com (Jacky Lam)
Date: Mon, 23 Nov 2009 09:40:53 +0800
Subject: Libertas driver performance on Samsung platform
Message-ID: <39811fe10911221740w89f25e6m7178af9114a98d21@mail.gmail.com>

Dear Ravi,

	The problem we have met is our platform driver use polling when dealing
SDIO interrupt. The solution is provided by tommy. I will describe the
solution as follows:

	1) Your mmc host capability need to enable MMC_CAP_SDIO_IRQ.
	2) In mmc host operations (struct mmc_host_ops), you have to implement
the callback enable_sdio_irq.

	Also, the firmware version we are using is v9 as Dan said.

	Hope this help.

Br,
Jacky

Ravi Mahadevappa ??:
> Hi Dan, Jacky,
>
> We are facing the same problem. Could you please elaborate a bit on this
> issue.
> What is the firmware version and the driver version I should use?
> Where do I look to verify that the interrupt support is enabled?
>
> Thanks,
> Ravi
>
> On 11/15/2009 10:43 PM, Jacky Lam wrote:
>> Dear Dan,
>>
>> 	I just talk to tommy and find that the problem really happened in the
>> interrupt support as you said. Thanks for all advice from you.
>>
>> BR,
>> Jacky
>>
>> Dan Williams ??:
>>
>>> On Mon, 2009-11-16 at 09:43 +0800, Jacky Lam wrote:
>>>
>>>> Dan Williams ??:
>>>>
>>>>> On Fri, 2009-11-13 at 13:12 +0800, Jacky Lam wrote:
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> 	I have read the previous mail about the low performance of Samsung
>>>>>> BSP's SDIO platform driver when working with Libertas. I want to know if
>>>>>> anyone have tried the kernel mainstream's Samsung driver and have any
>>>>>> improvement on that?
>>>>>>
>>>>> Does the Samsung SDHC have quirks or limitations with respect to DMA,
>>>>> block size, transfer width, etc?
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Dear Dan,
>>>>
>>>> 	I look through the source code and can't find any "special" limitation
>>>> for the DMA, block size, transfer width.....Maybe I am not familiar
>>>> enough with Linux MMC stack. Could you tell me if there is any
>>>> requirement for the MMC stack on the host's DMA, block size, transfer
>>>> width..etc? So, I can pinpoint my investigation?
>>>>
>>> There's no requirement in the stack, but the libertas driver and
>>> firmware expect multi-block transfer ability and interrupt support.  The
>>> libertas firmware will fail to load if if the host controller doesn't
>>> support multi-block, which we just found to be a limitation of one of
>>> the i.MX platform for example.
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> libertas-dev mailing list
>> libertas-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/libertas-dev
>>


From cmccabe at alumni.cmu.edu  Mon Nov 30 19:53:44 2009
From: cmccabe at alumni.cmu.edu (Colin McCabe)
Date: Mon, 30 Nov 2009 16:53:44 -0800
Subject: [PATCH] libertas: remove internal buffers from GSPI driver
In-Reply-To: <1256687501-8636-1-git-send-email-andrey@cozybit.com>
References: <1256687501-8636-1-git-send-email-andrey@cozybit.com>
Message-ID: <436f52800911301653q224bacceq4a14cbbfaa5cc0e2@mail.gmail.com>

On Tue, Oct 27, 2009 at 3:51 PM, Andrey Yurovsky <andrey at cozybit.com> wrote:
> This patch removes the internal command and data buffers that the GSPI driver
> maintained and instead relies on the Libertas core to synchronize access
> to the command and data ports as with the other interface drivers.

Hi all,

I'm glad to see you're improving stuff. Good catch with some of the
recent bugfixes.

However... it seems like you are headed for a "scheduling while
atomic" with this patch.

The original reason why if_spi_host_to_card copied the data into a
buffer, rather than simply calling spu_write and being done with it,
was that spu_write needed to sleep. spu_write invokes spi_sync, which
has a big comment that says "This call may only be used from a context
that may sleep."

Unfortunately, if_spi_host_to_card is called from contexts where we
hold a spinlock. For example, lbs_main does

spin_lock_irq(&priv->driver_lock);
if (!priv->dnld_sent && priv->tx_pending_len > 0) {
    int ret = priv->hw_host_to_card(priv, MVMS_DAT,

priv->tx_pending_buf,

priv->tx_pending_len);
...etc...

Perhaps the easiest thing would be to get rid of this usage of hw_host_to_card?
spu_write will always have to busy-wait from time to time because the
SPU requires a delay between successive transactions. Busy-waiting
under a spinlock, with interrupts disabled, just doesn't seem right.

Also the comment in if_spi_c2h_cmd that "we need a buffer big enough
to handle whatever people send to hw_host_to_card" should go away if
the buffer is not used in hw_host_to_card.

> This is an incremental cleanup: after removing the redundant buffers, we
> can further improve the driver to use a threaded IRQ handler instead of
> maintaining its own thread. ?However I would like a few folks to test
> the buffer removal first and make sure that I'm not introducing
> regressions.

Threaded IRQs, cool. I'm waiting for that patch. :)

Colin


>
> Tested on Blackfin BF527 with DMA disabled due to an issue with the SPI
> host controller driver in the current bleeding-edge Blackfin kernel. ?I
> would appreciate it if someone with working DMA could test this patch
> and provide feedback.
>
> Signed-off-by: Andrey Yurovsky <andrey at cozybit.com>
> ---
> ?drivers/net/wireless/libertas/if_spi.c | ?136 ++------------------------------
> ?1 files changed, 6 insertions(+), 130 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/if_spi.c b/drivers/net/wireless/libertas/if_spi.c
> index 06df2e1..9e0096d 100644
> --- a/drivers/net/wireless/libertas/if_spi.c
> +++ b/drivers/net/wireless/libertas/if_spi.c
> @@ -32,12 +32,6 @@
> ?#include "dev.h"
> ?#include "if_spi.h"
>
> -struct if_spi_packet {
> - ? ? ? struct list_head ? ? ? ? ? ? ? ?list;
> - ? ? ? u16 ? ? ? ? ? ? ? ? ? ? ? ? ? ? blen;
> - ? ? ? u8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?buffer[0] __attribute__((aligned(4)));
> -};
> -
> ?struct if_spi_card {
> ? ? ? ?struct spi_device ? ? ? ? ? ? ? *spi;
> ? ? ? ?struct lbs_private ? ? ? ? ? ? ?*priv;
> @@ -66,33 +60,10 @@ struct if_spi_card {
> ? ? ? ?struct semaphore ? ? ? ? ? ? ? ?spi_thread_terminated;
>
> ? ? ? ?u8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?cmd_buffer[IF_SPI_CMD_BUF_SIZE];
> -
> - ? ? ? /* A buffer of incoming packets from libertas core.
> - ? ? ? ?* Since we can't sleep in hw_host_to_card, we have to buffer
> - ? ? ? ?* them. */
> - ? ? ? struct list_head ? ? ? ? ? ? ? ?cmd_packet_list;
> - ? ? ? struct list_head ? ? ? ? ? ? ? ?data_packet_list;
> -
> - ? ? ? /* Protects cmd_packet_list and data_packet_list */
> - ? ? ? spinlock_t ? ? ? ? ? ? ? ? ? ? ?buffer_lock;
> ?};
>
> ?static void free_if_spi_card(struct if_spi_card *card)
> ?{
> - ? ? ? struct list_head *cursor, *next;
> - ? ? ? struct if_spi_packet *packet;
> -
> - ? ? ? BUG_ON(card->run_thread);
> - ? ? ? list_for_each_safe(cursor, next, &card->cmd_packet_list) {
> - ? ? ? ? ? ? ? packet = container_of(cursor, struct if_spi_packet, list);
> - ? ? ? ? ? ? ? list_del(&packet->list);
> - ? ? ? ? ? ? ? kfree(packet);
> - ? ? ? }
> - ? ? ? list_for_each_safe(cursor, next, &card->data_packet_list) {
> - ? ? ? ? ? ? ? packet = container_of(cursor, struct if_spi_packet, list);
> - ? ? ? ? ? ? ? list_del(&packet->list);
> - ? ? ? ? ? ? ? kfree(packet);
> - ? ? ? }
> ? ? ? ?spi_set_drvdata(card->spi, NULL);
> ? ? ? ?kfree(card);
> ?}
> @@ -774,40 +745,6 @@ out:
> ? ? ? ?return err;
> ?}
>
> -/* Move data or a command from the host to the card. */
> -static void if_spi_h2c(struct if_spi_card *card,
> - ? ? ? ? ? ? ? ? ? ? ? struct if_spi_packet *packet, int type)
> -{
> - ? ? ? int err = 0;
> - ? ? ? u16 int_type, port_reg;
> -
> - ? ? ? switch (type) {
> - ? ? ? case MVMS_DAT:
> - ? ? ? ? ? ? ? int_type = IF_SPI_CIC_TX_DOWNLOAD_OVER;
> - ? ? ? ? ? ? ? port_reg = IF_SPI_DATA_RDWRPORT_REG;
> - ? ? ? ? ? ? ? break;
> - ? ? ? case MVMS_CMD:
> - ? ? ? ? ? ? ? int_type = IF_SPI_CIC_CMD_DOWNLOAD_OVER;
> - ? ? ? ? ? ? ? port_reg = IF_SPI_CMD_RDWRPORT_REG;
> - ? ? ? ? ? ? ? break;
> - ? ? ? default:
> - ? ? ? ? ? ? ? lbs_pr_err("can't transfer buffer of type %d\n", type);
> - ? ? ? ? ? ? ? err = -EINVAL;
> - ? ? ? ? ? ? ? goto out;
> - ? ? ? }
> -
> - ? ? ? /* Write the data to the card */
> - ? ? ? err = spu_write(card, port_reg, packet->buffer, packet->blen);
> - ? ? ? if (err)
> - ? ? ? ? ? ? ? goto out;
> -
> -out:
> - ? ? ? kfree(packet);
> -
> - ? ? ? if (err)
> - ? ? ? ? ? ? ? lbs_pr_err("%s: error %d\n", __func__, err);
> -}
> -
> ?/* Inform the host about a card event */
> ?static void if_spi_e2h(struct if_spi_card *card)
> ?{
> @@ -837,8 +774,6 @@ static int lbs_spi_thread(void *data)
> ? ? ? ?int err;
> ? ? ? ?struct if_spi_card *card = data;
> ? ? ? ?u16 hiStatus;
> - ? ? ? unsigned long flags;
> - ? ? ? struct if_spi_packet *packet;
>
> ? ? ? ?while (1) {
> ? ? ? ? ? ? ? ?/* Wait to be woken up by one of two things. ?First, our ISR
> @@ -877,43 +812,9 @@ static int lbs_spi_thread(void *data)
> ? ? ? ? ? ? ? ?if (hiStatus & IF_SPI_HIST_CMD_DOWNLOAD_RDY ||
> ? ? ? ? ? ? ? ? ? (card->priv->psstate != PS_STATE_FULL_POWER &&
> ? ? ? ? ? ? ? ? ? ?(hiStatus & IF_SPI_HIST_TX_DOWNLOAD_RDY))) {
> - ? ? ? ? ? ? ? ? ? ? ? /* This means two things. First of all,
> - ? ? ? ? ? ? ? ? ? ? ? ?* if there was a previous command sent, the card has
> - ? ? ? ? ? ? ? ? ? ? ? ?* successfully received it.
> - ? ? ? ? ? ? ? ? ? ? ? ?* Secondly, it is now ready to download another
> - ? ? ? ? ? ? ? ? ? ? ? ?* command.
> - ? ? ? ? ? ? ? ? ? ? ? ?*/
> ? ? ? ? ? ? ? ? ? ? ? ?lbs_host_to_card_done(card->priv);
> -
> - ? ? ? ? ? ? ? ? ? ? ? /* Do we have any command packets from the host to
> - ? ? ? ? ? ? ? ? ? ? ? ?* send? */
> - ? ? ? ? ? ? ? ? ? ? ? packet = NULL;
> - ? ? ? ? ? ? ? ? ? ? ? spin_lock_irqsave(&card->buffer_lock, flags);
> - ? ? ? ? ? ? ? ? ? ? ? if (!list_empty(&card->cmd_packet_list)) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? packet = (struct if_spi_packet *)(card->
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cmd_packet_list.next);
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? list_del(&packet->list);
> - ? ? ? ? ? ? ? ? ? ? ? }
> - ? ? ? ? ? ? ? ? ? ? ? spin_unlock_irqrestore(&card->buffer_lock, flags);
> -
> - ? ? ? ? ? ? ? ? ? ? ? if (packet)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if_spi_h2c(card, packet, MVMS_CMD);
> ? ? ? ? ? ? ? ?}
> - ? ? ? ? ? ? ? if (hiStatus & IF_SPI_HIST_TX_DOWNLOAD_RDY) {
> - ? ? ? ? ? ? ? ? ? ? ? /* Do we have any data packets from the host to
> - ? ? ? ? ? ? ? ? ? ? ? ?* send? */
> - ? ? ? ? ? ? ? ? ? ? ? packet = NULL;
> - ? ? ? ? ? ? ? ? ? ? ? spin_lock_irqsave(&card->buffer_lock, flags);
> - ? ? ? ? ? ? ? ? ? ? ? if (!list_empty(&card->data_packet_list)) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? packet = (struct if_spi_packet *)(card->
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? data_packet_list.next);
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? list_del(&packet->list);
> - ? ? ? ? ? ? ? ? ? ? ? }
> - ? ? ? ? ? ? ? ? ? ? ? spin_unlock_irqrestore(&card->buffer_lock, flags);
>
> - ? ? ? ? ? ? ? ? ? ? ? if (packet)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if_spi_h2c(card, packet, MVMS_DAT);
> - ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ?if (hiStatus & IF_SPI_HIST_CARD_EVENT)
> ? ? ? ? ? ? ? ? ? ? ? ?if_spi_e2h(card);
>
> @@ -942,40 +843,18 @@ static int if_spi_host_to_card(struct lbs_private *priv,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u8 type, u8 *buf, u16 nb)
> ?{
> ? ? ? ?int err = 0;
> - ? ? ? unsigned long flags;
> ? ? ? ?struct if_spi_card *card = priv->card;
> - ? ? ? struct if_spi_packet *packet;
> - ? ? ? u16 blen;
>
> ? ? ? ?lbs_deb_enter_args(LBS_DEB_SPI, "type %d, bytes %d", type, nb);
>
> - ? ? ? if (nb == 0) {
> - ? ? ? ? ? ? ? lbs_pr_err("%s: invalid size requested: %d\n", __func__, nb);
> - ? ? ? ? ? ? ? err = -EINVAL;
> - ? ? ? ? ? ? ? goto out;
> - ? ? ? }
> - ? ? ? blen = ALIGN(nb, 4);
> - ? ? ? packet = kzalloc(sizeof(struct if_spi_packet) + blen, GFP_ATOMIC);
> - ? ? ? if (!packet) {
> - ? ? ? ? ? ? ? err = -ENOMEM;
> - ? ? ? ? ? ? ? goto out;
> - ? ? ? }
> - ? ? ? packet->blen = blen;
> - ? ? ? memcpy(packet->buffer, buf, nb);
> - ? ? ? memset(packet->buffer + nb, 0, blen - nb);
> + ? ? ? nb = ALIGN(nb, 4);
>
> ? ? ? ?switch (type) {
> ? ? ? ?case MVMS_CMD:
> - ? ? ? ? ? ? ? priv->dnld_sent = DNLD_CMD_SENT;
> - ? ? ? ? ? ? ? spin_lock_irqsave(&card->buffer_lock, flags);
> - ? ? ? ? ? ? ? list_add_tail(&packet->list, &card->cmd_packet_list);
> - ? ? ? ? ? ? ? spin_unlock_irqrestore(&card->buffer_lock, flags);
> + ? ? ? ? ? ? ? err = spu_write(card, IF_SPI_CMD_RDWRPORT_REG, buf, nb);
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?case MVMS_DAT:
> - ? ? ? ? ? ? ? priv->dnld_sent = DNLD_DATA_SENT;
> - ? ? ? ? ? ? ? spin_lock_irqsave(&card->buffer_lock, flags);
> - ? ? ? ? ? ? ? list_add_tail(&packet->list, &card->data_packet_list);
> - ? ? ? ? ? ? ? spin_unlock_irqrestore(&card->buffer_lock, flags);
> + ? ? ? ? ? ? ? err = spu_write(card, IF_SPI_DATA_RDWRPORT_REG, buf, nb);
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?default:
> ? ? ? ? ? ? ? ?lbs_pr_err("can't transfer buffer of type %d", type);
> @@ -983,9 +862,6 @@ static int if_spi_host_to_card(struct lbs_private *priv,
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?}
>
> - ? ? ? /* Wake up the spi thread */
> - ? ? ? up(&card->spi_ready);
> -out:
> ? ? ? ?lbs_deb_leave_args(LBS_DEB_SPI, "err=%d", err);
> ? ? ? ?return err;
> ?}
> @@ -1062,9 +938,6 @@ static int __devinit if_spi_probe(struct spi_device *spi)
>
> ? ? ? ?sema_init(&card->spi_ready, 0);
> ? ? ? ?sema_init(&card->spi_thread_terminated, 0);
> - ? ? ? INIT_LIST_HEAD(&card->cmd_packet_list);
> - ? ? ? INIT_LIST_HEAD(&card->data_packet_list);
> - ? ? ? spin_lock_init(&card->buffer_lock);
>
> ? ? ? ?/* Initialize the SPI Interface Unit */
> ? ? ? ?err = spu_init(card, pdata->use_dummy_writes);
> @@ -1141,6 +1014,9 @@ static int __devinit if_spi_probe(struct spi_device *spi)
> ? ? ? ? ? ? ? ?goto terminate_thread;
> ? ? ? ?}
>
> + ? ? ? /* poke the IRQ handler so that we don't miss the first interrupt */
> + ? ? ? up(&card->spi_ready);
> +
> ? ? ? ?/* Start the card.
> ? ? ? ? * This will call register_netdev, and we'll start
> ? ? ? ? * getting interrupts... */
> --
> 1.5.6.3
>
>
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev
>


From bogus@does.not.exist.com  Fri Nov  6 13:01:15 2009
From: bogus@does.not.exist.com ()
Date: Fri, 06 Nov 2009 18:01:15 -0000
Subject: No subject
Message-ID: <mailman.89.1260548453.2170.libertas-dev@lists.infradead.org>

Office Of The  Director British finance 
monitoring unit


In agreement with the United Nation (UN) concerning all overdue/pending payment on Contracts/ Inheritance/ Winning funds we are contacting you that we the British Finance Monitoring Unit (BFMU), in collaboration with our affilited Bank we had agreed to effect your payment installment.  

Note: That for security reason, your fund is placed in an Escrow/Bond account with our affiliated Bank London pending when your present a clear and good evidence of fund ownership, for further verification you are to confirm the following: FULL NAME, HOME ADDRESS, PHONE/FAX NUMBERS, IDENTIFICATION AND ACCOUNT DETAILS.

We are expecting to hear from with the verification of the information.

Thanks
PETER MARRIOTT
DIRECTOR BRITISH FINANCE MONITORING UNIT





From bogus@does.not.exist.com  Fri Nov  6 13:01:15 2009
From: bogus@does.not.exist.com ()
Date: Fri, 06 Nov 2009 18:01:15 -0000
Subject: No subject
Message-ID: <mailman.96.1260935951.2170.libertas-dev@lists.infradead.org>

at all places, I checked it several times now. (Btw, the %s format
string you pointed out all use print_ssid() to properly escape all
non-printable characters, so they're rules out, too).

I'll send a patch to fix the flaw in libertas.

Thanks,
Daniel



From bogus@does.not.exist.com  Fri Nov  6 13:01:15 2009
From: bogus@does.not.exist.com ()
Date: Fri, 06 Nov 2009 18:01:15 -0000
Subject: No subject
Message-ID: <mailman.237.1268426786.2170.libertas-dev@lists.infradead.org>

the next step?  I'd like to see them merged rather than bitrot, is
there something we can do to move forward?

Deepak -- can you or someone from your team step help with the
mesh-related issues?

Thanks,

  -Andrey


From bogus@does.not.exist.com  Fri Nov  6 13:01:15 2009
From: bogus@does.not.exist.com ()
Date: Fri, 06 Nov 2009 18:01:15 -0000
Subject: No subject
Message-ID: <mailman.289.1270143579.2170.libertas-dev@lists.infradead.org>

>
> If the SSID coming in from WEXT *is* valid, but somehow the driver is
> messing up the SSID internally before sending the assoc request, well
> that's a different story and we should fix that. =C2=A0Any idea if the
> incoming WEXT SSID is valid or not?

I have dumped dwrq->flags, extra, and dwrq->length and get

1, %=EF=BF=BD\01, 32

the extra can be varying lengths of garbage always with \00 or \01.

What concerns me about the bogus SSID has a null character in the
middle of it.  This seems to me that we are doing bad math somewhere.
That looks to me like a blank SSID a null then a flag possibly.

>
> But honestly we should be queuing the assoc request and only execeuting
> it *after* the scan is done. =C2=A0Or we could reject assoc becuase there=
's
> an ongoing scan, but that's just mean and makes clients fail.

I have enable wpa_supplicant logging and I don't see the association
request anywhere.  I see the scan requests but not an association
request until the scan has finished and it has found my AP.

Thanks for the pointers.  I will also try dumping the invalid
association request and verify that fixes the scanning delay I am
seeing.

Jon


From bogus@does.not.exist.com  Fri Nov  6 13:01:15 2009
From: bogus@does.not.exist.com ()
Date: Fri, 06 Nov 2009 18:01:15 -0000
Subject: No subject
Message-ID: <mailman.297.1270563076.2170.libertas-dev@lists.infradead.org>

I
have done that but this is not working. I have the same behaviour.=20

I think they have a faulty modules. Their engineer have no Idea why this =
is
not working. I 'll sill waiting for a solution from zcomax.=20

Since I can't have the Marvell Datasheet, I had to wait the answer from
zcomax.=20

JOnathan

>=20
> - Alagu Sankar
>=20
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev




