[PATCH 0/3] ath9k: several fixes ported to 2.6.27

[PATCH 0/3] ath9k: several fixes ported to 2.6.27

[Luis R. Rodriguez]

This fixes a few issues seen on MacBook Pros:

http://bugzilla.kernel.org/show_bug.cgi?id=11811

I've ported them to 2.6.27 to help with them being applied sooner.
I've tried to keep them as small as possible. I don't have the
ports for 2.6.28 though I think John will be sending them soon
through his pending-fixes branch.

These are already applied on wireless-testing.

  Luis

[PATCH] ath9k: Fix SW-IOMMU bounce buffer starvation

[Luis R. Rodriguez]

This should fix the SW-IOMMU bounce buffer starvation
seen ok kernel.org bugzilla 11811:

http://bugzilla.kernel.org/show_bug.cgi?id=11811

Users on MacBook Pro 3.1/MacBook v2 would see something like:

DMA: Out of SW-IOMMU space for 4224 bytes at device 0000:0b:00.0

Unfortunately its only easy to trigger on MacBook Pro 3.1/MacBook v2
so far so its difficult to debug (even with swiotlb=force).

We were pci_unmap_single()'ing less bytes than what we called
for with pci_map_single() and as such we were starving
the swiotlb from its 64MB amount of bounce buffers. We remain
consistent and now always use sc->rxbufsize for RX. While at
it we update the beacon DMA maps as well to only use the data
portion of the skb, previous to this we were pci_map_single()'ing
more data for beaconing than what we tell the hardware it can use,
therefore pushing more iotlb abuse.

Still not sure why this is so easily triggerable on
MacBook Pro 3.1, it may be the hardware configuration
tends to use more memory > 3GB mark for DMA.

Signed-off-by: Maciej Zenczykowski <zenczykowski@gmail.com>
Signed-off-by: Bennyam Malavazi <Bennyam.Malavazi@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath9k/recv.c |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath9k/recv.c b/drivers/net/wireless/ath9k/recv.c
index 20ddb7a..4d23827 100644
--- a/drivers/net/wireless/ath9k/recv.c
+++ b/drivers/net/wireless/ath9k/recv.c
@@ -1011,7 +1011,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
 
 		pci_dma_sync_single_for_cpu(sc->pdev,
 					    bf->bf_buf_addr,
-					    skb_tailroom(skb),
+					    sc->sc_rxbufsize,
 					    PCI_DMA_FROMDEVICE);
 		pci_unmap_single(sc->pdev,
 				 bf->bf_buf_addr,
@@ -1303,8 +1303,7 @@ dma_addr_t ath_skb_map_single(struct ath_softc *sc,
 	 * NB: do NOT use skb->len, which is 0 on initialization.
 	 * Use skb's entire data area instead.
 	 */
-	*pa = pci_map_single(sc->pdev, skb->data,
-		skb_end_pointer(skb) - skb->head, direction);
+	*pa = pci_map_single(sc->pdev, skb->data, sc->sc_rxbufsize, direction);
 	return *pa;
 }
 
@@ -1314,6 +1313,5 @@ void ath_skb_unmap_single(struct ath_softc *sc,
 			  dma_addr_t *pa)
 {
 	/* Unmap skb's entire data area */
-	pci_unmap_single(sc->pdev, *pa,
-		skb_end_pointer(skb) - skb->head, direction);
+	pci_unmap_single(sc->pdev, *pa, sc->sc_rxbufsize, direction);
 }
-- 
1.5.6.rc2.15.g457bb.dirty

[PATCH] ath9k: correct expected max RX buffer size

[Luis R. Rodriguez]

We should only tell the hardware its capable of DMA'ing
to us only what we asked dev_alloc_skb(). Prior to this
it is possible a large RX'd frame could have corrupted
DMA data but for us but we were saved only because we
were previously also pci_map_single()'ing the same large
value. The issue prior to this though was we were unmapping
a smaller amount which the prior DMA patch fixed.

Signed-off-by: Bennyam Malavazi <Bennyam.Malavazi@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath9k/recv.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath9k/recv.c b/drivers/net/wireless/ath9k/recv.c
index 4d23827..0941589 100644
--- a/drivers/net/wireless/ath9k/recv.c
+++ b/drivers/net/wireless/ath9k/recv.c
@@ -52,7 +52,7 @@ static void ath_rx_buf_link(struct ath_softc *sc, struct ath_buf *bf)
 	/* setup rx descriptors */
 	ath9k_hw_setuprxdesc(ah,
 			     ds,
-			     skb_tailroom(skb),   /* buffer size */
+			     sc->sc_rxbufsize,
 			     0);
 
 	if (sc->sc_rxlink == NULL)
-- 
1.5.6.rc2.15.g457bb.dirty

[PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Luis R. Rodriguez]

We would get an oops on RX on -ENOMEM by passing
NULL to the hardware on ath_rx_buf_link(). The oops
would look something like this:

ath_rx_tasklet
...
RIP: ath_rx_buf_link

We correct this by handling the allocation for the next
skb we will put in our RX tail directly on the ath_rx_tasklet()
*prior* to sending up the last hardware processed
skb. If we run out of memory this gauranteees we have
skbs to work with while it simply drops new received
frames.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath9k/recv.c |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath9k/recv.c b/drivers/net/wireless/ath9k/recv.c
index 0941589..a4f92b2 100644
--- a/drivers/net/wireless/ath9k/recv.c
+++ b/drivers/net/wireless/ath9k/recv.c
@@ -441,18 +441,16 @@ static void ath_rx_requeue(struct ath_softc *sc, struct sk_buff *skb)
  */
 static int ath_rx_indicate(struct ath_softc *sc,
 			   struct sk_buff *skb,
+			   struct sk_buff *nskb,
 			   struct ath_recv_status *status,
 			   u16 keyix)
 {
 	struct ath_buf *bf = ATH_RX_CONTEXT(skb)->ctx_rxbuf;
-	struct sk_buff *nskb;
 	int type;
 
 	/* indicate frame to the stack, which will free the old skb. */
 	type = ath__rx_indicate(sc, skb, status, keyix);
 
-	/* allocate a new skb and queue it to for H/W processing */
-	nskb = ath_rxbuf_alloc(sc, sc->sc_rxbufsize);
 	if (nskb != NULL) {
 		bf->bf_mpdu = nskb;
 		bf->bf_buf_addr = ath_skb_map_single(sc,
@@ -741,6 +739,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
 	struct ath_desc *ds;
 	struct ieee80211_hdr *hdr;
 	struct sk_buff *skb = NULL;
+	struct sk_buff *nskb = NULL;
 	struct ath_recv_status rx_status;
 	struct ath_hal *ah = sc->sc_ah;
 	int type, rx_processed = 0;
@@ -963,6 +962,17 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
 		 */
 		if (sc->sc_rxbufsize < ds->ds_rxstat.rs_datalen)
 			goto rx_next;
+
+		/* allocate a new skb and queue it to for H/W processing */
+		nskb = ath_rxbuf_alloc(sc, sc->sc_rxbufsize);
+
+		/* Diregard current RX'd frame and reuse the old skb */
+		if (!nskb) {
+			list_move_tail(&bf->list, &sc->sc_rxbuf);
+			ath_rx_buf_link(sc, bf);
+			goto rx_next;
+		}
+
 		/*
 		 * Sync and unmap the frame.  At this point we're
 		 * committed to passing the sk_buff somewhere so
@@ -1052,7 +1062,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
 
 		/* Pass frames up to the stack. */
 
-		type = ath_rx_indicate(sc, skb,
+		type = ath_rx_indicate(sc, skb, nskb,
 			&rx_status, ds->ds_rxstat.rs_keyix);
 
 		/*
-- 
1.5.6.rc2.15.g457bb.dirty

Re: [ath9k-devel] [PATCH 0/3] ath9k: several fixes ported to 2.6.27

[Luis R. Rodriguez]

On Tue, Dec 2, 2008 at 12:51 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> This fixes a few issues seen on MacBook Pros:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=11811
>
> I've ported them to 2.6.27 to help with them being applied sooner.
> I've tried to keep them as small as possible. I don't have the
> ports for 2.6.28 though I think John will be sending them soon
> through his pending-fixes branch.
>
> These are already applied on wireless-testing.

Oh sorry, I noticed patch 2 and 3 didn't go with the subject to
indicate their order. The order they should be applied in is:

0001-ath9k-Fix-SW-IOMMU-bounce-buffer-starvation.patch
0002-ath9k-correct-expected-max-RX-buffer-size.patch
0003-ath9k-Handle-ENOMEM-on-RX-gracefully.patch

You can also find these here:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2008-11-22/27-IOMMU-01/

  Luis

Re: [stable] [PATCH 0/3] ath9k: several fixes ported to 2.6.27

[Greg KH]

On Tue, Dec 02, 2008 at 12:51:19PM -0800, Luis R. Rodriguez wrote:
> This fixes a few issues seen on MacBook Pros:
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=11811
> 
> I've ported them to 2.6.27 to help with them being applied sooner.

What do you mean by "sooner"?  They need to be in Linus's tree before we
can add them to the 2.6.27-stable tree.  Please let us know when that
happens, and what the git ids of them are, so we can add them to the
next -stable release.

thanks,

greg k-h

Re: [stable] [PATCH 0/3] ath9k: several fixes ported to 2.6.27

[Luis R. Rodriguez]

On Tue, Dec 2, 2008 at 1:27 PM, Greg KH <greg@kroah.com> wrote:
> On Tue, Dec 02, 2008 at 12:51:19PM -0800, Luis R. Rodriguez wrote:
>> This fixes a few issues seen on MacBook Pros:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=11811
>>
>> I've ported them to 2.6.27 to help with them being applied sooner.
>
> What do you mean by "sooner"?  They need to be in Linus's tree before we
> can add them to the 2.6.27-stable tree.  Please let us know when that
> happens, and what the git ids of them are, so we can add them to the
> next -stable release.

Heh, well once applied there it may not apply on 27, so by sooner I
mean that you don't have to do backport work as I did it for you.

  Luis

Re: [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Greg KH]

I don't see this patch upstream in Linus's tree.  Am I just missing it
and if so, do you know the git commit id?

thanks,

greg k-h


On Tue, Dec 02, 2008 at 12:51:22PM -0800, Luis R. Rodriguez wrote:
> We would get an oops on RX on -ENOMEM by passing
> NULL to the hardware on ath_rx_buf_link(). The oops
> would look something like this:
> 
> ath_rx_tasklet
> ...
> RIP: ath_rx_buf_link
> 
> We correct this by handling the allocation for the next
> skb we will put in our RX tail directly on the ath_rx_tasklet()
> *prior* to sending up the last hardware processed
> skb. If we run out of memory this gauranteees we have
> skbs to work with while it simply drops new received
> frames.
> 
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>  drivers/net/wireless/ath9k/recv.c |   18 ++++++++++++++----
>  1 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath9k/recv.c b/drivers/net/wireless/ath9k/recv.c
> index 0941589..a4f92b2 100644
> --- a/drivers/net/wireless/ath9k/recv.c
> +++ b/drivers/net/wireless/ath9k/recv.c
> @@ -441,18 +441,16 @@ static void ath_rx_requeue(struct ath_softc *sc, struct sk_buff *skb)
>   */
>  static int ath_rx_indicate(struct ath_softc *sc,
>  			   struct sk_buff *skb,
> +			   struct sk_buff *nskb,
>  			   struct ath_recv_status *status,
>  			   u16 keyix)
>  {
>  	struct ath_buf *bf = ATH_RX_CONTEXT(skb)->ctx_rxbuf;
> -	struct sk_buff *nskb;
>  	int type;
>  
>  	/* indicate frame to the stack, which will free the old skb. */
>  	type = ath__rx_indicate(sc, skb, status, keyix);
>  
> -	/* allocate a new skb and queue it to for H/W processing */
> -	nskb = ath_rxbuf_alloc(sc, sc->sc_rxbufsize);
>  	if (nskb != NULL) {
>  		bf->bf_mpdu = nskb;
>  		bf->bf_buf_addr = ath_skb_map_single(sc,
> @@ -741,6 +739,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
>  	struct ath_desc *ds;
>  	struct ieee80211_hdr *hdr;
>  	struct sk_buff *skb = NULL;
> +	struct sk_buff *nskb = NULL;
>  	struct ath_recv_status rx_status;
>  	struct ath_hal *ah = sc->sc_ah;
>  	int type, rx_processed = 0;
> @@ -963,6 +962,17 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
>  		 */
>  		if (sc->sc_rxbufsize < ds->ds_rxstat.rs_datalen)
>  			goto rx_next;
> +
> +		/* allocate a new skb and queue it to for H/W processing */
> +		nskb = ath_rxbuf_alloc(sc, sc->sc_rxbufsize);
> +
> +		/* Diregard current RX'd frame and reuse the old skb */
> +		if (!nskb) {
> +			list_move_tail(&bf->list, &sc->sc_rxbuf);
> +			ath_rx_buf_link(sc, bf);
> +			goto rx_next;
> +		}
> +
>  		/*
>  		 * Sync and unmap the frame.  At this point we're
>  		 * committed to passing the sk_buff somewhere so
> @@ -1052,7 +1062,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
>  
>  		/* Pass frames up to the stack. */
>  
> -		type = ath_rx_indicate(sc, skb,
> +		type = ath_rx_indicate(sc, skb, nskb,
>  			&rx_status, ds->ds_rxstat.rs_keyix);
>  
>  		/*
> -- 
> 1.5.6.rc2.15.g457bb.dirty
> 
> _______________________________________________
> stable mailing list
> stable@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/stable

Re: [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Luis R. Rodriguez]

On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
> I don't see this patch upstream in Linus's tree.  Am I just missing it
> and if so, do you know the git commit id?

Nope sorry, John has yet to send his pending-fixes branch to davem and
so forth, which would contain it AFAICT. Please correct me if I'm
wrong John.

  Luis

Re: [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[John W. Linville]

On Tue, Dec 02, 2008 at 04:20:32PM -0800, Luis R. Rodriguez wrote:
> On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
> > I don't see this patch upstream in Linus's tree.  Am I just missing it
> > and if so, do you know the git commit id?
> 
> Nope sorry, John has yet to send his pending-fixes branch to davem and
> so forth, which would contain it AFAICT. Please correct me if I'm
> wrong John.

It has been sent, and Dave sent his pull request to Linus today
(or maybe yesterday).  I'll try to dig-up the commit IDs tomorrow.

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: [ath9k-devel] [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Luis R. Rodriguez]

On Tue, Dec 2, 2008 at 4:24 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, Dec 02, 2008 at 04:20:32PM -0800, Luis R. Rodriguez wrote:
>> On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
>> > I don't see this patch upstream in Linus's tree.  Am I just missing it
>> > and if so, do you know the git commit id?
>>
>> Nope sorry, John has yet to send his pending-fixes branch to davem and
>> so forth, which would contain it AFAICT. Please correct me if I'm
>> wrong John.
>
> It has been sent, and Dave sent his pull request to Linus today
> (or maybe yesterday).  I'll try to dig-up the commit IDs tomorrow.

Greg, I see two of these patches in 2.6.27-stable review patch but the
one in this subject was not applied, any specific reason or was it
just missed?

  Luis

Re: [ath9k-devel] [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Greg KH]

On Wed, Dec 03, 2008 at 12:19:22PM -0800, Luis R. Rodriguez wrote:
> On Tue, Dec 2, 2008 at 4:24 PM, John W. Linville <linville@tuxdriver.com> wrote:
> > On Tue, Dec 02, 2008 at 04:20:32PM -0800, Luis R. Rodriguez wrote:
> >> On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
> >> > I don't see this patch upstream in Linus's tree.  Am I just missing it
> >> > and if so, do you know the git commit id?
> >>
> >> Nope sorry, John has yet to send his pending-fixes branch to davem and
> >> so forth, which would contain it AFAICT. Please correct me if I'm
> >> wrong John.
> >
> > It has been sent, and Dave sent his pull request to Linus today
> > (or maybe yesterday).  I'll try to dig-up the commit IDs tomorrow.
> 
> Greg, I see two of these patches in 2.6.27-stable review patch but the
> one in this subject was not applied, any specific reason or was it
> just missed?

It was not applied because it was not yet in Linus's tree, which is a
requirement for it to go into the 2.6.27-stable tree.

thanks,

greg k-h

Re: [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[John W. Linville]

On Tue, Dec 02, 2008 at 07:24:04PM -0500, John W. Linville wrote:
> On Tue, Dec 02, 2008 at 04:20:32PM -0800, Luis R. Rodriguez wrote:
> > On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
> > > I don't see this patch upstream in Linus's tree.  Am I just missing it
> > > and if so, do you know the git commit id?
> > 
> > Nope sorry, John has yet to send his pending-fixes branch to davem and
> > so forth, which would contain it AFAICT. Please correct me if I'm
> > wrong John.
> 
> It has been sent, and Dave sent his pull request to Linus today
> (or maybe yesterday).  I'll try to dig-up the commit IDs tomorrow.

Hmmm...I seem to have sent this to -next instead.  Since it fixes an
Oops, I guess I can requeue for 2.6.28.

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: [ath9k-devel] [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Luis R. Rodriguez]

On Wed, Dec 3, 2008 at 1:22 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, Dec 02, 2008 at 07:24:04PM -0500, John W. Linville wrote:
>> On Tue, Dec 02, 2008 at 04:20:32PM -0800, Luis R. Rodriguez wrote:
>> > On Tue, Dec 2, 2008 at 4:12 PM, Greg KH <greg@kroah.com> wrote:
>> > > I don't see this patch upstream in Linus's tree.  Am I just missing it
>> > > and if so, do you know the git commit id?
>> >
>> > Nope sorry, John has yet to send his pending-fixes branch to davem and
>> > so forth, which would contain it AFAICT. Please correct me if I'm
>> > wrong John.
>>
>> It has been sent, and Dave sent his pull request to Linus today
>> (or maybe yesterday).  I'll try to dig-up the commit IDs tomorrow.
>
> Hmmm...I seem to have sent this to -next instead.  Since it fixes an
> Oops, I guess I can requeue for 2.6.28.

Pretty please :)

 Luis

Re: [ath9k-devel] [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Brian]

Luis,
I tried to respond to your comment in bug 12110 but do not have a id yet.

Does this patch fix this bug?


Here is my response


I have the same problem but with wireless testing on a 2.6.28-rc6-wl kernel.
I can run for hours if I do not use the wireless heavily.
But will crash within 10mins if I use NX.
(I have the NX parm turned on in the kernel)
I also get the same symptoms re a ping that will just stop/start,
directly before a crash. Also it starts to use my swap file. I NEVER use
swap normally.
Would you like me to apply the same patch and see if I can get some message?


Can I get a patch for 2.6.28-rc6-wl ?


Wireless Statistics
Sent :891261
TX Packets Dropped :21
Received :878290
RX Packets Dropped :1576
Errors :3531

Brian

Re: [ath9k-devel] [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully

[Luis R. Rodriguez]

On Wed, Dec 03, 2008 at 02:59:21PM -0800, Brian wrote:
> Luis,
> I tried to respond to your comment in bug 12110 but do not have a id yet.
> 
> Does this patch fix this bug?
> 
> 
> Here is my response
> 
> 
> I have the same problem but with wireless testing on a 2.6.28-rc6-wl kernel.
> I can run for hours if I do not use the wireless heavily.
> But will crash within 10mins if I use NX.
> (I have the NX parm turned on in the kernel)
> I also get the same symptoms re a ping that will just stop/start,
> directly before a crash. Also it starts to use my swap file. I NEVER use
> swap normally.
> Would you like me to apply the same patch and see if I can get some message?
> 
> 
> Can I get a patch for 2.6.28-rc6-wl ?

wireless-testing is now on 2.6.28-rc7, please do a git pull and
recompile and test that. It has some critical fixes for ath9k.

  Luis

2.6.28-rc7-wl

[Brian]

Luis,
> 
> wireless-testing is now on 2.6.28-rc7, please do a git pull and
> recompile and test that. It has some critical fixes for ath9k.
> 
Downloaded and installed, I had done a git-pull a few hours before and
it was not there:)

I set up my system with NX running and was waiting to be up 2hours.
Unfortunately it only made 1:50.
Still this is bundles better than the 10mins I was getting.

Some observations:

1) wpa_supplicant no longer chews up cpu/mem. It started and then did
nothing from then on. It used to be in the top 5 on htop.

2) I used to get a huge number of receive errors
 This is what I started with Errors :3708
 After an hour I had         Errors :3746

3) Towards the end the memory usage was creeping, slightly, up but no
where near the swap file.


As suggested by others I did have a console running, but I was
monitoring htop(to see if it started to use the swap) when it went.
So I have no further diagnostics.

When I did the compile it came up and asked me if I wanted the new
diagnostic facility for the driver and I just pressed enter.
Happy to go back and recompile(or can I turn it on).

If I turn it on do you have a methodology to use it?

Thanks for the great improvement,
Brian

Re: 2.6.28-rc7-wl

[Luis R. Rodriguez]

On Wed, Dec 03, 2008 at 11:59:07PM -0800, Brian wrote:
> 
> 
> Luis,
> >
> > wireless-testing is now on 2.6.28-rc7, please do a git pull and
> > recompile and test that. It has some critical fixes for ath9k.
> >
> Downloaded and installed, I had done a git-pull a few hours before and
> it was not there:)
> 
> I set up my system with NX running and was waiting to be up 2hours.
> Unfortunately it only made 1:50.

What do you mean Brian, did it crash? What happened?

  Luis

Re: 2.6.28-rc7-wl

[Luis R. Rodriguez]

On Thu, Dec 04, 2008 at 03:38:09PM -0800, Brian wrote:
> 
> 
> Luis,
> 
> >> So I think the driver could be fine, it could be application specific.
> >> Will also do a search of the NX site and see if they have any problems.
> >>
> >> Will let you know how I go.
> >
> > I see.. What is NX?
> http://www.nomachine.com/
> NX is really great and is easily the best remote control software.
> While I can get by with krdc I want to use NX if I can.
> 
> We run tests against ath9k over hours too and
> > I don't think we've seen this memory hog issue. But if your userspace
> > application is hogging up application your kernel shoulod not panic,
> > unless of course some -ENOMEM as part of your drivers is not being
> > handled correctly. But the patches merged recently actually handle this
> > for ath9k :) I at least have tested it with mem=200 and even using the
> > swiotlb.
> >
> Yes I saw that you had included the -ENOMEM fix, so I was very hopeful
> that the problem would go away.
> I must say the difference between rc6 and rc7 is really significant.
> Things are quicker and more stable for all the normal operations.
> I just do not see what is different about NX, I might try running
> wireshark on it. If you could fire up NX and it fails then at least we
> could say that it is not specific to my machine.
> I should also point out that when researching this problem on the web I
> found that hundreds of people were having the same freezing problem.
> 
> My krdc has been running for 30mins with no problems, but the memory is
> going up.
> 
> Back in a bit

So do some other test -- run bitorrent, or iperf. That should rule out
ath9k.

To test if its NX try testing it over a wired ethernet connection.

  Luis