2008-02-12 21:54:02 CET
25 years
no, I'm not 25 years old (actually,
by coincidence, I'm 0x25 years :)), but these days it's 25 years
that I (was) moved from Upper Austria to the Tyrol.
my summary of 25 years of development aid? well, I guess I got used to this country; although I still dislike those walls-with-names that are put here between the traces of civilization & the horizon ...
other calculation: I've spent more or less exactly two thirds of my life so far here.
my summary of 25 years of development aid? well, I guess I got used to this country; although I still dislike those walls-with-names that are put here between the traces of civilization & the horizon ...
other calculation: I've spent more or less exactly two thirds of my life so far here.
2008-02-11 23:36:20 CET
fun with 2.6.24, part II
after my laptop I
tried to get 2.6.24 running on my desktop machine; several attempts
(Debian kernels, self-compiled ones with different options) all led
to the same results: a machine that feels rather unresponsive &
where music has sporadic dropouts.
some searching on the intarweb showed that the new CFS scheduler (cf. Documentation/sched-design-CFS.txt) (at least the enabled-by-default CONFIG_FAIR_USER_SCHED flavour) might have latency problems, in itself or in combination with the ondemand CPU frequency scaling governor or with nice'd processes; after turning off all CONFIG_FAIR_* options in .config, recompiling & rebooting the machine seems to behave normally.
maybe I'm missing some great new features but actually I prefer a working desktop computer :)
update 1: approximately half an hour after the original blog entry I had my first "ion sorbet", i.e. a half-frozen ion3 (the applications are still running, I can switch to a tty but I cannot change/close/whatever ion3's frames). at the moment I have no idea what's going (wr)on(g) here ...
update 2: two more "ion sorbets" today yet; let's see if a new kernel (CONFIG_FAIR_USER_SCHED seems to be fixed in 2.6.24.1) & a new ion3 version help.
update 3: still the same problems (& inbetween some glitches with switching from X to a tty and back; I hope I solved them with some kernel config options); ATM I suspect ion3 to be the culprit; when it hangs it eats almost all the CPU, & strace'ing the pid gives only SIGALRM messages.
update 4: maybe I fixed the problem; by changing from ion3's deprecated statusbar_external.lua to the newer statusd_exec.lua (I just wanted to get rid of the error when starting ion3 ...).
update 5: & after compiling a kernel without PREEMPT ion3-statusd doesn't get stuck at using all my cpu every once in a while. or after removing some duplicated statusd_*.lua scripts. who knows.
update 6: nope, ion3-statusd is still hogging the cpu. argl.
update 7: I guess it's statusbar_external.lua's fault, as it happens on my other machine too.
some searching on the intarweb showed that the new CFS scheduler (cf. Documentation/sched-design-CFS.txt) (at least the enabled-by-default CONFIG_FAIR_USER_SCHED flavour) might have latency problems, in itself or in combination with the ondemand CPU frequency scaling governor or with nice'd processes; after turning off all CONFIG_FAIR_* options in .config, recompiling & rebooting the machine seems to behave normally.
maybe I'm missing some great new features but actually I prefer a working desktop computer :)
update 1: approximately half an hour after the original blog entry I had my first "ion sorbet", i.e. a half-frozen ion3 (the applications are still running, I can switch to a tty but I cannot change/close/whatever ion3's frames). at the moment I have no idea what's going (wr)on(g) here ...
update 2: two more "ion sorbets" today yet; let's see if a new kernel (CONFIG_FAIR_USER_SCHED seems to be fixed in 2.6.24.1) & a new ion3 version help.
update 3: still the same problems (& inbetween some glitches with switching from X to a tty and back; I hope I solved them with some kernel config options); ATM I suspect ion3 to be the culprit; when it hangs it eats almost all the CPU, & strace'ing the pid gives only SIGALRM messages.
update 4: maybe I fixed the problem; by changing from ion3's deprecated statusbar_external.lua to the newer statusd_exec.lua (I just wanted to get rid of the error when starting ion3 ...).
update 5: & after compiling a kernel without PREEMPT ion3-statusd doesn't get stuck at using all my cpu every once in a while. or after removing some duplicated statusd_*.lua scripts. who knows.
update 6: nope, ion3-statusd is still hogging the cpu. argl.
update 7: I guess it's statusbar_external.lua's fault, as it happens on my other machine too.
2008-02-09 17:31:49 CET
2.6.24 (finally)
no big step for humankind but I'm
quite happy that linux 2.6.24 is finally running on my laptop
(thinkpad R60e). the culprit that caused the freezes during earlier
attempts was cpudyn; after deactivating it I had no more
problems so far.
what's not working is ath5k which seems to dislike my wifi card; but the recent madwifi packages do what they are supposed to do.
JFTR:
what's not working is ath5k which seems to dislike my wifi card; but the recent madwifi packages do what they are supposed to do.
JFTR:
- I grabbed the latest kernel snapshot from the Debian kernel team's repo.
- after reading
#463353I downloaded kel's source packages for madwifi-*, built them, installed them, & built the modules as usual with m-a.
