#1414 closed bug (fixed)
FTP upload stops around 78k
Reported by: | scottmc | Owned by: | hugosantos |
---|---|---|---|
Priority: | critical | Milestone: | R1 |
Component: | Network & Internet/TCP | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86-64 |
Description
Using vmware image (tried a few different daily images from august 10-19, 2007), network card shows as ipro1000, using command line ftp "get" works fine, but "put" stops, showing 0% done. I check the ftp site and it shows the first 78k or so of the file made it, file i tried to upload was 300k. Attepts to "kill" the ftp session do not work. Also tried FtpPositive and that does the same thing.
I'm running in Ubunbtu x64 using vmware player 2.0 if that makes any difference.
Attachments (1)
Change History (9)
comment:1 by , 17 years ago
Component: | - Network & Internet → - Network & Internet/TCP |
---|---|
Owner: | changed from | to
Priority: | normal → critical |
comment:2 by , 17 years ago
Ok, tried again with same results, this time capturing the stack trace as requested:
kdebug> sc 0x22c stack trace for thread 0x22c "ftp"
kernal stack: 0x935df000 to 0x935e3000
user stack: 0x7efe7000 to 0x7ffe7000
frame caller <image>:function + offset 00000000 -- read fault kdebug>
comment:3 by , 17 years ago
Ah, you're hitting a bug in the "sc" function (which is fixed in hrev22026). It looks like your thread is currently running - possibly, it is an endless loop. Can you retry with that release, or, leave out the ID if that thread is currently running on the current CPU (you can test with the "running" command)? Thanks!
by , 17 years ago
Attachment: | serial.txt added |
---|
comment:4 by , 17 years ago
i'm not running the hrev22018 image and it's acting slightly different. It's still only transferring 78k: http://www.bedrivers.com/screen2.png But as you can see in the screenshot it's showing that 100% went and then not printing anything..pressing ctril-c breaks it out of the ftp session. I'll attach the serial.txt output from vmware, look about 3/4th the way down for "sc 0x14d" that's where i entered KDL and ran the stack trace (line 777?)
follow-up: 6 comment:5 by , 17 years ago
I just tried a new version from the August 30, 2007 HD Images and was able to upload a file that was 156kb without any trouble. I will try uploading more files soon to see if this one is really fixed or not now.
comment:6 by , 17 years ago
Replying to scottmc:
I just tried a new version from the August 30, 2007 HD Images and was able to upload a file that was 156kb without any trouble. I will try uploading more files soon to see if this one is really fixed or not now.
I tried a version from September 19th, and was able to upload past 1meg now. But it seemed slow. I'm going to set up a local ftp server in ubuntu and try sending some larger files and see how it goes. It seems the 78k barrier isn't a problem anymore but there might be a speed issue here still.
comment:7 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Speed issue is tracked in #1958. I have no problem downloading or uploading much larger files, so I am closing this bug, since the original issue seems to be fixed.
comment:8 by , 15 years ago
Platform: | x64 → x86-64 |
---|
This seems to be a deadlock in the TCP implementation; there are kernel semaphores which you cannot interrupt. Can you provide a stack trace of the FTP thread? You can get this via "sc <thread-id>" in the kernel debugger. You could see the thread ID of the FTP thread using the "teams" command (in hex, so you'll have to add "0x" in front of the number before passing it to "sc").
Both commands have to be entered in the kernel debugger which can be entered via the F12 key.