From: "Dâniel Fraga" <fragabr@gmail.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Cc: Thomas Gleixner <tglx@linutronix.de>,
David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround (fwd)
Date: Fri, 17 Oct 2008 20:51:49 -0300 [thread overview]
Message-ID: <48f9251b.1626360a.6574.61ec@mx.google.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0810131633370.3843@wrl-59.cs.helsinki.fi>
On Mon, 13 Oct 2008 16:35:08 +0300 (EEST)
"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> wrote:
Just reporting another stall event... Who knows it helps in some way...
> ...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...
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...
--
next prev parent reply other threads:[~2008-10-17 23:51 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-01 12:52 [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround (fwd) Ilpo Järvinen
2008-10-01 16:27 ` Dâniel Fraga
2008-10-01 20:05 ` Thomas Gleixner
2008-10-01 20:46 ` Dâniel Fraga
2008-10-01 21:14 ` Dâniel Fraga
2008-10-02 10:42 ` Thomas Gleixner
2008-10-02 11:17 ` Dâniel Fraga
2008-10-02 12:08 ` Thomas Gleixner
2008-10-02 14:09 ` Dâniel Fraga
2008-10-02 19:16 ` Thomas Gleixner
2008-10-02 20:31 ` Ilpo Järvinen
2008-10-02 20:59 ` Dâniel Fraga
2008-10-02 21:19 ` Ilpo Järvinen
2008-10-02 21:39 ` Dâniel Fraga
2008-10-05 17:52 ` Dâniel Fraga
2008-10-05 18:09 ` Thomas Gleixner
2008-10-05 19:31 ` Dâniel Fraga
2008-10-06 1:27 ` Dâniel Fraga
2008-10-08 19:34 ` Dâniel Fraga
2008-10-08 19:56 ` Thomas Gleixner
2008-10-08 20:44 ` Ilpo Järvinen
2008-10-10 4:20 ` Dâniel Fraga
2008-10-10 8:10 ` Thomas Gleixner
2008-10-11 8:27 ` Ilpo Järvinen
2008-10-11 13:38 ` Dâniel Fraga
2008-10-13 4:08 ` Dâniel Fraga
2008-10-13 13:35 ` Ilpo Järvinen
2008-10-13 18:32 ` Dâniel Fraga
2008-10-13 18:48 ` Nicolas Cannasse
2008-10-17 23:51 ` Dâniel Fraga [this message]
2008-10-20 21:48 ` Ilpo Järvinen
2008-10-20 21:49 ` Ilpo Järvinen
2008-10-22 2:12 ` Dâniel Fraga
2008-10-30 10:43 ` Ilpo Järvinen
2008-10-30 18:16 ` Dâniel Fraga
2008-11-02 5:56 ` [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround (fwd) [SOLVED] Dâniel Fraga
2008-11-03 15:37 ` Ilpo Järvinen
2008-11-03 17:03 ` Dâniel Fraga
2008-10-02 20:56 ` [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround (fwd) Dâniel Fraga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48f9251b.1626360a.6574.61ec@mx.google.com \
--to=fragabr@gmail.com \
--cc=davem@davemloft.net \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=netdev@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).