Inspired by a thread http://forum.transmissionbt.com/viewtop ... f=2&t=9443 "transmission-daemon crashing on ARM linux" and my system crashes, tried to disable EPOLL method in libevent (I've got 1.4.11-stable-1). Even though the system behaviour had definitely become different, had still got the same crash (kernel panic), now with tons of messages like that filled up my system logs:
Feb 4 07:45:07 kovalev-home kernel: [20955.786019] recvmsg bug: copied 94BE3DA1 seq 94BE4348
Feb 4 07:45:07 kovalev-home kernel: [20955.786059] recvmsg bug: copied 94BE3DA1 seq 94BE4348
Thus, not a bug in libevent EPOLL, even if it exists, but a problem with recvmsg is a possible cause of my crashes. My attempt to trace down an issue in Ubuntu community has given only one relevant discussion here:
https://bugs.launchpad.net/ubuntu/+sour ... bug/245990
where a similar error was related to Atheros AR5212 wireless card and its driver. Unfortunately, I've got an Atheros wifi too (AR5007eg)...
Tried to reduce a number of peers-per-torrent and download speed per torrent. Even though this had given some remedy, the same crash has finally occurred. This is because it happens even while downloading from only one peer but with a large number of download requests (ca. 20 and above). Thus, it would be nice to have an option in Transmission to put a limit to a number of download requests-per-peer ("Dn Reqs"), the same way as we've got them for download speed and for a number of peers connected.
Now, as my issue appears to be system-wide, I am desperately looking for any possible system-wide solution for it. By the way, what exactly the "Dn Reqs" means: a number of established tcp(udp) connections between me and a given peer? Or is it a feature of bittorrent protocol only? Please excuse my ignorance - I am not a torrent freak...
Running Transmission 1.83+ GTK (rc10048) on Ubuntu 9.10 (Linux kernel 2.6.31.18 and Gnome 2.28.1).
P.S. On global and peers-per-torrent limits in Transmission:
Now Transmission seems doesn't honour a global peers-per-torrent limit. Intuitively, "Global limit" means "Maximum allowed for all". Read: if an option "Honour global values (limits)" in a Torrent Inspector tag is set, neither related value for this given torrent should not exceed its global limits set via "Preferences". In a current version of Transmission, one can increase a peers-per-torrent value for a given torrent even above its global limit. Alternatively, when reducing a global cap on peers-per-torrent via "Preferences", the value for any given torrent remains intact and thus may exceed its new global limit. It means, current "global limit" to peers-per-torrent means actually a "default limit" assigned to a newly added torrent...
I would prefer to have more clear set of limits in Transmission. I mean, there should be a distinct difference between a global and a local limit, as well as between total and per-torrent value. All global limits, both to total and to per-torrent values, should be set via global "Preferences" - and that's it. A set of global per-torrent limits would also become a default set of limits for each newly added torrent. Then, only per-torrent limits to values of a given torrent should be accessible via Torrent Inspector. There should be the only option "Honour global limits" for all per-torrent values of a given torrent. Setting it via Torrent Inspector would then mean: "Use global per-torrent limit to each value of this torrent, unless explicitly specified". Of course there should be an option to cap any such a value of any loaded torrent explicitly via Torrent Inspector, even above its global limit. This is what we've got now for speed and seed ratio, but not for peers-per-torrent. And of course none of this explicitly set limit should not be allowed to exceed a total capacity for all currently active torrents, which is set as global limits to total values.
[SOLVED] Capping a number of download requests per peer?
Re: Capping a number of download requests per peer?
An addition to my first post in a thread:
In search for a solution to my crashes around Linux community have found several notices about kernel bug in recvmsg which has plagued kernel at least since release 2.1.x. This is not related to any specific hardware setup nor to any application and has never been completely fixed in any release including current 2.6.31. The only reason while Transmission triggers such a crashes is a nature of bittorrent protocol. To see a crash while downloading via http or ftp, I would have attempted to download a hundred of files simultaneously.
There is still some hope for improvements in kernel 2.6.32, which is under active development now. Just have to be patient, cap my download speed down to one-tenth of bandwidth and wait for Ubuntu 10.04 with a new kernel coming soon...
Running Transmission 1.83+ GTK (rc10092) on Ubuntu 9.10 (Linux kernel 2.6.31.18 and Gnome 2.28.1).
In search for a solution to my crashes around Linux community have found several notices about kernel bug in recvmsg which has plagued kernel at least since release 2.1.x. This is not related to any specific hardware setup nor to any application and has never been completely fixed in any release including current 2.6.31. The only reason while Transmission triggers such a crashes is a nature of bittorrent protocol. To see a crash while downloading via http or ftp, I would have attempted to download a hundred of files simultaneously.
There is still some hope for improvements in kernel 2.6.32, which is under active development now. Just have to be patient, cap my download speed down to one-tenth of bandwidth and wait for Ubuntu 10.04 with a new kernel coming soon...
Running Transmission 1.83+ GTK (rc10092) on Ubuntu 9.10 (Linux kernel 2.6.31.18 and Gnome 2.28.1).
SOLVED: system crash while downloading at high speed
Have being using Transmission (1.75 to 1.91) for over a year in Ubuntu 9.04 to 9.10 on my Toshiba Satellite L40 laptop connected to the Internet via built-in Atheros AR5007EG wireless card installed in mini-PCI. While using Transmission I discovered that downloading from large swarms at high speed resulted in regular system crash (kernel panic) within 30 min to 1 hour. Recently it turned out the issue is system-wide, i.e. any heavy network activity triggers system crash. My search through Linux support community made me think that a bug in Linux kernel which causes i/o stalls in some cases (seems has been fixed in kernel 2.6.32) could be responsible for it.
Recently however I have found a hardware problem in my laptop. The PCI chip (not the CPU!) lacks proper cooling due to limitations in laptop design, mechanical defect in its radiator and partial blocking of ventilation slits by dust. After fixing mechanical problems my system has become rock stable. Still I was able to trigger system crash by heavy i/o activity - while downloading at ~2.5 MBits/s over wireless and transferring lots of data (~10MByte/s) via IEEE1394 PCMCIA card simultaneously and for a prolonged time providing that a temperature of cooling air is above 24 deg C.
Problem solved.
Conclusion: before reporting a software problem, it should be wise to check all your hardware carefully...
Recently however I have found a hardware problem in my laptop. The PCI chip (not the CPU!) lacks proper cooling due to limitations in laptop design, mechanical defect in its radiator and partial blocking of ventilation slits by dust. After fixing mechanical problems my system has become rock stable. Still I was able to trigger system crash by heavy i/o activity - while downloading at ~2.5 MBits/s over wireless and transferring lots of data (~10MByte/s) via IEEE1394 PCMCIA card simultaneously and for a prolonged time providing that a temperature of cooling air is above 24 deg C.
Problem solved.
Conclusion: before reporting a software problem, it should be wise to check all your hardware carefully...