Re: [PATCH] net: smc911x: convert pxa dma to dmaengine

[Guennadi Liakhovetski]

Hi,

On Sat, 20 Feb 2016, Hitoshi Mitake wrote:

> 
> Hi Robert,
> 
> At Sat, 06 Feb 2016 10:05:51 +0100,
> Robert Jarzmik wrote:
> > 
> > David Miller  writes:
> > 
> > > From: Robert Jarzmik 
> > > Date: Fri, 05 Feb 2016 22:44:56 +0100
> > >
> > >> Apart from Alberto who answered he cannot test it by lack of hardware, 
> > >> the
> > >> others didn't answer.
> > >> 
> > >> So how can I move forward ? Would you want me to amend the KConfig to 
> > >> add a "&&
> > >> !ARCH_PXA" on the "depend" line ?
> > >
> > > Please just keep pinging people to properly test this.
> > Okay, let's have another try.
> > 
> > Hi Guennadi, Hitoshi, Fabio,
> > 
> > Could any of you try this patch to ensure your board is not broken please ?
> > I've re-added the patch at the end of this mail for easier handling. 
> > Normally no
> > code path in non-PXA board is changed, so the test should be 
> > straightforward.
> > 
> > It's also available in : https://lkml.org/lkml/2015/11/30/768
> > 
> > You're the maintainers of the following boards using smc911x AFAIK:
> >  - sh2007: Guennadi and Hitoshi
> 
> (I noticed my previous mail was bounced, so sending it again)
> 
> Really sorry, currently I don't have the board :(
> Do you have a working board that can be used for testing, Guennadi?

Don't think I have anything, that I could use for testing with a 
reasonable effort.

Thanks
Guennadi

> 
> Thanks,
> Hitoshi
> 
> >  - armadillo5x0: Alberto
> >  - imx v6 and imx v7: Fabio
> > 
> > Cheers.
> > 
> > -- 
> > Robert
> > 
> > 
> > ---8<---
> > From: Robert Jarzmik 
> > Subject: [PATCH] net: smc911x: convert pxa dma to dmaengine
> > To: "David S. Miller" 
> > Cc: netdev@vger.kernel.org, linux-ker...@vger.kernel.org, Robert Jarzmik 
> > 
> > Date: Mon, 30 Nov 2015 22:40:28 +0100 (9 weeks, 4 days, 11 hours ago)
> > Message-Id: <1448919628-13273-1-git-send-email-robert.jarz...@free.fr>
> > X-Mailer: git-send-email 2.1.4
> > 
> > Convert the dma transfers to be dmaengine based, now pxa has a dmaengine
> > slave driver. This makes this driver a bit more PXA agnostic.
> > 
> > The driver was only compile tested. The risk is quite small as no
> > current PXA platform I'm aware of is using smc911x driver.
> > 
> > Signed-off-by: Robert Jarzmik 
> > ---
> >  drivers/net/ethernet/smsc/smc911x.c | 85 
> > -
> >  drivers/net/ethernet/smsc/smc911x.h | 63 ---
> >  2 files changed, 82 insertions(+), 66 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/smsc/smc911x.c 
> > b/drivers/net/ethernet/smsc/smc911x.c
> > index bd64eb982e52..3f5711061432 100644
> > --- a/drivers/net/ethernet/smsc/smc911x.c
> > +++ b/drivers/net/ethernet/smsc/smc911x.c
> > @@ -73,6 +73,9 @@ static const char version[] =
> >  #include 
> >  #include 
> >  
> > +#include 
> > +#include 
> > +
> >  #include 
> >  
> >  #include "smc911x.h"
> > @@ -1174,18 +1177,16 @@ static irqreturn_t smc911x_interrupt(int irq, void 
> > *dev_id)
> >  
> >  #ifdef SMC_USE_DMA
> >  static void
> > -smc911x_tx_dma_irq(int dma, void *data)
> > +smc911x_tx_dma_irq(void *data)
> >  {
> > -   struct net_device *dev = (struct net_device *)data;
> > -   struct smc911x_local *lp = netdev_priv(dev);
> > +   struct smc911x_local *lp = data;
> > +   struct net_device *dev = lp->netdev;
> > struct sk_buff *skb = lp->current_tx_skb;
> > unsigned long flags;
> >  
> > DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
> >  
> > DBG(SMC_DEBUG_TX | SMC_DEBUG_DMA, dev, "TX DMA irq handler\n");
> > -   /* Clear the DMA interrupt sources */
> > -   SMC_DMA_ACK_IRQ(dev, dma);
> > BUG_ON(skb == NULL);
> > dma_unmap_single(NULL, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
> > dev->trans_start = jiffies;
> > @@ -1208,18 +1209,16 @@ smc911x_tx_dma_irq(int dma, void *data)
> > "TX DMA irq completed\n");
> >  }
> >  static void
> > -smc911x_rx_dma_irq(int dma, void *data)
> > +smc911x_rx_dma_irq(void *data)
> >  {
> > -   struct net_device *dev = (struct net_device *)data;
> > -   struct smc911x_local *lp = netdev_priv(dev);
> > +   struct smc911x_local *lp = data;
> > +   struct net_device *dev = lp->netdev;
> > struct sk_buff *skb = lp->current_rx_skb;
> > unsigned long flags;
> > unsigned int pkts;
> >  
> > DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
> > DBG(SMC_DEBUG_RX | SMC_DEBUG_DMA, dev, "RX DMA irq handler\n");
> > -   /* Clear the DMA interrupt sources */
> > -   SMC_DMA_ACK_IRQ(dev, dma);
> > dma_unmap_single(NULL, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
> > BUG_ON(skb == NULL);
> > lp->current_rx_skb = NULL;
> > @@ -1792,6 +1791,9 @@ static int smc911x_probe(struct net_device *dev)
> > unsigned int val, chip_id, revision;
> > const char *version_string;
> > unsigned long irq_flags;
> > +   struct dma_slave_config config;
> > +   

IPSec in tunnel mode on ARM not working

[Guennadi Liakhovetski]

Hi

Got two setups: with an ARM-based router and with a PC, connecting to 
a remote site using IPSec in tunnel mode over ppp. Setup is identical, 
PC works, ARM router doesn't. Kernel 2.6.23.1.

The setup looks like

PCa --- routerA ==== routerB --- PCb

where routerA is our problematic router. We issue ping from PCa to PCb, we 
see ICMP packet coming to PCb, being answered, coming back to routerA, and 
there it doesn't get through to PCa. We see it with iptables LOG coming 
into the INPUT chain, and that's about it.

Does anyone haveexperiences with IPSec in tunnel mode on ARM? Or does 
anyone have debugging ideas? Is there a description somewhere how an 
incoming packet traverses the networking stack in such a setup?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

socket tx_queue grows and communication stops

[Guennadi Liakhovetski]

Hi all,

writing to both netdev and IrDA since I don't know where the problem 
occurs. More likely in IrDA, but maybe someone from netdev will have 
debugging ideas.

System: PXA270 ARM CPU

Kernel: 2.6.20.1-rt8 (realtime preemption)

Test case: small UDP-packet request-response test over ppp on irnet.

Problem: after some time the tx_queue value in /proc/net/udp for this 
socket on the active (request) side becomes large and the communication 
stops. Whereas background (ppp) IrDA communication runs further, new 
connections are possible. Moreover, the frozen communication can be 
thawed, e.g., if I dump task states per sysrq-t IrDA first reports no 
activity, but the communication afterwards runs further. Without such a 
kick it hangs indefinitely (days). I think, also just starting a parallel 
ping thaws the socket too. It is hard to reproduce - occurs only after 
several hours of testing (once a day).

So, does anyone have an idea what the reason can be or at least how can I 
debug it? Does it look like a leak again? Nothing suspicious in slabinfo. 
The number in tx_queue doesn't grow gradually - most of the time it's 0.

Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ppp_generic.c recursive spinlock_bh(pch-downl)

[Guennadi Liakhovetski]

Hi Paul,

This has been discussed on these lists since some time already, but as we 
don't seem to come to a proper fix, I decided to summarize our problem 
once again.

A short summary from the ppp PoV:

ppp_push()
{
spin_lock_bh(pch-downl);
pch-chan-ops-start_xmit(pch-chan, skb)
{
...
ppp_output_wakeup()
{
ppp_channel_push()
{
spin_lock_bh(pch-downl);
BANG!...

This happens with IrNET. So, the question is, is it legitimate to call 
ppp_channel_push() from the .start_xmit() method? How do other ppp drivers 
do it? Looks like, for examplke, ppp_async checks explicitly for 
recursion, synctty does a try_spinlock_bh()... Is it just a bug in IrNET 
and one just cannot do this, or is there a simple fix for this?

Samuel's suggestion is to offload the call to ppp_output_wakeup() to the 
keventd workqueue, but we haven't been able to make this work properly so 
far.

I have a dirty workaround, whereby I explicitly verify recursion in 
ppp_channel_push(). This works, but it doesn't seem to be a good solution.

Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [irda-users] [BUG] 2.6.20.1-rt8 irnet + pppd recursive spinlock...

[Guennadi Liakhovetski]

On Tue, 1 May 2007, Samuel Ortiz wrote:
 But I will definitely spend some time this week running my IrDA stack 
 with this patch applied. I didn't bother to do that earlier as you first 
 reported some oops with this patch applied.

I think, what I reported was not an Oops, but the race that we're also 
fixing ATM - the one in the state machine. So, unrelated.

 On Mon, Apr 30, 2007 at 03:24:05PM +0200, Guennadi Liakhovetski wrote:

  in irttp_dup() (remember spinlock_init()?:-)), otherwise it oopses.
 good catch, again...Yes, I do remember the irttp_dup bug ;-)

I've put a tsap_init() function that does those common initialisation 
calls, so we have a smaller chance of forgetting the dup() path next 
time...

  I will be 
  testing it too, but don't know how much longer and how intensively. Do you 
  think we might get some new problems with this new context?
 It seems quite safe to me. But more importantly, I thing we do want to call
 the flow indication routine asynchronously in that specific case. 
 There is one thing that this patch is missing though: we should probably
 clean the worqueue right before we destroy the TTP instance. The work routine
 checks for NULL pointer, but still...

I thought about it too, but the only thing you can do is 
flush_scheduled_work(), is this what you mean?

The test with your patch stopped inside a ftp transfer - the ftp client 
was doing a get, and it stopped half-way through. On the client side only 
the control tcp connection was still open, on the client both ftp-server 
forked children were dead, no connection open. No errors in logs. Weird. 
With my ugly patch it ran the weekend through.

...and it just stopped again - this time after just 13 minutes.

A couple of comments to your patch:

   +static void irttp_flow_restart(struct work_struct *work)
   +{
   + struct tsap_cb * self =
   + container_of(work, struct tsap_cb, irnet_flow_work);
   +
   + if (self == NULL)
   + return;

self will not be NULL here. How about

+   IRDA_ASSERT(work != NULL, return;);
+   IRDA_ASSERT(self-magic == TTP_TSAP_MAGIC, return;);

   - /* Check if we can accept more frames from client.
   -  * We don't want to wait until the todo timer to do that, and we
   -  * can't use tasklets (grr...), so we are obliged to give control
   -  * to client. That's ok, this test will be true not too often
   -  * (max once per LAP window) and we are called from places
   -  * where we can spend a bit of time doing stuff. - Jean II */
 if ((self-tx_sdu_busy) 
 (skb_queue_len(self-tx_queue)  TTP_TX_LOW_THRESHOLD) 
 (!self-close_pend))

Is this test still needed here? You do it again in the work-function, and 
the conditions can change, so, should we schedule_work unconditionally 
here?

Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [irda-users] [BUG] 2.6.20.1-rt8 irnet + pppd recursive spinlock...

[Guennadi Liakhovetski]

On Tue, 10 Apr 2007, Samuel Ortiz wrote:

 Hi Guennadi,
 
 The patch below schedules irnet_flow_indication() asynchronously. Could
 you please give it a try (it builds, but I couldn't test it...) ? :

Ok, your patch (still below) works too (now that I fixed that state 
machine race, btw, we still have to decide on the final form how it goes 
in the mainline) __after__ you also add the line

+   INIT_WORK(new-irnet_flow_work, irttp_flow_restart);

in irttp_dup() (remember spinlock_init()?:-)), otherwise it oopses. 
Generally, I like your patch better than mine to ppp_generic.c, where I 
explicitly check if a recursion is occurring. Still, I am a bit concerned 
about introducing yet another execution context into irda... We have seen 
a couple of locking issues there already in the last 2-3 months especially 
under rt-preempt... Would you be able to run some tests too? I will be 
testing it too, but don't know how much longer and how intensively. Do you 
think we might get some new problems with this new context?

Thanks
Guennadi

 
 diff --git a/include/net/irda/irttp.h b/include/net/irda/irttp.h
 index a899e58..941f0f1 100644
 --- a/include/net/irda/irttp.h
 +++ b/include/net/irda/irttp.h
 @@ -128,6 +128,7 @@ struct tsap_cb {
  
   struct net_device_stats stats;
   struct timer_list todo_timer; 
 + struct work_struct irnet_flow_work;   /* irttp asynchronous flow 
 restart */
  
   __u32 max_seg_size; /* Max data that fit into an IrLAP frame */
   __u8  max_header_size;
 diff --git a/net/irda/irnet/irnet.h b/net/irda/irnet/irnet.h
 diff --git a/net/irda/irttp.c b/net/irda/irttp.c
 index 7069e4a..a0d0f26 100644
 --- a/net/irda/irttp.c
 +++ b/net/irda/irttp.c
 @@ -367,6 +367,29 @@ static int irttp_param_max_sdu_size(void *instance, 
 irda_param_t *param,
  /*** CLIENT CALLS ***/
  /** LMP CALLBACKS **/
  /* Everything is happily mixed up. Waiting for next clean up - Jean II */
 +static void irttp_flow_restart(struct work_struct *work)
 +{
 + struct tsap_cb * self =
 + container_of(work, struct tsap_cb, irnet_flow_work);
 +
 + if (self == NULL)
 + return;
 +
 + /* Check if we can accept more frames from client. */
 + if ((self-tx_sdu_busy) 
 + (skb_queue_len(self-tx_queue)  TTP_TX_LOW_THRESHOLD) 
 + (!self-close_pend)) {
 + if (self-notify.flow_indication)
 + self-notify.flow_indication(self-notify.instance,
 +  self, FLOW_START);
 +
 + /* self-tx_sdu_busy is the state of the client.
 +  * We don't really have a race here, but it's always safer
 +  * to update our state after the client - Jean II */
 + self-tx_sdu_busy = FALSE;
 + }
 +}
 +
  
  /*
   * Function irttp_open_tsap (stsap, notify)
 @@ -402,6 +425,8 @@ struct tsap_cb *irttp_open_tsap(__u8 stsap_sel, int 
 credit, notify_t *notify)
   self-todo_timer.data = (unsigned long) self;
   self-todo_timer.function = irttp_todo_expired;
  
 + INIT_WORK(self-irnet_flow_work, irttp_flow_restart);
 +
   /* Initialize callbacks for IrLMP to use */
   irda_notify_init(ttp_notify);
   ttp_notify.connect_confirm = irttp_connect_confirm;
 @@ -761,25 +786,10 @@ static void irttp_run_tx_queue(struct tsap_cb *self)
   self-stats.tx_packets++;
   }
  
 - /* Check if we can accept more frames from client.
 -  * We don't want to wait until the todo timer to do that, and we
 -  * can't use tasklets (grr...), so we are obliged to give control
 -  * to client. That's ok, this test will be true not too often
 -  * (max once per LAP window) and we are called from places
 -  * where we can spend a bit of time doing stuff. - Jean II */
   if ((self-tx_sdu_busy) 
   (skb_queue_len(self-tx_queue)  TTP_TX_LOW_THRESHOLD) 
   (!self-close_pend))
 - {
 - if (self-notify.flow_indication)
 - self-notify.flow_indication(self-notify.instance,
 -  self, FLOW_START);
 -
 - /* self-tx_sdu_busy is the state of the client.
 -  * We don't really have a race here, but it's always safer
 -  * to update our state after the client - Jean II */
 - self-tx_sdu_busy = FALSE;
 - }
 + schedule_work(self-irnet_flow_work);
  
   /* Reset lock */
   self-tx_queue_lock = 0;
 
 
 

-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [irda-users] [BUG] 2.6.20.1-rt8 irnet + pppd recursive spinlock...

[Guennadi Liakhovetski]

On Tue, 10 Apr 2007, Samuel Ortiz wrote:

 The patch below schedules irnet_flow_indication() asynchronously. Could
 you please give it a try (it builds, but I couldn't test it...) ? :

I'm afraid, your patch makes it worse - with my patch to ppp_generic it 
worked 5 hours before Ir stopped, remaining at 4mbaud, and only discovery 
timer was expiring periodically without actually doing anything; with your 
patch the same happens in about 5 minutes.

I'll double-verify it, and then will try the same work-queue approach, but 
from ppp_generic, rather than from irttp, combining our 2 patches.

Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[BUG] 2.6.20.1-rt8 irnet + pppd recursive spinlock...

[Guennadi Liakhovetski]

Hi all

As I came this morning to check the IrNET / PPP test, I started yesterday, 
the device was dead and OOM messages were scrolling up the terminal. I 
captured task trace, and the ftp process seems to have been the original 
culprit. Below is the backtrace. Which looks like a recursive spinlock, 
since, I assume, it is this BUG() that has triggered:

BUG_ON(rt_mutex_owner(lock) == current);

and ppp is indeed entered recursively in the trace. I'll look if I can 
find the reason and a solution, but would also be greatful for any hints.

Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

ftp   D [c3c9e460] C01E5838 0 18445  1 20756 14588 
(L-TLB)
[c01e5420] (__schedule+0x0/0x7e8) from [c01e5cfc] (schedule+0x54/0x124)
[c01e5ca8] (schedule+0x0/0x124) from [c017e69c] (lock_sock_nested+0x94/0xd0)
 r5 = C329F06C  r4 = C14B9780 
[c017e608] (lock_sock_nested+0x0/0xd0) from [c017b878] 
(sock_fasync+0x40/0x154)
 r7 = C329F040  r6 = C2238A5C  r5 = C0AD8B60  r4 = C0AD8B60
[c017b838] (sock_fasync+0x0/0x154) from [c017b9b0] (sock_close+0x24/0x44)
[c017b98c] (sock_close+0x0/0x44) from [c008dbbc] (__fput+0x194/0x1c8)
 r4 = 0008 
[c008da28] (__fput+0x0/0x1c8) from [c008dc28] (fput+0x38/0x3c)
 r8 =   r7 = C3251380  r6 =   r5 = C3251380
 r4 = C0AD8B60 
[c008dbf0] (fput+0x0/0x3c) from [c008b860] (filp_close+0x5c/0x88)
[c008b804] (filp_close+0x0/0x88) from [c003f108] 
(put_files_struct+0x9c/0xdc)
 r6 = C3251388  r5 = 0007  r4 = 0001 
[c003f06c] (put_files_struct+0x0/0xdc) from [c003fa14] (do_exit+0x168/0x8b0)
[c003f8ac] (do_exit+0x0/0x8b0) from [c002411c] (die+0x29c/0x2e8)
[c0023e80] (die+0x0/0x2e8) from [c0025b3c] (__do_kernel_fault+0x70/0x80)
[c0025acc] (__do_kernel_fault+0x0/0x80) from [c0025cd0] 
(do_page_fault+0x60/0x214)
 r7 = C1B3B8C0  r6 = C0264418  r5 = C3C9E460  r4 = C02643A8
[c0025c70] (do_page_fault+0x0/0x214) from [c0025fa0] 
(do_DataAbort+0x3c/0xa4)
[c0025f64] (do_DataAbort+0x0/0xa4) from [c001fa60] (__dabt_svc+0x40/0x60)
 r8 = 0001  r7 = A013  r6 = C3A43780  r5 = C14B99E0
 r4 =  
[c0023cd0] (__bug+0x0/0x2c) from [c01e753c] 
(rt_spin_lock_slowlock+0x1c8/0x1f8)
[c01e7374] (rt_spin_lock_slowlock+0x0/0x1f8) from [c01e7894] 
(__lock_text_start+0x44/0x48)
[c01e7850] (__lock_text_start+0x0/0x48) from [bf12b23c] 
(ppp_channel_push+0x1c/0xc8 [ppp_generic])
[bf12b220] (ppp_channel_push+0x0/0xc8 [ppp_generic]) from [bf12bf98] 
(ppp_output_wakeup+0x18/0x1c [ppp_generic])
 r7 = C38F42BC  r6 = C38F4200  r5 = C38F4200  r4 = 
[bf12bf80] (ppp_output_wakeup+0x0/0x1c [ppp_generic]) from [bf132c98] 
(irnet_flow_indication+0x38/0x3c [irnet])
[bf132c60] (irnet_flow_indication+0x0/0x3c [irnet]) from [bf104e4c] 
(irttp_run_tx_queue+0x1c0/0x1d4 [irda])
[bf104c8c] (irttp_run_tx_queue+0x0/0x1d4 [irda]) from [bf104f88] 
(irttp_data_request+0x128/0x4f8 [irda])
 r8 = BF121560  r7 = 0002  r6 = C38F4200  r5 = C21418B8
 r4 = C21418B8 
[bf104e60] (irttp_data_request+0x0/0x4f8 [irda]) from [bf1321bc] 
(ppp_irnet_send+0x134/0x238 [irnet])
[bf132088] (ppp_irnet_send+0x0/0x238 [irnet]) from [bf12a600] 
(ppp_push+0x80/0xb8 [ppp_generic])
 r7 = C3A436E0  r6 =   r5 = C21418B8  r4 = C1489600
[bf12a580] (ppp_push+0x0/0xb8 [ppp_generic]) from [bf12a8d8] 
(ppp_xmit_process+0x34/0x50c [ppp_generic])
 r7 = 0021  r6 = C21418B8  r5 = C1489600  r4 = 
[bf12a8a4] (ppp_xmit_process+0x0/0x50c [ppp_generic]) from [bf12aed8] 
(ppp_start_xmit+0x128/0x254 [ppp_generic])
[bf12adb0] (ppp_start_xmit+0x0/0x254 [ppp_generic]) from [c0186fa4] 
(dev_hard_start_xmit+0x170/0x268)
[c0186e34] (dev_hard_start_xmit+0x0/0x268) from [c01979b8] 
(__qdisc_run+0x60/0x270)
 r8 = C1BBC914  r7 = C21418B8  r6 =   r5 = C21418B8
 r4 = C1BBC800 
[c0197958] (__qdisc_run+0x0/0x270) from [c0187250] 
(dev_queue_xmit+0x1b4/0x25c)
[c018709c] (dev_queue_xmit+0x0/0x25c) from [c01a5f08] 
(ip_output+0x150/0x254)
 r7 = C329F040  r6 = C21418B8  r5 =   r4 = C0D02EE0
[c01a5db8] (ip_output+0x0/0x254) from [c01a52ac] (ip_queue_xmit+0x360/0x4b4)
[c01a4f4c] (ip_queue_xmit+0x0/0x4b4) from [c01b8424] 
(tcp_transmit_skb+0x5ec/0x8c0)
[c01b7e38] (tcp_transmit_skb+0x0/0x8c0) from [c01b9ff4] 
(tcp_push_one+0xb4/0x13c)
[c01b9f40] (tcp_push_one+0x0/0x13c) from [c01ad640] 
(tcp_sendmsg+0x9a8/0xcdc)
 r8 = C2EF30A0  r7 = 05A8  r6 =   r5 = C329F040
 r4 = C2141820 
[c01acc98] (tcp_sendmsg+0x0/0xcdc) from [c01ccc94] (inet_sendmsg+0x60/0x64)
[c01ccc34] (inet_sendmsg+0x0/0x64) from [c017b49c] 
(sock_aio_write+0x100/0x104)
 r7 = C14B9E94  r6 = 0001  r5 = C14B9E9C  r4 = C2238A20
[c017b3a0] (sock_aio_write+0x4/0x104) from [c008c360] 
(do_sync_write+0xc8/0x114)
 r8 = C14B9E94  r7 = C14B9EE4  r6 = C14B9E9C  r5 = 
 r4 =  
[c008c298] (do_sync_write+0x0/0x114) from [c008c524] (vfs_write+0x178/0x18c)
[c008c3ac] (vfs_write+0x0/0x18c) from [c008c600] (sys_write+0x4c/0x7c)
[c008c5b4

Re: [BUG] 2.6.20.1-rt8 irnet + pppd recursive spinlock...

[Guennadi Liakhovetski]

Ok, a simple analysis reveals the recursive spinlock:

On Thu, 5 Apr 2007, Guennadi Liakhovetski wrote:

 [bf12b220] (ppp_channel_push+0x0/0xc8 [ppp_generic]) from [bf12bf98] 
 (ppp_output_wakeup+0x18/0x1c [ppp_generic])
===
  r7 = C38F42BC  r6 = C38F4200  r5 = C38F4200  r4 = 

===spin_lock_bh(pch-downl);

 [bf12bf80] (ppp_output_wakeup+0x0/0x1c [ppp_generic]) from [bf132c98] 
 (irnet_flow_indication+0x38/0x3c [irnet])
 [bf132c60] (irnet_flow_indication+0x0/0x3c [irnet]) from [bf104e4c] 
 (irttp_run_tx_queue+0x1c0/0x1d4 [irda])
 [bf104c8c] (irttp_run_tx_queue+0x0/0x1d4 [irda]) from [bf104f88] 
 (irttp_data_request+0x128/0x4f8 [irda])
  r8 = BF121560  r7 = 0002  r6 = C38F4200  r5 = C21418B8
  r4 = C21418B8 
 [bf104e60] (irttp_data_request+0x0/0x4f8 [irda]) from [bf1321bc] 
 (ppp_irnet_send+0x134/0x238 [irnet])
 [bf132088] (ppp_irnet_send+0x0/0x238 [irnet]) from [bf12a600] 
 (ppp_push+0x80/0xb8 [ppp_generic])
  r7 = C3A436E0  r6 =   r5 = C21418B8  r4 = C1489600
 [bf12a580] (ppp_push+0x0/0xb8 [ppp_generic]) from [bf12a8d8] 
 (ppp_xmit_process+0x34/0x50c [ppp_generic])
===
  r7 = 0021  r6 = C21418B8  r5 = C1489600  r4 = 

===spin_lock_bh(pch-downl);

 [bf12a8a4] (ppp_xmit_process+0x0/0x50c [ppp_generic]) from [bf12aed8] 
 (ppp_start_xmit+0x128/0x254 [ppp_generic])
 [bf12adb0] (ppp_start_xmit+0x0/0x254 [ppp_generic]) from [c0186fa4] 
 (dev_hard_start_xmit+0x170/0x268)
 [c0186e34] (dev_hard_start_xmit+0x0/0x268) from [c01979b8] 
 (__qdisc_run+0x60/0x270)
  r8 = C1BBC914  r7 = C21418B8  r6 =   r5 = C21418B8
  r4 = C1BBC800 
 [c0197958] (__qdisc_run+0x0/0x270) from [c0187250] 
 (dev_queue_xmit+0x1b4/0x25c)

Now, does anyone have an idea how best to fix it?

1. Should re-entrance in ppp_channel_push() be prevented, and if yes - at 
which level? Or

2. Should re-entrance be allowed and only recursive spin_lock_bh() 
avoided?

Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] 2.6.20.1-rt8 irnet + pppd recursive spinlock...

[Guennadi Liakhovetski]

On Thu, 5 Apr 2007, Guennadi Liakhovetski wrote:

 Ok, a simple analysis reveals the recursive spinlock:
 
 On Thu, 5 Apr 2007, Guennadi Liakhovetski wrote:
 
  [bf12b220] (ppp_channel_push+0x0/0xc8 [ppp_generic]) from [bf12bf98] 
  (ppp_output_wakeup+0x18/0x1c [ppp_generic])
 ===  
   r7 = C38F42BC  r6 = C38F4200  r5 = C38F4200  r4 = 
 
 ===  spin_lock_bh(pch-downl);
 
  [bf12bf80] (ppp_output_wakeup+0x0/0x1c [ppp_generic]) from [bf132c98] 
  (irnet_flow_indication+0x38/0x3c [irnet])
  [bf132c60] (irnet_flow_indication+0x0/0x3c [irnet]) from [bf104e4c] 
  (irttp_run_tx_queue+0x1c0/0x1d4 [irda])
  [bf104c8c] (irttp_run_tx_queue+0x0/0x1d4 [irda]) from [bf104f88] 
  (irttp_data_request+0x128/0x4f8 [irda])
   r8 = BF121560  r7 = 0002  r6 = C38F4200  r5 = C21418B8
   r4 = C21418B8 
  [bf104e60] (irttp_data_request+0x0/0x4f8 [irda]) from [bf1321bc] 
  (ppp_irnet_send+0x134/0x238 [irnet])
  [bf132088] (ppp_irnet_send+0x0/0x238 [irnet]) from [bf12a600] 
  (ppp_push+0x80/0xb8 [ppp_generic])
   r7 = C3A436E0  r6 =   r5 = C21418B8  r4 = C1489600
  [bf12a580] (ppp_push+0x0/0xb8 [ppp_generic]) from [bf12a8d8] 
  (ppp_xmit_process+0x34/0x50c [ppp_generic])
 ===  
   r7 = 0021  r6 = C21418B8  r5 = C1489600  r4 = 
 
 ===  spin_lock_bh(pch-downl);

For comments, below is a patch I am testing ATM. It doesn't look right nor 
very pretty, but I couldn't come up with anything better. I do sign-off 
for it in case nothing better is proposed and it is decided to push it for 
2.6.21.

Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Fix recursion with PPP over IrNET.

Signed-off-by: G. Liakhovetski [EMAIL PROTECTED]

diff -u -r1.1.1.19.4.1 ppp_generic.c
--- a/drivers/net/ppp_generic.c 26 Mar 2007 09:21:32 -  1.1.1.19.4.1
+++ b/drivers/net/ppp_generic.c 5 Apr 2007 15:01:45 -
@@ -155,6 +155,7 @@
struct ppp_channel *chan;   /* public channel data structure */
struct rw_semaphore chan_sem;   /* protects `chan' during chan ioctl */
spinlock_t  downl;  /* protects `chan', file.xq dequeue */
+   struct task_struct *locker; /* owner of the downl lock */
struct ppp  *ppp;   /* ppp unit we're connected to */
struct list_head clist; /* link in list of channels per unit */
rwlock_tupl;/* protects `ppp' */
@@ -1214,8 +1215,11 @@
 
spin_lock_bh(pch-downl);
if (pch-chan) {
+   /* Prevent recursive locking */
+   pch-locker = current;
if (pch-chan-ops-start_xmit(pch-chan, skb))
ppp-xmit_pending = NULL;
+   pch-locker = NULL;
} else {
/* channel got unregistered */
kfree_skb(skb);
@@ -1435,6 +1439,9 @@
struct sk_buff *skb;
struct ppp *ppp;
 
+   if (pch-locker == current)
+   return;
+
spin_lock_bh(pch-downl);
if (pch-chan != 0) {
while (!skb_queue_empty(pch-file.xq)) {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [git patches] net driver fixes

[Guennadi Liakhovetski]

On Thu, 29 Mar 2007, Jeff Garzik wrote:

 Guennadi Liakhovetski wrote:
 Jeff, might be worth getting the sk_buff leak fix in ppp from 
 http://www.spinics.net/lists/netdev/msg27706.html in 2.6.21 too?
 
 Don't know how important it is for stable. It was present in 2.6.18 too.

 Can you resend the patch to me, please?

 Easier for the system to apply than the URL...

Sure, attached below. I think, though, this patch is already in someone's 
tree. Andrew has applied it to -mm under the name

ppp-dont-leak-an-sk_buff-on-interface-destruction.patch

but then dropped with the reasoning This patch was dropped because it was 
merged into mainline or a subsystem tree. So, maybe it is now in Samuel's 
IrDA tree. Samuel?So, maybe all you have to do is to pull it from his 
tree.

Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Don't leak an sk_buff on interface destruction.

Signed-off-by: G. Liakhovetski [EMAIL PROTECTED]

--- a/drivers/net/ppp_generic.c 2007-03-23 13:04:04.0 +0100
+++ b/drivers/net/ppp_generic.c 2007-03-23 13:05:29.0 +0100
@@ -2544,6 +2544,9 @@
ppp-active_filter = NULL;
  #endif /* CONFIG_PPP_FILTER */

+   if (ppp-xmit_pending)
+   kfree_skb(ppp-xmit_pending);
+
kfree(ppp);
  }

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [irda-users] [2.6.20-rt8] Neighbour table overflow.

[Guennadi Liakhovetski]

On Sat, 24 Mar 2007, Samuel Ortiz wrote:


On Fri, Mar 23, 2007 at 01:14:43PM +0100, Guennadi Liakhovetski wrote:


Below is a patch that fixes ONE
sk_buff leak (maintainer added to cc: hi, Paul:-)). Still investigating if
there are more there.

Are you still seeing the skb cache growing with your fix ?


No, running stable so far.

Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [git patches] net driver fixes

[Guennadi Liakhovetski]

Jeff, might be worth getting the sk_buff leak fix in ppp from 
http://www.spinics.net/lists/netdev/msg27706.html in 2.6.21 too?

Don't know how important it is for stable. It was present in 2.6.18 too.

Thanks
Guennadi
---
Guennadi Liakhovetski
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [irda-users] [2.6.20-rt8] Neighbour table overflow.

[Guennadi Liakhovetski]

On Wed, 21 Mar 2007, Guennadi Liakhovetski wrote:


On Wed, 21 Mar 2007, Samuel Ortiz wrote:


I'm quite sure the leak is in the IrDA code rather than in the ppp or
ipv4 one, hence the need for full irda debug...


Well, looks like you were wrong, Samuel. Below is a patch that fixes ONE 
sk_buff leak (maintainer added to cc: hi, Paul:-)). Still investigating if 
there are more there.


Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Don't leak an sk_buff on interface destruction.

Signed-off-by: G. Liakhovetski [EMAIL PROTECTED]

--- a/drivers/net/ppp_generic.c 2007-03-23 13:04:04.0 +0100
+++ b/drivers/net/ppp_generic.c 2007-03-23 13:05:29.0 +0100
@@ -2544,6 +2544,9 @@
ppp-active_filter = NULL;
 #endif /* CONFIG_PPP_FILTER */

+   if (ppp-xmit_pending)
+   kfree_skb(ppp-xmit_pending);
+
kfree(ppp);
 }

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [irda-users] [2.6.20-rt8] Neighbour table overflow.

[Guennadi Liakhovetski]

(Short recap for newly added to cc: netdev: I'm seeing an skb leak in 
2.6.20 during an IrDA IrNET+ppp UDP test with periodic connection 
disruptions)


On Wed, 21 Mar 2007, Guennadi Liakhovetski wrote:


On Tue, 20 Mar 2007, Guennadi Liakhovetski wrote:

Ok, looks like all leaked skbuffs come from ip_append_data(), like this:

(sock_alloc_send_skb+0x2c8/0x2e4)
(ip_append_data+0x7fc/0xa80)
(udp_sendmsg+0x248/0x68c)
(inet_sendmsg+0x60/0x64)
(sock_sendmsg+0xb4/0xe4)
 r4 = C3CB4960
(sys_sendto+0xc8/0xf0)
 r4 = 
(sys_socketcall+0x168/0x1f0)
(ret_fast_syscall+0x0/0x2c)


This call to sock_alloc_send_skb() in ip_append_data() is not from the 
inlined ip_ufo_append_data(), it is here:


/* The last fragment gets additional space at tail.
 * Note, with MSG_MORE we overallocate on fragments,
 * because we have no idea what fragment will be
 * the last.
 */
if (datalen == length + fraggap)
alloclen += rt-u.dst.trailer_len;

if (transhdrlen) {
skb = sock_alloc_send_skb(sk,
alloclen + hh_len + 15,
(flags  MSG_DONTWAIT), err);
} else {

Then, I traced a couple of paths how such a skbuff, coming down from 
ip_append_data() and allocated above get freed (when they do):


[c0182380] (__kfree_skb+0x0/0x170) from [c0182514] (kfree_skb+0x24/0x50)
 r5 = C332BC00  r4 = C332BC00 
[c01824f0] (kfree_skb+0x0/0x50) from [bf0fac58] (irlap_update_nr_received+0x94/0xc8 [irda])

[bf0fabc4] (irlap_update_nr_received+0x0/0xc8 [irda]) from [bf0fda98] 
(irlap_state_nrm_p+0x530/0x7c0 [irda])
 r7 = 0001  r6 = C0367EC0  r5 = C332BC00  r4 = 
[bf0fd568] (irlap_state_nrm_p+0x0/0x7c0 [irda]) from [bf0fbd90] 
(irlap_do_event+0x68/0x18c [irda])
[bf0fbd28] (irlap_do_event+0x0/0x18c [irda]) from [bf1008cc] 
(irlap_driver_rcv+0x1f0/0xd38 [irda])
[bf1006dc] (irlap_driver_rcv+0x0/0xd38 [irda]) from [c01892c0] 
(netif_receive_skb+0x244/0x338)
[c018907c] (netif_receive_skb+0x0/0x338) from [c0189468] 
(process_backlog+0xb4/0x194)
[c01893b4] (process_backlog+0x0/0x194) from [c01895f8] 
(net_rx_action+0xb0/0x210)
[c0189548] (net_rx_action+0x0/0x210) from [c0042f7c] (ksoftirqd+0x108/0x1cc)
[c0042e74] (ksoftirqd+0x0/0x1cc) from [c0053614] (kthread+0x10c/0x138)
[c0053508] (kthread+0x0/0x138) from [c003f918] (do_exit+0x0/0x8b0)
 r8 =   r7 =   r6 =   r5 = 
 r4 = 

and

[c0182380] (__kfree_skb+0x0/0x170) from [c0182514] (kfree_skb+0x24/0x50)
 r5 = C03909E0  r4 = C1A97400 
[c01824f0] (kfree_skb+0x0/0x50) from [c0199bf8] (pfifo_fast_enqueue+0xb4/0xd0)

[c0199b44] (pfifo_fast_enqueue+0x0/0xd0) from [c0188c30] 
(dev_queue_xmit+0x17c/0x25c)
 r8 = C1A2DCE0  r7 = FFF4  r6 = C3393114  r5 = C03909E0
 r4 = C3393000 
[c0188ab4] (dev_queue_xmit+0x0/0x25c) from [c01a7c18] (ip_output+0x150/0x254)

 r7 = C3717120  r6 = C03909E0  r5 =   r4 = C1A2DCE0
[c01a7ac8] (ip_output+0x0/0x254) from [c01a93d0] 
(ip_push_pending_frames+0x368/0x4d4)
[c01a9068] (ip_push_pending_frames+0x0/0x4d4) from [c01c6954] 
(udp_push_pending_frames+0x14c/0x310)
[c01c6808] (udp_push_pending_frames+0x0/0x310) from [c01c70d8] 
(udp_sendmsg+0x5c0/0x690)
[c01c6b18] (udp_sendmsg+0x0/0x690) from [c01ceafc] (inet_sendmsg+0x60/0x64)
[c01cea9c] (inet_sendmsg+0x0/0x64) from [c017c970] (sock_sendmsg+0xb4/0xe4)
 r7 = C2CEFDF4  r6 = 0064  r5 = C2CEFEA8  r4 = C3C94080
[c017c8bc] (sock_sendmsg+0x0/0xe4) from [c017dd9c] (sys_sendto+0xc8/0xf0)
 r7 = 0064  r6 = C3571580  r5 = C2CEFEC4  r4 = 
[c017dcd4] (sys_sendto+0x0/0xf0) from [c017e654] 
(sys_socketcall+0x168/0x1f0)
[c017e4ec] (sys_socketcall+0x0/0x1f0) from [c001ff40] 
(ret_fast_syscall+0x0/0x2c)
 r5 = 00415344  r4 = 

I would be greatful for any hints how I can identify which skbuff's get 
lost and why, and where and who should free them.


I am not subscribed to netdev, please keep in cc.

Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [irda-users] [2.6.20-rt8] Neighbour table overflow.

[Guennadi Liakhovetski]

On Wed, 21 Mar 2007, Samuel Ortiz wrote:


On 3/21/2007, Guennadi Liakhovetski [EMAIL PROTECTED] wrote:


[c0182380] (__kfree_skb+0x0/0x170) from [c0182514] (kfree_skb+0x24/0x50)
 r5 = C332BC00  r4 = C332BC00
[c01824f0] (kfree_skb+0x0/0x50) from [bf0fac58] 
(irlap_update_nr_received+0x94/0xc8 [irda])
[bf0fabc4] (irlap_update_nr_received+0x0/0xc8 [irda]) from [bf0fda98] 
(irlap_state_nrm_p+0x530/0x7c0 [irda])
 r7 = 0001  r6 = C0367EC0  r5 = C332BC00  r4 = 
[bf0fd568] (irlap_state_nrm_p+0x0/0x7c0 [irda]) from [bf0fbd90] 
(irlap_do_event+0x68/0x18c [irda])
[bf0fbd28] (irlap_do_event+0x0/0x18c [irda]) from [bf1008cc] 
(irlap_driver_rcv+0x1f0/0xd38 [irda])
[bf1006dc] (irlap_driver_rcv+0x0/0xd38 [irda]) from [c01892c0] 
(netif_receive_skb+0x244/0x338)
[c018907c] (netif_receive_skb+0x0/0x338) from [c0189468] 
(process_backlog+0xb4/0x194)
[c01893b4] (process_backlog+0x0/0x194) from [c01895f8] 
(net_rx_action+0xb0/0x210)
[c0189548] (net_rx_action+0x0/0x210) from [c0042f7c] (ksoftirqd+0x108/0x1cc)
[c0042e74] (ksoftirqd+0x0/0x1cc) from [c0053614] (kthread+0x10c/0x138)
[c0053508] (kthread+0x0/0x138) from [c003f918] (do_exit+0x0/0x8b0)
 r8 =   r7 =   r6 =   r5 = 
 r4 = 

This is the IrDA RX path, so I doubt the corresponding skb ever got
through
ip_append_data(). The skb was allocated by your HW driver upon packet
reception, then queued to the net input queue, and finally passed to the
IrDA stack. Are you sure your tracing is correct ?


I've added a bitfield to struct sk_buff:

__u8pkt_type:3,
fclone:2,
-   ipvs_property:1;
+   ipvs_property:1,
+   trace_dbg:1;

and I set itin ip_append_data() before sock_alloc_send_skb() is called. 
Then I check this bit in __kfree_skb(). The bit is set to 0 in __alloc_skb 
per


memset(skb, 0, offsetof(struct sk_buff, truesize));

So, if it was a freshly allocated skb, the tracing should be correct.


[c0182380] (__kfree_skb+0x0/0x170) from [c0182514] (kfree_skb+0x24/0x50)
 r5 = C03909E0  r4 = C1A97400
[c01824f0] (kfree_skb+0x0/0x50) from [c0199bf8] 
(pfifo_fast_enqueue+0xb4/0xd0)
[c0199b44] (pfifo_fast_enqueue+0x0/0xd0) from [c0188c30] 
(dev_queue_xmit+0x17c/0x25c)
 r8 = C1A2DCE0  r7 = FFF4  r6 = C3393114  r5 = C03909E0
 r4 = C3393000
[c0188ab4] (dev_queue_xmit+0x0/0x25c) from [c01a7c18] 
(ip_output+0x150/0x254)
 r7 = C3717120  r6 = C03909E0  r5 =   r4 = C1A2DCE0
[c01a7ac8] (ip_output+0x0/0x254) from [c01a93d0] 
(ip_push_pending_frames+0x368/0x4d4)
[c01a9068] (ip_push_pending_frames+0x0/0x4d4) from [c01c6954] 
(udp_push_pending_frames+0x14c/0x310)
[c01c6808] (udp_push_pending_frames+0x0/0x310) from [c01c70d8] 
(udp_sendmsg+0x5c0/0x690)
[c01c6b18] (udp_sendmsg+0x0/0x690) from [c01ceafc] (inet_sendmsg+0x60/0x64)
[c01cea9c] (inet_sendmsg+0x0/0x64) from [c017c970] (sock_sendmsg+0xb4/0xe4)
 r7 = C2CEFDF4  r6 = 0064  r5 = C2CEFEA8  r4 = C3C94080
[c017c8bc] (sock_sendmsg+0x0/0xe4) from [c017dd9c] (sys_sendto+0xc8/0xf0)
 r7 = 0064  r6 = C3571580  r5 = C2CEFEC4  r4 = 
[c017dcd4] (sys_sendto+0x0/0xf0) from [c017e654] 
(sys_socketcall+0x168/0x1f0)
[c017e4ec] (sys_socketcall+0x0/0x1f0) from [c001ff40] 
(ret_fast_syscall+0x0/0x2c)
 r5 = 00415344  r4 = 

This one is on the TX path, yes. However it got dropped and freed because
your TX queue was full. Any idea in which situation does that happen ?


No. I can only describe what communication is running while ppp is 
disrupted - it's just some sort of udp mirror test - udp packets are sent 
one after another and mirrored back.



I would be greatful for any hints how I can identify which skbuff's get
lost and why, and where and who should free them.

You're seeing skb leaks when cutting the ppp connection periodically,
right ?


Right


Do you such leaks when not cutting the ppp connection ?


Looks like I don't.


If not, could you send me a kernel trace (with irda debug set to 5) when
the ppp connection is shut down ? It would narrow down the problem a bit.


Attached bzipped... It's a complete log starting from irda up, running udp 
packets over the link, closing the link and bringing irda completely down.



I'm quite sure the leak is in the IrDA code rather than in the ppp or
ipv4 one, hence the need for full irda debug...


Likely, yes. Why I am asking netdev guys for help is just because I have 
very little idea about the data flow in the network stack(s). And the more 
experienced eyes we have on the problem the sooner we might solve it, I 
hope...


Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

mpppdown.bz2
Description: Binary data

Management packet 0x70 - connection broken

[Guennadi Liakhovetski]

Hi all

Using the zd1211rw driver on a ppc under Sarge, 2.6.17-rc2 with some 
ieee80211 / softmac patches I get

ieee80211: eth1: Unknown management packet: 112

and then the connection was broken:-( What is the 0x70 packet? Have been 
using the original zd1211 vendor-based driver before, probably, these 
packets also were seen, but the connection didn't break. I can put a debug 
in the original driver to see what happens when these packets arrive. 
Basically they just ignore them as well as ieee80211 now, but without 
fatal consequences... Using openvpn over eth1 if it matters.

Not subscribed, please cc.

Thanks
Guennadi
---
Guennadi Liakhovetski
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Management packet 0x70 - connection broken

[Guennadi Liakhovetski]

On Sun, 28 May 2006, Guennadi Liakhovetski wrote:

 ieee80211: eth1: Unknown management packet: 112

a small addendum: below is the function from the original driver, where 
they process management packets. Although they don't have special 
processing for 0x70, they seem to be doing lots of stuff for 
unrecognised packets. Complete sources are at 
http://zd1211.ath.cx/download/, the new (rewrite) driver, that uses the 
ieee80211 layer is at http://www.deine-taler.de/zd1211/snapshots/

Thanks
Guennadi
---
Guennadi Liakhovetski

__inline unsigned long
Cfg_CtrlSetting(
struct zd1205_private *macp,
zd1205_SwTcb_t  *pSwTcb,
wla_Header_t*pWlaHdr,
ctrl_Set_parm_t *pSetParms
)
{
zd1205_Ctrl_Set_t   *pCtrlSet = pSwTcb-pHwCtrlPtr;
u8  tmp;
u16 Len = 0;
u16 NextLen = 0;
u16 LenInUs = 0;
u16 NextLenInUs = 0;
u8  Service;
u8  TxRate;
u8  Rate = pSetParms-Rate;
u8  Preamble = pSetParms-Preamble;
u32 CurrFragLen = pSetParms-CurrFragLen;
u32 NextFragLen = pSetParms-NextFragLen;
u8  encryType = pSetParms-encryType;
//u8vapId = pSetParms-vapId;
u8  bMgtFrame = 0;
u8  bGroupAddr = 0;
u8  EnCipher = ((pWlaHdr-FrameCtrl[1]  ENCRY_BIT) 
? 1 : 0);
u16 FragNum = (pWlaHdr-SeqCtrl[0]  0x0F);
card_Setting_t  *pCardSettting = macp-cardSetting;
u16 FrameType = pWlaHdr-FrameCtrl[0];
u8  bBusrt = 0;
#ifdef ZD1211B

u8  LengthDiff=0;
#endif

memset(pCtrlSet,0,sizeof(zd1205_Ctrl_Set_t));

if (Rate  macp-AdapterMaxRate)
Rate = macp-AdapterMaxRate;

if ((FrameType  0x0c) == MANAGEMENT)
{
bMgtFrame = 1;
Rate = dot11Obj.BasicRate;
}
if ((FrameType  0x0c) == DATA)
{
write_str(DbgStr101, EnCipher);
}
if (bMgtFrame)
{
if ((FrameType == PROBE_RSP) || (FrameType == PROBE_REQ)) {
// Ensure Site-Survey smooth
Rate = RATE_1M;
Preamble = 0;
}
}

if (FrameType == PS_POLL)
{
// For compatibility with D-Link AP
Rate = RATE_1M;
Preamble = 0;
}

if ((Rate == RATE_1M)  (Preamble == 1))
{ //1M  short preamble
Rate = RATE_2M;
}

if (macp-bFixedRate)
{
if (!bMgtFrame)
Rate = pCardSettting-FixedRate;
}

pSwTcb-Rate = Rate;
//FPRINT_V(zdinline Rate, Rate);

#if !defined(OFDM)

pCtrlSet-CtrlSetting[0] = (Rate | (Preamble  5));
#else

if (Rate  RATE_6M)
{ //CCK frame
pCtrlSet-CtrlSetting[0] = (Rate | (Preamble  5));
//``JWEI 2003/12/22
#if fTX_PWR_CTRL

if ((macp-TxOFDMCnt  0)  (macp-TxOFDMCnt  cTX_SENT_LEN))
macp-TxOFDMCnt --;
macp-TxPwrCCK ++;
#endif

} else
{
#if fTX_PWR_CTRL
macp-TxPwrOFDM ++;
macp-TxOFDMCnt ++;
if (Rate == RATE_48M) {
if (macp-TxOFDMType != cTX_48M)
macp-TxOFDMCnt = 0;
macp-TxOFDMType = cTX_48M;
} else if (Rate == RATE_54M) {
if (macp-TxOFDMType != cTX_54M)
macp-TxOFDMCnt = 0;
macp-TxOFDMType = cTX_54M;
} else {
if (macp-TxOFDMType != cTX_OFDM)
macp-TxOFDMCnt = 0;
macp-TxOFDMType = cTX_OFDM;
}
#endif

pCtrlSet-CtrlSetting[0] = OfdmRateTbl[Rate];
}
#endif

TxRate = Rate;

//keep current Tx rate
pCardSettting-CurrTxRate = TxRate;

/* Length in byte */
if (EnCipher)
{
if (!pCardSettting-SwCipher) {
write_str(DbgStr102, encryType);
switch(encryType) {
case WEP64:
case WEP128:
case WEP256:
Len = CurrFragLen + 36; /* Header(24) + 
CRC32(4) + IV(4) + ICV(4) */
NextLen = NextFragLen + 36;
#ifdef ZD1211B

LengthDiff=17;
#endif