* [LARTC] tc/htb still hangs system.
@ 2002-09-18 22:52 Tomasz Wrona
2002-09-19 0:35 ` Werner Almesberger
0 siblings, 1 reply; 2+ messages in thread
From: Tomasz Wrona @ 2002-09-18 22:52 UTC (permalink / raw)
To: lartc
Hello,
I would like ask for help in despair...
I am running complex htb setup to manage two leased lines [1+2MBit] for
500 users. Setup works from few months but in this time I have still
awfully problems with stable work. Nowadays there is no week when system
hangs two
or three times. I tried dozens of setups, patches, recompilations of
kernel, iproute and iptables, tricks and still almost without improvement.
I tried to find reason but without success. Bellow I mention some
observed facts. Maybe someboty could advise or solve problem...
When I started with HTB [2.0] [about 200 users on 1Mbit link; Previous it
worked on CBQ setup] there wasn't propably [AFAIK] problems with stable
work [many days between manual reboot]. From time to time I had some
sudden hangs, which become more often later. I changed kernel to 2.4.18
but the reason
what I found [or one of the reasons...] whas hardware related [damaged cpu
and/or mboard].
I changed completly all hardware and changed kernel to 2.4.18 patched
with htb v2. but problem didn't dissapear - frozen system during several
days. Most ofen hangs was after 1 or 2 days of stable work but some cases
it was 4 or even 7 days.
.
Then I tried 2.4.18 patched with htb v.3. but situation become hopeless. I
found that each changing of htb class parameters [tc class change...] lead
to freezing system. Sometimes one sometimes more changing params caused
crash. Htb 3 was useless for me and htb 2 was/is also unstable.
I also tried htb2 on completly other machine [but with the same Linux
distro - PLD], but system crashed almost immediately.
Now I am testing 2.4.20-pre7 [with included htb3], system didn't hang
immediatelly after changing htb class params but now it works from several
hours to one day.
Unfortunatelly I didn't have any error messages in logs and on console.
ERRATA: Today I have first time to see some
logs on console [kernel 2.4.20-pre7], there is something about Oops
"Process swapper (pid: 0, stackpage¿211000)" and a lot of digits.
I put screen on location: http://eter.tym.pl/bug2.gif
Diging in LARTC archive I found maybe something simmilar problem in post
of "Dimitris Zilaskos: [LARTC] tc reliably hangs my system "
[http://mailman.ds9a.nl/pipermail/lartc/2002q3/004316.html]
but there is not solution for me and despaired I dont know the reason
and what to do with it.
BTW. If this bug report [http://eter.tym.pl/bug2.gif file] is related
more to kernel than to tc/htb please tell me where to send it.
Regards
tw
--
----------------
ck.eter.tym.pl
"Never let shooling disturb Your education"
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [LARTC] tc/htb still hangs system.
2002-09-18 22:52 [LARTC] tc/htb still hangs system Tomasz Wrona
@ 2002-09-19 0:35 ` Werner Almesberger
0 siblings, 0 replies; 2+ messages in thread
From: Werner Almesberger @ 2002-09-19 0:35 UTC (permalink / raw)
To: lartc
Tomasz Wrona wrote:
> I tried to find reason but without success. Bellow I mention some
> observed facts. Maybe someboty could advise or solve problem...
In case you want to try systematic debugging of HTB, you may find
tcsim useful. tcsim can be run under Electric Fence and under
Valgrind (http://developer.kde.org/~sewardj/).
It won't help you find race conditions and such, but spotting
odd side-effects of parameter changes may be well within its
capabilities.
Of course, a decent set of regression tests should also be
useful for future HTB development ...
Concerning the Oops you got: you should run it through ksymoops
(see Documentation/oops-tracing.txt in your kernel source tree).
If you don't want to type in the whole Oops text, you can also
get the location of individual symbols with
gdb your/kernel/dir/vmlinux
(gdb) info line *0xd093caa4
etc.
The most useful data is in the EIP and the call trace.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-09-19 0:35 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-18 22:52 [LARTC] tc/htb still hangs system Tomasz Wrona
2002-09-19 0:35 ` Werner Almesberger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.