Opened 12 years ago

Closed 11 years ago

Last modified 9 years ago

#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:
Has a Patch: no 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)

serial.txt (44.3 KB) - added by scottmc 12 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 12 years ago by axeld

Component: - Network & Internet- Network & Internet/TCP
Owner: changed from axeld to hugosantos
Priority: normalcritical

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.

comment:2 Changed 12 years ago by scottmc

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 Changed 12 years ago by axeld

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!

Changed 12 years ago by scottmc

Attachment: serial.txt added

comment:4 Changed 12 years ago by scottmc

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?)

comment:5 Changed 12 years ago by 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.

comment:6 in reply to:  5 Changed 12 years ago by scottmc

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 Changed 11 years ago by stippi

Resolution: fixed
Status: newclosed

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 Changed 9 years ago by mmadia

Platform: x64x86-64
Note: See TracTickets for help on using tickets.