* Re: memory problem with fec on 8250 @ 2004-01-04 15:55 Samo Pogacnik 2004-01-05 8:15 ` Wojciech Kromer 0 siblings, 1 reply; 5+ messages in thread From: Samo Pogacnik @ 2004-01-04 15:55 UTC (permalink / raw) To: linuxppc-embedded 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: memory problem with fec on 8250 2004-01-04 15:55 memory problem with fec on 8250 Samo Pogacnik @ 2004-01-05 8:15 ` Wojciech Kromer 2004-01-05 22:52 ` Samo Pogacnik 0 siblings, 1 reply; 5+ messages in thread From: Wojciech Kromer @ 2004-01-05 8:15 UTC (permalink / raw) To: Linuxppc-Embedded (E-mail) 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: memory problem with fec on 8250 2004-01-05 8:15 ` Wojciech Kromer @ 2004-01-05 22:52 ` Samo Pogacnik 2004-01-06 7:47 ` cd Wojciech Kromer 0 siblings, 1 reply; 5+ messages in thread From: Samo Pogacnik @ 2004-01-05 22:52 UTC (permalink / raw) To: linuxppc-embedded 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* cd 2004-01-05 22:52 ` Samo Pogacnik @ 2004-01-06 7:47 ` Wojciech Kromer 2004-01-06 22:03 ` memory problem with fec on 8250 Samo Pogacnik 0 siblings, 1 reply; 5+ messages in thread From: Wojciech Kromer @ 2004-01-06 7:47 UTC (permalink / raw) To: Linuxppc-Embedded (E-mail) 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: memory problem with fec on 8250 2004-01-06 7:47 ` cd Wojciech Kromer @ 2004-01-06 22:03 ` Samo Pogacnik 0 siblings, 0 replies; 5+ messages in thread From: Samo Pogacnik @ 2004-01-06 22:03 UTC (permalink / raw) To: linuxppc-embedded 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-01-06 22:03 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-01-04 15:55 memory problem with fec on 8250 Samo Pogacnik 2004-01-05 8:15 ` Wojciech Kromer 2004-01-05 22:52 ` Samo Pogacnik 2004-01-06 7:47 ` cd Wojciech Kromer 2004-01-06 22:03 ` memory problem with fec on 8250 Samo Pogacnik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox