Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#5309 closed bug (fixed)

r35232 causes network stack to stall.

Reported by: bga Owned by: bonefish
Priority: high Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc: Jens.Arm@…
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

Steps to reproduce:

1 - Use wget (or anything else, really) and try to download a file that is bigger than 4 Mb. 2 - Whatch the file downloading until, at some point (around 4 Mb) the transfer stalls. 3 - After this, nothing network related works anymore.

Note that the 4 Mb "limit" applies globally in the sense that if I do several 1 Mb transfers, it will hang after the fourth one (more or less).

The only solution to this seem to be rebooting the OS.

As this seems to be related to the memory allocation changes, I am assigning it the kernel component instead of the network or driver ones.

Let me know if you need more info.

Change History (9)

comment:1 Changed 9 years ago by axeld

Owner: changed from axeld to bonefish
Status: newassigned

comment:2 Changed 9 years ago by jahaiku

Cc: Jens.Arm@… added

comment:3 Changed 9 years ago by bga

Just in case it may help, the network card is a Marvel Yukon Gigabit Ethernet card, the machine is SMP (quad core) and has 4 Gb of memory (only 3 Gb visible by Haiku due to the video cards taking the other 1 Gb of address space). It worked without problems a few revisions ago.

Also, I started downloading the file just after boot, so there was no memory pressure in the system in general (180 Mb used of 3 Gb).

comment:4 Changed 9 years ago by bonefish

No stalling here. Tested with hrev35235 gcc4 hybrid on real hardware and in qemu. Downloaded the gcc4 optional package (16.3 MB) a few times as well as several larger packages from BeBits via BeZillaBrowser.

The only thing I noticed is that the downloads went significantly faster in qemu under Linux (with only 128 MB virtual memory) than on real hardware. But I guess that is just driver related.

comment:5 Changed 9 years ago by bga

I will investigate this deeper during this weekend then and will let you know if I find anything. Thanks for looking into this.

comment:6 Changed 9 years ago by bonefish

hrev35242 might improve the situation.

comment:7 in reply to:  6 ; Changed 9 years ago by bga

Resolution: fixed
Status: assignedclosed

Replying to bonefish:

hrev35242 might improve the situation.

Nope. But the following CL from you actually did it. The only weird thing is that now i see a "saw-like" pattern in the transfer (the speed is going up and down every second). Not sure if this is an expected artifact of how ActivityMonitor measures transfer speed or if there is something fishy...

In any case, this bug is solved. Thanks!

comment:8 in reply to:  7 ; Changed 9 years ago by siarzhuk

Replying to bga:

The only weird thing is that now i see a "saw-like" pattern in the transfer (the speed is going up and down every second). Not sure if this is an expected artifact of how ActivityMonitor measures transfer speed or if there is something fishy...

Do you mean meander-like trace like one displayed on screenshot attached to #5019? But this behavior was observed month ago and looks like not related to last changes.

2 bonefish: By the way, the problem, described in #5019 is not observed on revision hrev35253. Can your latest changes affect on that? I'll check this situation on some more network cards and close the ticket if all goes OK.

comment:9 in reply to:  8 Changed 9 years ago by bonefish

Replying to siarzhuk:

Replying to bga: 2 bonefish: By the way, the problem, described in #5019 is not observed on revision hrev35253. Can your latest changes affect on that? I'll check this situation on some more network cards and close the ticket if all goes OK.

Yep, that's exactly what hrev35242 would fix. I think it is safe to close that ticket, but feel free to test some more.

Note: See TracTickets for help on using tickets.