August 2011 - kernelnewbies@kernelnewbies.org

Re: TCP - RST flag
by Daniel Baluta Aug. 23, 2011

Aug. 23, 2011

On Wed, Aug 24, 2011 at 12:50 AM, Eric Dumazet <eric.dumazet(a)gmail.com> wrote: > Le mercredi 24 août 2011 à 00:32 +0300, Daniel Baluta a écrit : >> On Tue, Aug 23, 2011 at 11:55 PM, Eric Dumazet <eric.dumazet(a)gmail.com> wrote: > >> > TCP in RFC 1122 section 4.2.2.13: >> > >> > "A host MAY implement a "half-duplex" TCP close sequence, so that an >> > application that has called CLOSE cannot continue to read data from the >> > connection. If such a host issues a CLOSE call while received data is >> > still pending in TCP, or if new data is received after CLOSE is called, >> > its TCP SHOULD send a RST to show that data was lost." >> >> So, this means that server's CLOSE operation is issued while received >> data is still pending? I will analyze ftp's server code, but this is strange >> since P4 [221 Have a nice day!\r\n] it is generated as a response for >> P3 [QUIT\r\n]. So P4 must have been fully received. >> > > tcpdump only shows TCP stack did receive the frame, not that it was > _read_ by application. > > Only strace could eventually say if the input queue was really drained > before the close(). > Maybe server decided to close the connexion before reading the QUIT > command from client. > >> Also, looking at the capture no data is received from the client after >> server calls CLOSE (P5) (there are only ACKs and FIN - P6, P7, P8). > > That doesnt matter. > > If data was received (and ACKnowledged by TCP stack) _before_ close(fd), > but not yet read by application, TCP must send an RST to be RFC > compliant. I see. Thanks a lot for your explanations. I will further use strace to see what's going on. Daniel.

1 0

Re: TCP - RST flag
by Daniel Baluta Aug. 23, 2011

Aug. 23, 2011

On Tue, Aug 23, 2011 at 11:55 PM, Eric Dumazet <eric.dumazet(a)gmail.com> wrote: > Le mardi 23 août 2011 à 23:31 +0300, Daniel Baluta a écrit : >> Hello, >> >> Please help me understanding the behavior of the following >> TCP conversation. >> >> You can find bellow a snippet of the (FTP) conversation captured both >> on client (C) and server (S). >> >> [client]$ tcpdump -n -r client-6-conv.cap >> [P1] 49.045690 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq >> 197:220, ack 81, win 757, length 23 >> [P2] 49.046600 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220, >> win 738, length 0 >> [P3] 49.047462 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq >> 81:87, ack 220, win 738, length 6 >> [P5] 49.048757 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq >> 242, ack 87, win 757, length 0 >> [P6] 49.048794 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220, >> win 738, options [nop,nop,sack 1 {242:243}], length 0 >> [P4] 49.048801 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq >> 220:242, ack 87, win 757, length 22 >> [P7] 49.048833 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243, >> win 715, length 0 >> [P8] 49.049566 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87, >> ack 243, win 715, length 0 >> [P9] 49.050889 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq >> 1672731590, win 0, length 0 >> >> [server]$ tcpdump -n -r server-6-conv.cap >> [P1] 49.059740 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq >> 197:220, ack 81, win 757, length 23 >> [P2] 49.061394 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220, >> win 738, length 0 >> [P3] 49.061760 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq >> 81:87, ack 220, win 738, length 6 >> [P4] 49.062794 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq >> 220:242, ack 87, win 757, length 22 >> [P5] 49.062843 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq >> 242, ack 87, win 757, length 0 >> [P6] 49.063808 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220, >> win 738, options [nop,nop,sack 1 {242:243}], length 0 >> [P7] 49.063823 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243, >> win 715, length 0 >> [P8] 49.064271 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87, >> ack 243, win 715, length 0 >> [P9] 49.064481 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq >> 1672731590, win 0, length 0 >> >> What happens is that servers sends packets P4 and P5, but client >> receives P5 before P4. >> Since SACK is enabled, client will send a SACK (P6) ack-ing P5. >> >> Then client sees P4, and will send an ack (P7) for P4, then sends P8 >> with FIN flag set. >> What I don't understand, is why server responds with RST (P9) instead of ACK? >> >> This is was obtained on 2.6.32.43. I have also attached full capture files. >> >> I am reading TCP's RFC and kernel code, but so far I haven't reached >> a conclusion. > > TCP in RFC 1122 section 4.2.2.13: > > "A host MAY implement a "half-duplex" TCP close sequence, so that an > application that has called CLOSE cannot continue to read data from the > connection. If such a host issues a CLOSE call while received data is > still pending in TCP, or if new data is received after CLOSE is called, > its TCP SHOULD send a RST to show that data was lost." So, this means that server's CLOSE operation is issued while received data is still pending? I will analyze ftp's server code, but this is strange since P4 [221 Have a nice day!\r\n] it is generated as a response for P3 [QUIT\r\n]. So P4 must have been fully received. Also, looking at the capture no data is received from the client after server calls CLOSE (P5) (there are only ACKs and FIN - P6, P7, P8). > This is why some apps first call shutdown(), then drain receive queue, > then close() This makes sense :). thanks Eric. Daniel.

2 1

TCP - RST flag
by Daniel Baluta Aug. 23, 2011

Aug. 23, 2011

Hello, Please help me understanding the behavior of the following TCP conversation. You can find bellow a snippet of the (FTP) conversation captured both on client (C) and server (S). [client]$ tcpdump -n -r client-6-conv.cap [P1] 49.045690 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq 197:220, ack 81, win 757, length 23 [P2] 49.046600 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220, win 738, length 0 [P3] 49.047462 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq 81:87, ack 220, win 738, length 6 [P5] 49.048757 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq 242, ack 87, win 757, length 0 [P6] 49.048794 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220, win 738, options [nop,nop,sack 1 {242:243}], length 0 [P4] 49.048801 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq 220:242, ack 87, win 757, length 22 [P7] 49.048833 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243, win 715, length 0 [P8] 49.049566 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87, ack 243, win 715, length 0 [P9] 49.050889 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq 1672731590, win 0, length 0 [server]$ tcpdump -n -r server-6-conv.cap [P1] 49.059740 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq 197:220, ack 81, win 757, length 23 [P2] 49.061394 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220, win 738, length 0 [P3] 49.061760 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq 81:87, ack 220, win 738, length 6 [P4] 49.062794 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq 220:242, ack 87, win 757, length 22 [P5] 49.062843 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq 242, ack 87, win 757, length 0 [P6] 49.063808 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220, win 738, options [nop,nop,sack 1 {242:243}], length 0 [P7] 49.063823 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243, win 715, length 0 [P8] 49.064271 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87, ack 243, win 715, length 0 [P9] 49.064481 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq 1672731590, win 0, length 0 What happens is that servers sends packets P4 and P5, but client receives P5 before P4. Since SACK is enabled, client will send a SACK (P6) ack-ing P5. Then client sees P4, and will send an ack (P7) for P4, then sends P8 with FIN flag set. What I don't understand, is why server responds with RST (P9) instead of ACK? This is was obtained on 2.6.32.43. I have also attached full capture files. I am reading TCP's RFC and kernel code, but so far I haven't reached a conclusion. thanks, Daniel.

2 1

Difference between logical and physical cpu hotplug
by Vaibhav Jain Aug. 23, 2011

Aug. 23, 2011

Hi, I need to know the difference between making a cpu logically offline and physically offline. I have read that the following command $ echo 0 > /sys/device/system/cpu/<cpu number>/online makes a cpu logically offline. It frees the cpu from interrupts and migrates running processes. But then what does it mean to make a cpu physically offline ? I referred to following article : http://www.kernel.org/doc/Documentation/cpu-hotplug.txt Here is the relevant excerpt : Q: Does hot-add/hot-remove refer to physical add/remove of cpus? A: The usage of hot-add/remove may not be very consistently used in the code. CONFIG_HOTPLUG_CPU enables logical online/offline capability in the kernel. To support physical addition/removal, one would need some BIOS hooks and the platform should have something like an attention button in PCI hotplug. CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs. Please help! Thanks Vaibhav Jain

5 13

how to compile additional module?
by loody Aug. 23, 2011

Aug. 23, 2011

Dear all: I make a module under kernel tree and adding Kconfig for that. But I have no idea where I should add that when I type "make modules", the modules I add will be compiled. Would anyone tell me where the modules list located? -- Regards,

2 5

Re: Headset driver detection problem during bootup
by anish singh Aug. 23, 2011

Aug. 23, 2011

adding more information and experts on alsa. On Fri, Aug 19, 2011 at 9:23 PM, anish singh <anish198519851985(a)gmail.com> wrote: > I need some suggestions for below situation: > > Headset if it is inserted before the device is powered up is > now detected by forcefully calling the interrupt handler in > the probe function of the headset driver. Headset is detected in our andorid device by using a detect gpio which is turned on when headset is inserted.If the headset is inserted right from very beginging i.e. before device is even turned on then we forcefully call the handler and thereby in handler we check if gpio is turned on or not and do the rest of things. > Once the handler is called then we find out if the headset > is there or not using gpio and then normal detection happens > > Is it the right way to detect the device during power-up? Does not linux have any other way of doing this which i may be missing? How this is handled in the case of ALSA jack i.e. the jack drivers which is using alsa framework for detection? Android doesn't use ALSA framework for reporting JACK. > > After the device is powered up and then if we insert headset > then it is working fine by calling the interrupt handler and > everything goes fine. > > linux -2.3.5 > Android Device >

2 2

Running code on an isolated core
by Vaibhav Jain Aug. 23, 2011

Aug. 23, 2011

Hi, I am looking into running a program on one of the cores which is isolated (logically offline ) from the rest of the cores. I have come to that the command echo 0 > /sys/device/system/cpu/<core num>/online will make a core logically offline, What I need to do now is to run a program on this offline core. Please suggest on how to proceed. Thanks! Vaibhav Jain

2 5

[ Kernel not booting up ]
by ashish raste Aug. 23, 2011

Aug. 23, 2011

Hi all, Recently I compiled and tried installing kernel (2.6.39.3), which I downloaded from kernel.org All the activity that I did was to copy the .config file of my distro (Ubuntu 10.10), then the following commands : - make menuconfig ( I exited, keeping the default configuration ) - make modules - make install_modules - make install - update grub All of the above commands got executed without any errors, and the new kernel version was also shown in the grub menu. But it showed some errors and didn't login. When I tried logging to my Ubuntu distro, a blue login box(which is normally violet in color) appeared. After giving password, it came back again to the same screen without going inside. Only thing I was able to do was to dropping in root mode (from Ubuntu's recovery mode u\in the grub menu) and looking at all of my data through terminal without a GUI. Can anyone tell how can I recover my compiled kernel and distro's kernel? Thankyou. -- ~Cheers!! Ashish Raste Anyone who has never made a mistake has never tried anything new. -Sir Albert Einstein

6 9

question in request_threaded_irq
by radhika bhaskaran Aug. 23, 2011

Aug. 23, 2011

Hi, I have a question with respect to request_threaded_irq. Assume that one driver has registered and ISR on some particular irq number. Can i use the same irq number and register and isr in another driver. Because that is my requirement. when i try to do that is an error message with an error no as -19. err = request_threaded_irq(pdata->irq , NULL, testing_fucntion, IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING, "testing_function", dev); Can some one please help me whether it is possible. Regards, RB

3 4

Can i allocate 4GB virtual addresses (more than a certain limit) using vmalloc?
by sandeep kumar Aug. 22, 2011

Aug. 22, 2011

Hi all, The following link gives the memory map for the arm architecture. http://www.arm.linux.org.uk/developer/memory.txt I have the following doubts.. 1) Any chipset(based on arm) manufacturer(qualcom,samsung..) should follow the same memory map. Is it hardly constrained or can be changed? Where are this constraints are implemented in the kernel source tree? 2) while i was student, i read in OS concepts that, "Virtual memory gives an illusion to a process, that it has always a larger continuous address space (even more than RAM) available to it." So i thought i could allocate howmuch ever memory i want. But seeing the above link,i observed there is some limitation in the address space created by the vmalloc(). So i m now thinking that vmalloc has some limit. Please make me clear these things.... With regards, Sandeep Kumar Anantapalli,

6 7