A few days ago I had a very big problem with tc. On the machine tc is used in many ways: - from crontab to load night-time and day-time bandwidth (at 1am and 8am) - from crontab to get statistics for qdiscs on WAN interfaces (every minute) - from perl/php database for changing user bandwidth (sometimes) What happened: At 1am the night-time bandwidth should be loaded. tc hanged up, and also every tc (for qdisc stats) loaded every minute from cron was waiting(?) for the first one to finish its job. So the next day I had several hundreds tcs running and I was unable to kill any of them. (loadavg 800 looks pretty bad). reboot -f was the only solution (some other deamons stopped working and everything was really slow). The same thing happened about year ago on some other server. After it I added some changes in qdisc stats script to check if there is any other tc running and in that case don't check qdisc stats and therefore don't run any more tc. The similiraity between those two servers is that they have 2 processors. It never happened to me on any other machine with 1 processor. Current setup on which the problem appeared a few days ago is Linux 2.4.31, iproute2-ss051107, iptables v1.3.2, Debian (probably testing, I'm not maintaining the system). Setup which caused probles ~year ago is Linux 2.4.28, iproute2-ss041019, iptables v1.2.11, Slackware (mostly "current"). Kernels are heavy patched with p-o-m, imq and grsec. Did anyone had similar problems? And what is the difference between sources (.tar.gz): iproute2-date_only iproute2-2.6.X-date iproute2-ssdate ? In current setups I'm using iproute2-2.6.X-date.tar.gz, which results in: [root@XXX src]# ls | grep iproute iproute2-2.6.14-051107 [root@XXX src]# ip -V ip utility, iproute2-ss051107 and the log says: Table to handle kernel paging request at virtual address ffffffe4 (http://tuxpowered.net/tc_lockup/log.txt) Unfortunatly I don't have System.map for this kernel anymore :( -- | pozdrawiam / greetings | powered by Trustix, Gentoo and FreeBSD | | Kajetan Staszkiewicz | JID: vegeta@xxxxxxxxx | | Vegeta | IMQ devnames: http://tuxpowered.net | `------------------------^----------------------------------------' _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
