#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: | ||
| 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 by , 14 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 14 years ago
| Cc: | added |
|---|
comment:3 by , 14 years ago
comment:4 by , 14 years ago
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 by , 14 years ago
I will investigate this deeper during this weekend then and will let you know if I find anything. Thanks for looking into this.
follow-up: 8 comment:7 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
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!
follow-up: 9 comment:8 by , 14 years ago
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 by , 14 years ago
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.
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).