Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround (fwd)
From: Ilpo Järvinen <hidden>
Date: 2008-10-20 21:48:18
On Fri, 17 Oct 2008, Dâniel Fraga wrote:
On Mon, 13 Oct 2008 16:35:08 +0300 (EEST) "Ilpo Järvinen" [off-list ref] wrote: Just reporting another stall event... Who knows it helps in some way...quoted
...might turn out related. It has somewhat similar problem though different syscall. Not enough info on what kernel version etc. there though.Well, I can be wrong, but I think those stalls are related to USB (or USB helped to "solve" the stall temporarily)... I explain below (I have a monitor with usb hub connected): Oct 17 19:35:55 tux sudo: pam_unix(sudo:session): session opened for user root by fraga(uid=0) Oct 17 19:35:55 tux sudo: pam_unix(sudo:session): session closed for user root ^---------- sudo opened the session at 19:35 Oct 17 19:38:16 tux sudo: fraga : TTY=pts/2 ; PWD=/usr/local/lib ; USER=root ; COMMAND=/usr/local/bin/rm libdvdread.a libdvdread.la libdvdread.so libdvdread.so.3 libdvdread.so.3.2.1 libdvdread.so.4 libdvdread .so.4.1.2 ^---------- I tried to run this command with sudo. And it stalled. Notice that it was logged only on 19:38. Oct 17 19:38:16 tux sudo: pam_unix(sudo:session): session opened for user root by fraga(uid=0) Oct 17 19:38:16 tux sudo: pam_unix(sudo:session): session closed for user root Oct 17 19:40:20 tux vmunix: ci000/000:21ub/-/-./-../-..:./nu/nu7 ^----------- Here is the stall. You can see that the log is corrupted, every other line. Oct 17 19:40:20 tux vmunix: 6ipt S I 11 os Lgtc pia S os]o s-000:21112 ^----------- Every other line. Here is when I turned off my monitor with USB... Unless it was an extreme coincidence, I'm sure this event of turning off and...
You probably meant every other character... :-) The same as with the netfilter logs... I've two open question related to it, where did the every other letter go...? and why not a larger block but only a single char is missing (at a time)? I've no idea about printk's internals, maybe I'll try to ping somebody tomorrow about it.
Oct 17 19:40:25 tux vmunix: sd 9:0:0:0: [sdb] Attached SCSI removable disk Oct 17 19:40:25 tux scsi.agent[5498]: disk at /devices/pci0000:00/0000:00:02.1/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0/host9/target9:0:0/9:0:0:0 ^---------- ...turning on again, helped to "solve" the stall. The stall ended when I turned off the monitor. Oct 17 19:40:28 tux sudo: fraga : TTY=pts/2 ; PWD=/usr/local/lib ; USER=root ; COMMAND=/usr/local/bin/ls Oct 17 19:40:28 tux sudo: pam_unix(sudo:session): session opened for user root by fraga(uid=0) Oct 17 19:40:28 tux sudo: pam_unix(sudo:session): session closed for user root Oct 17 19:40:30 tux scsi.agent[5310]: Attribute /sys/devices/pci0000:00/0000:00:02.1/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0/host9/type does not exist Oct 17 19:40:35 tux scsi.agent[5493]: Attribute /sys/devices/pci0000:00/0000:00:02.1/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0/host9/target9:0:0/type does not exist Oct 17 20:12:37 tux vmunix: usb-storage: device found at 14 Oct 17 20:12:37 tux vmunix: usb-storage: waiting for device to settle before scanning Oct 17 20:12:42 tux vmunix: scsi 10:0:0:0: Direct-Access Generic ls SC 53 Q NI Oct 17 20:12:42 tux vmunix: k Oct 17 20:12:42 tux scsi.agent[7439]: disk at /devices/pci0000:00/0000:00:02.1/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0/host10/target10:0:0/10:0:0:0 Oct 17 20:12:47 tux vmunix: DROP INPUT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:15:e9:e2:00:db:08:00 SRC=192.168.0.1 DST=255.255.255.255 LEN=334 TOS=0x00 PREC=0x00 TTL=64 ID=6668 PROTO=UDP SPT=67 DPT=68 LEN=314 Oct 17 20:12:47 tux scsi.agent[7252]: Attribute /sys/devices/pci0000:00/0000:00:02.1/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0/host10/type does not exist Oct 17 20:12:53 tux scsi.agent[7435]: Attribute /sys/devices/pci0000:00/0000:00:02.1/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0/host10/target10:0:0/type does not exist *** At the server I have an usb device connected too... OR at eh end it's just a symptom of the problem... I don't know. The interesting thing is that as soon as I turned off the monitor (at the exact moment), the speaker beeped, because I used TAB to auto complete my command, and I knew that sudo wasn't stalled anymore. Maybe what the kernel does when we remove a usb hub could give us a hint about the stalling issue...
I doubt we'll find the cause from networking... Trying something a bit more generic: Try running vmstat 1 > somelog.file to see if there's something particularly interesting behavior during the stall. -- i.