TCP_REPAIR code and how it works

[Ramana Reddy]

Hi All,

Any one have an idea of  hwo TCP_REPAIR works, and a working example
of a client and multiple servers.

Looking forward for your help.

Thanks & Regards,
Raman
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: mkinitcpio

[Pablo G. Gallardo]

Em 7 de fevereiro de 2016 23:07:54 BRST, Tobin Harding  escreveu:
>> 
>> Please post every step you took to build the kernel.
>> 
>> Thanks,
>> -- 
>> Pablo G. Gallardo
>
>Hi Pablo,
>
>Thanks for the reply. While typing out a response to you with my build
>steps I
>found the problem
>
>$ zcat /proc/config.gz > config
>
>Should have been .config
>
>Thanks again (I'm emailing you from the new running kernel!)
>
>Tobin

Hello Tobin,

Nice! I'm copying the mailing list so if anyone else has this problem, they'll 
know where to start looking.

Regards,
-- 
Pablo G. Gallardo

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Memory Management

[Robert P. J. Day]

Quoting sanjeev sharma :

> Hi,
>
> I would suggest you to go through the Linux Kernel book Robert Love which
> is simpler to understand.

   just a caution that that book is starting to show its age, even though
it's still really, really good. the memory management is probably still
fairly current, but i would compare all code snippets against the
current kernel just in case.

rday



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Process Scheduling

[Nitin Varyani]

Hi,
  I am new to kernel source. I want to plugin a new process scheduling
algorithm. Can someone elaborate the steps to do it?
Nitin
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Memory Management

[慕冬亮]

I think "Understanding The Linux Virtual Memory Manager" is a good choice.

[1] Understanding The Linux Virtual Memory Manager:
https://www.kernel.org/doc/gorman/pdf/understand.pdf

2016-02-06 2:49 GMT+08:00 masoud hematpour :

> Hi,
>
> I am beginner to kernel source. I decide to work on Performance Tuning. I
> studied some material around memory management but which material is well
> described for Memory management in Linux?
>
>
> Thank you,
>
>
> masoud
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>


-- 
My best regards to you.

 No System Is Safe!
 mudongliang
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: mkinitcpio

[Bjørn Mork]

Tobin Harding  writes:

> Issue resolved thank you. I forgot to CC the list. Thanks also to Pablo
> G. Gallardo.

Please give a summary of how the issue was resolved, even if it may seem
obvious to you now.  The problem was important enough for you to ask
about, and you can be sure that you are not alone. The next person
having the same problem will find your question.  A nice gesture would
be to let them find your answer as well...


Bjørn

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Memory Management

[sanjeev sharma]

Hi,

I would suggest you to go through the Linux Kernel book Robert Love which
is simpler to understand.

Regards
Sanjeev Sharma

On Mon, Feb 8, 2016 at 2:13 PM, 慕冬亮  wrote:

> I think "Understanding The Linux Virtual Memory Manager" is a good choice.
>
> [1] Understanding The Linux Virtual Memory Manager:
> https://www.kernel.org/doc/gorman/pdf/understand.pdf
>
> 2016-02-06 2:49 GMT+08:00 masoud hematpour :
>
>> Hi,
>>
>> I am beginner to kernel source. I decide to work on Performance Tuning. I
>> studied some material around memory management but which material is well
>> described for Memory management in Linux?
>>
>>
>> Thank you,
>>
>>
>> masoud
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>
>
> --
> My best regards to you.
>
>  No System Is Safe!
>  mudongliang
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: mkinitcpio

[Tobin Harding]

Issue resolved thank you. I forgot to CC the list. Thanks also to Pablo
G. Gallardo.

Regards,
Tobin Harding.


signature.asc
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: dma_alloc_coherent

[sanjeev sharma]

Hello Saumendra,

I would suggest you to go through the following link: 1) This will explain
need of DMA with practical scenario 2) ARM DMA Mapping with example

https://sanjeevsharmaengg.wordpress.com/2014/08/26/why-dma-required-in-linux-kernel/

http://linuxkernelhacker.blogspot.in/2014/07/arm-dma-mapping-explained.html

I hope these link will give you more confidence around understanding of DMA.

Regards
Sanjeev Sharma

On Mon, Feb 8, 2016 at 12:29 PM, Saumendra Dash  wrote:

> >> Hi Ran,
> >  the api which you have mentioned...
> >
> >> void *
> >> dma_alloc_coherent(struct device *dev, size_t size,
> >> dma_addr_t *dma_handle, gfp_t flag)
> >>
> >> is the kernel api to alloc consistent memory.
> >>
> >> DMA devices understand the physical addresses not the virtual addresses.
> >>
> >> which means that we must supply to the dma device, the physical
> >> address, to read
> >>
> >> from or to write to.
> >>
> >> The second argument of this api is an input argument which is updated
> >> by the kernel if this api returns a success (and contains the physical
> >> base address of the allocated memory) and the returned value of this
> >> api is the kernel virtual address.
> >>
> >> if the *CPU* has to operate on this memory (assume that the memory is
> >> dma'ed by the dma device and cpu want to read it for further
> >> processing ) it should use the virtual address, so the returned value
> >> of this api, as the base address.
> >> However, if the dma device has to operate on this memory (assume
> >> device want to write to this memory), it should use the *dma_handle* ,
> >> which is the physical address (base) of the dma memory.
> >>
> >> Now the question is how the dma device knows about this *physical*
> address?
> >> The answer is that the "dma controller" register would have a register
> >> to accept this physical address.
> >>
> >> So the sequence of steps probably would be, in your case:
> >> 1: allocate the dma memory
> >> 2: programme the dma controller register with the physical address
> >> returned by this api, plus the size of the transaction and may be some
> >> more registers for setting some kind of flags (depends on your dma
> >> device)
> >> 3: programme the dma controller's dma *start* bit.
> >>
> >> after this the dma starts and dma device starts writing to the memory .
>
> Hi Vishwas,
>
> >That's fully clarify the questions about dma_alloc_coherent.
>
> >I also try to figure out what's the difference between dma_alloc_coherent
> and dma_map_single.
>
> >I could not find and important difference between these two methods.
> >1. With both methods I stil need to program the dma controller with the
> physical address and the start trigger.
> >2. I can still do the allocation whenever I want with both methods (for
> example at the initialization of the driver), 3. Not sure what the actuall
> dma_map_single does (and if it really necessary to use it), becuase it
> >seems I could just translate the virtual value from kmalloc into physical
> address and return it to the dma controller.
>
> DMA transfers are done either in BURST mode or CYCLE STEALING mode.
> In Burst mode, the bus is captured for the entire duration of the
> transfer  from the SRC to DST.  In this case, the bus will  be released
> when the Xfer is complete, so obviously it is not an efficient way of doing
> DMA.  DMA_ALLOC_COHERENT() does this way.
> In Cycle Stealing mode, the DMA controller grab the bus when free, send a
> byte  and then free the bus immediately. This process is repeated till the
> Xfer is complete, it is very efficient sine the bus is not grabbed for the
> entire transaction to complete.  DMA_MAP_SINGLE() does this way.
>
>  Hope this helps.
>
> Thanks,
> Saumendra
>
>
> ::DISCLAIMER::
>
> 
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability
> on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error
> please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other 

Re: Memory Management

[navid Rahimi]

On Mon, Feb 8, 2016 at 2:58 PM, Robert P. J. Day  wrote:
> Quoting sanjeev sharma :
>
>> Hi,
>>
>> I would suggest you to go through the Linux Kernel book Robert Love which
>> is simpler to understand.
>
>just a caution that that book is starting to show its age, even though
> it's still really, really good. the memory management is probably still
> fairly current, but i would compare all code snippets against the
> current kernel just in case.
>
> rday

I did it, last year (almost), comparing code snippet in the book
toward kernel source there (I think it was version 3.10 or maybe 4.0,
I don't remember precisely), the code/topics is still relevant.

I am not aware of the situation for 4.14 or newer version tough.

best wishes,
-navid

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: mkinitcpio

[Sudip Mukherjee]

On Tue, Feb 9, 2016 at 11:57 AM,   wrote:
>
>
>
>> you were asked if this is from the challenge and you said yes.  Are you
>> trolling us or did I miss understand something?
>
> I'm very sorry, I in no way meant to troll. I am just honestly trying to
> learn kernel development. I have two books and the afore mention
> challenges as my guides. I am sorry, I miss-understood you, yes I did
> answer that question. I will refrain from mentioning the challenges or
> asking any questions I face while doing them in future.

little has his way of knowing if some one has asked a question regading
the challenge, and usually if some one asks then he is removed from the
challenge.

>
> Please accept my apologies, this was not the introduction to the kernel
> community that I had hoped for.

You are always welcome in the community, but the challenge rules says
"This challenge is for you, not anyone else, so don't ask about how to solve
them on mailing lists or IRC."

Regards
Sudip

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: mkinitcpio

[Ruben Safir]

On 02/09/2016 01:07 AM, m...@tobin.cc wrote:
> 
> I'm sorry if I have offended you, I don't believe that my question or
> explanation had anything to do with the challenge. Excepting that the
> work eudyptula was in the email
> 
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 


you were asked if this is from the challenge and you said yes.  Are you
trolling us or did I miss understand something?


-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: mkinitcpio

[me]

I am glad this is the newbies list ;)

The initial problem was 

# mkinitcpio -g initramfs-custom.img -k 4.5.0-eudyptula+
==> Starting build: 4.5.0-eudyptula+
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [keyboard]
  -> Running build hook: [fsck]
==> WARNING: No modules were added to the image. This is probably not
what you want.
==> Creating gzip-compressed initcpio image: /boot/initramfs-custom.img
==> Image generation successful
#

The cause of the warning turned out to be that I had built the kernel
with an 'empty' config file. 

$ zcat /proc/config > config

instead of

$ zcat /proc/config > .config
 
(note the dot on config)

If I was more experienced I would have realised this when the compile
time was so short. It was only  while replying to Pablo with the steps I
had taken to build the kernel that I noticed my error.

So, thank you to the kernelnewbies mailing list.

Regards,
Tobin Harding

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: mkinitcpio

[me]

> you were asked if this is from the challenge and you said yes.  Are you
> trolling us or did I miss understand something?

I'm very sorry, I in no way meant to troll. I am just honestly trying to
learn kernel development. I have two books and the afore mention
challenges as my guides. I am sorry, I miss-understood you, yes I did
answer that question. I will refrain from mentioning the challenges or
asking any questions I face while doing them in future.

Please accept my apologies, this was not the introduction to the kernel
community that I had hoped for.

Tobin Harding.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: mkinitcpio

[me]

> little has his way of knowing if some one has asked a question regarding
> the challenge, and usually if some one asks then he is removed from the
> challenge.

I sincerely hope that does not happen, it would be a real kick in the
teeth as far as my kernel education goes.

> You are always welcome in the community, but the challenge rules says
> "This challenge is for you, not anyone else, so don't ask about how to
> solve
> them on mailing lists or IRC."

Point noted, thank you. 

Regards,
Tobin Harding.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: mkinitcpio

[me]

I'm sorry if I have offended you, I don't believe that my question or
explanation had anything to do with the challenge. Excepting that the
work eudyptula was in the email

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: mkinitcpio

[me]

> Is it a task of the Eudyptula Challenge?

Hi Sudip,

Yes this was for task 3 of the  Eudyptula Challenge

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: mkinitcpio

[Ruben Safir]

On 02/09/2016 12:16 AM, m...@tobin.cc wrote:
> I am glad this is the newbies list ;)
> 
> The initial problem was 
> 
> # mkinitcpio -g initramfs-custom.img -k 4.5.0-eudyptula+
> ==> Starting build: 4.5.0-eudyptula+
>   -> Running build hook: [base]
>   -> Running build hook: [udev]
>   -> Running build hook: [autodetect]
>   -> Running build hook: [modconf]
>   -> Running build hook: [block]
>   -> Running build hook: [filesystems]
>   -> Running build hook: [keyboard]
>   -> Running build hook: [fsck]
> ==> WARNING: No modules were added to the image. This is probably not
> what you want.
> ==> Creating gzip-compressed initcpio image: /boot/initramfs-custom.img
> ==> Image generation successful
> #
> 
> The cause of the warning turned out to be that I had built the kernel
> with an 'empty' config file. 
> 
> $ zcat /proc/config > config
> 
> instead of
> 
> $ zcat /proc/config > .config
>  
> (note the dot on config)
> 
> If I was more experienced I would have realised this when the compile
> time was so short. It was only  while replying to Pablo with the steps I
> had taken to build the kernel that I noticed my error.
> 
> So, thank you to the kernelnewbies mailing list.
> 
> Regards,
> Tobin Harding
> 
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 


You are not supposed to send the Challenge to the list.  It says that
like 20 times when you sign up to the list :(


-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Virtual and physical page address

[Mohammad A Khasawneh]

Thank you for your answer. Is there a way to get the virtual address by
traversing the pgd->pte->page hierarchy? I'm not sure I can use the
phys_to_virt() function.

Thanks,
Mohammad
On Feb 7, 2016 16:43, "Mike Krinkin"  wrote:

> On Sun, Feb 07, 2016 at 04:24:08PM -0500, Mohammad A Khasawneh wrote:
> > Hello everyone,
> >
> > I am attempting to dump the page table of a process in terms of virtual
> > addresses and the corresponding physical addresses. I am looking for
> > information whether the pointers I am using are correct for this purpose:
> >
> > 1. Can I say that pte_page(pte_t) returns the virtual address of the page
> > that the PTE points at?
>
> pte_page returns struct page pointer (virtual address of the struct page,
> but
> i suppose it's not the virtual address you need), it has nothing to do
> with a
> virtual address the pte corresponds to.
>
> >
> > 2. can I say that page_to_phys(struct page) returns the physical address
> of
> > that same entry?
>
> page_to_phys returns physical address the struct page corresponds to, so
> yes.
>
> >
> > Thank you,
> > Mohammad
>
> > ___
> > Kernelnewbies mailing list
> > Kernelnewbies@kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Virtual and physical page address

[Mike Krinkin]

On Mon, Feb 08, 2016 at 08:57:01AM -0500, Mohammad A Khasawneh wrote:
> Thank you for your answer. Is there a way to get the virtual address by
> traversing the pgd->pte->page hierarchy?

Well, position of pte in the hierarchy defines the virtual address, so yes,
there is way. I'm not sure that a portable across different architetures way
exists though. You can look at this reference:

https://www.kernel.org/doc/gorman/html/understand/understand006.html

> I'm not sure I can use the phys_to_virt() function.

In general you can't.

> 
> Thanks,
> Mohammad
> On Feb 7, 2016 16:43, "Mike Krinkin"  wrote:
> 
> > On Sun, Feb 07, 2016 at 04:24:08PM -0500, Mohammad A Khasawneh wrote:
> > > Hello everyone,
> > >
> > > I am attempting to dump the page table of a process in terms of virtual
> > > addresses and the corresponding physical addresses. I am looking for
> > > information whether the pointers I am using are correct for this purpose:
> > >
> > > 1. Can I say that pte_page(pte_t) returns the virtual address of the page
> > > that the PTE points at?
> >
> > pte_page returns struct page pointer (virtual address of the struct page,
> > but
> > i suppose it's not the virtual address you need), it has nothing to do
> > with a
> > virtual address the pte corresponds to.
> >
> > >
> > > 2. can I say that page_to_phys(struct page) returns the physical address
> > of
> > > that same entry?
> >
> > page_to_phys returns physical address the struct page corresponds to, so
> > yes.
> >
> > >
> > > Thank you,
> > > Mohammad
> >
> > > ___
> > > Kernelnewbies mailing list
> > > Kernelnewbies@kernelnewbies.org
> > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> >

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies