Re: memory problem with fec on 8250

Re: memory problem with fec on 8250

[Samo Pogacnik]

Hello!

Is it possible that there is something wrong in the way how the:
"netif_wake_queue(dev)" gets called from the interrupt handler in the
"fcc_enet.c"?
I can confirm this problem for 2.4.18 as well as 2.6.0 kernels on mpc82xx.

bye, Samo

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: memory problem with fec on 8250

[Wojciech Kromer]

Użytkownik Samo Pogacnik napisał:

>Hello!
>
>Is it possible that there is something wrong in the way how the:
>"netif_wake_queue(dev)" gets called from the interrupt handler in the
>"fcc_enet.c"?
>I can confirm this problem for 2.4.18 as well as 2.6.0 kernels on mpc82xx.
>
>bye, Samo
>
>
>
>
i don't know exactly what's wrong with 82xx code,
but i wrote a small patch that frees unfreed skbuf before allocating new
one,
and now it works fine

additionaly, i had no problem with (almost) the same code on 8xx

--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: memory problem with fec on 8250

[Samo Pogacnik]

On Monday 05 January 2004 09:15, Wojciech Kromer wrote:
> Użytkownik Samo Pogacnik napisał:
> >
> >Is it possible that there is something wrong in the way how the:
> >"netif_wake_queue(dev)" gets called from the interrupt handler in the
> >"fcc_enet.c"? I can confirm this problem for 2.4.18 as well as 2.6.0
> >kernels on mpc82xx.
>
> i don't know exactly what's wrong with 82xx code, but i wrote a small
> patch that frees unfreed skbuf before allocating new one, and now it
> works fine
>
> additionaly, i had no problem with (almost) the same code on 8xx

hi, Wojciech
can you send the patch?
did you free skbuffs from the irq handler or somewhere else?

when i run netperf (snapshot) test using the 100Mbps connection, this
test eats all the available RAM. the /proc/meminfo shows that most of the used
memory at that point is been held by internal kernel structures (Slab).

by, Samo

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

cd

[Wojciech Kromer]

Użytkownik Samo Pogacnik napisał:

>On Monday 05 January 2004 09:15, Wojciech Kromer wrote:
>
>
>>Użytkownik Samo Pogacnik napisał:
>>
>>
>>>Is it possible that there is something wrong in the way how the:
>>>"netif_wake_queue(dev)" gets called from the interrupt handler in the
>>>"fcc_enet.c"? I can confirm this problem for 2.4.18 as well as 2.6.0
>>>kernels on mpc82xx.
>>>
>>>
>>i don't know exactly what's wrong with 82xx code, but i wrote a small
>>patch that frees unfreed skbuf before allocating new one, and now it
>>works fine
>>
>>additionaly, i had no problem with (almost) the same code on 8xx
>>
>>
>
>hi, Wojciech
>can you send the patch?
>
sure, just 4 lines addes

>did you free skbuffs from the irq handler or somewhere else?
>
>
just before allocation

>when i run netperf (snapshot) test using the 100Mbps connection, this
>test eats all the available RAM. the /proc/meminfo shows that most of the used
>memory at that point is been held by internal kernel structures (Slab).
>
>
better reults are shwn with
grep skb /proc/slabinfo

>by, Samo
>
>
here it is:

--------------------------------------------------------------------------------------------------------
***************
*** 413,418 ****
--- 412,420 ----

      /* Save skb pointer.
      */
+     //by k@m 2003-12-05
+     if(cep->tx_skbuff[cep->skb_cur])
+      dev_kfree_skb_irq (cep->tx_skbuff[cep->skb_cur]);
      cep->tx_skbuff[cep->skb_cur] = skb;

      cep->stats.tx_bytes += skb->len;
***************
*** 560,565 ****
--- 562,568 ----
          /* Free the sk buffer associated with this last transmit.
          */
          dev_kfree_skb_irq(cep->tx_skbuff[cep->skb_dirty]);
+         cep->tx_skbuff[cep->skb_dirty]=0;//by k@m 2003-12-05
          cep->skb_dirty = (cep->skb_dirty + 1) & TX_RING_MOD_MASK;

          /* Update pointer to next buffer descriptor to be transmitted.
***************
*** 1348,1353 ****
--- 1351,1357 ----
       * It works when I do this.
       */
      memset((char *)ep, 0, sizeof(fcc_enet_t));
+     memset(cep->tx_skbuff,0,sizeof(cep->tx_skbuff));

      /* Allocate space for the buffer descriptors in the DP ram.
       * These are relative offsets in the DP ram address space.
-------------------------------------------------------------------------------------------

ps: i send you my full version of fcc_enet.c

--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: memory problem with fec on 8250

[Samo Pogacnik]

On Tuesday 06 January 2004 08:47, Wojciech Kromer wrote:
> sure, just 4 lines addes
>
> >did you free skbuffs from the irq handler or somewhere else?
>
> just before allocation
>
> >when i run netperf (snapshot) test using the 100Mbps connection, this
> >test eats all the available RAM. the /proc/meminfo shows that most
> >of the used memory at that point is been held by internal kernel
> >structures (Slab).
>
> better reults are shwn with grep skb /proc/slabinfo
>
> here it is:
	.
	.
	.
Thank you for the tips and the patch.
Eth seems to be working now without eating the RAM.

By the way that you have solved the problem, I suspect that BDs are written
over the dirty_tx limit, before their associated skbs get freed via the irq
handler.

bye, Samo

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: cd

[Andreas Ericsson]

On 04/03/2013 04:49 PM, jpinheiro wrote:
> Hi all,
>
> We are students from Universidade do Minho in Portugal, and we are using git
> in project as a case study.
> While experimenting with git we found an unexpected behavior with git rm.
> Here is a trace of the unexpected behavior:
>
> $ git init
> $ mkdir D
> $ echo "Hi" > D/F
> $ git add D/F
> $ rm -r D
> $ echo "Hey" > D
> $ git rm D/F
> warning: 'D/F': Not a directory
> rm 'D/F'
> fatal: git rm: 'D/F': Not a directory
>
>
> If the file D created with last echo did not exist or was named differently
> then no error would occur as expected. For example:
>
> $ git init
> $ mkdir D
> $ echo "Hi" > D/F
> $ git add D/F
> $ rm -r D
> $ echo "Hey" > F
> $ git rm D/F
>
> This works as expected, and the only difference is the name of the file of
> the last echo.
> Is this the expected behavior of git rm?
>

Yes. The only difference between 'git rm' and 'rm' is that git rm also
removes the file from its index and prepares to commit a version without
it. From git's point of view, it's not an error if the file doesn't
exist. It *is* an error if the directory where the file should reside
suddenly no longer a directory though.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

cd

[jpinheiro]

Hi all,

We are students from Universidade do Minho in Portugal, and we are using git
in project as a case study.
While experimenting with git we found an unexpected behavior with git rm.
Here is a trace of the unexpected behavior:

$ git init
$ mkdir D
$ echo "Hi" > D/F
$ git add D/F
$ rm -r D
$ echo "Hey" > D
$ git rm D/F
warning: 'D/F': Not a directory
rm 'D/F'
fatal: git rm: 'D/F': Not a directory


If the file D created with last echo did not exist or was named differently
then no error would occur as expected. For example:

$ git init
$ mkdir D
$ echo "Hi" > D/F
$ git add D/F
$ rm -r D
$ echo "Hey" > F
$ git rm D/F

This works as expected, and the only difference is the name of the file of
the last echo.
Is this the expected behavior of git rm?




--
View this message in context: http://git.661346.n2.nabble.com/cd-tp7581484.html
Sent from the git mailing list archive at Nabble.com.