Re: [Gumstix-users] Astlinux's buildroot x gumstix's one

[David K. <dk...@sh...>]

Alexandre Pereira Nunes wrote:
> [cut]
>=20
>> I reverted the 2.6.18 change in the svn repository (yay git svn
>> hookups!) and then copied the 2.6.17 config from astlinux. Asterisk
>> started right up. Perhaps this is a serious enough bug to consider
>> reverting the 2.6.18 stuff completely?
>>
>> David
>>
>> =20
>>
>=20
> I'm not in position to say, but everything that works on 2.6.18=20
> apparently also works on 2.6.17, so from where I see it, it's a=20
> possibility, although there seems to be two possible workarounds to thi=
s=20
> problem on 2.6.18:
>=20
>=20
> 1) Put this line (without the quotes): "cat=20
> /usr/lib/asterisk/modules/*.so >/dev/null" on line 61 of=20
> /etc/init.d/S60asterisk, so that it reads:
>     cat /usr/lib/asterisk/modules/*.so >/dev/null
>     start-stop-daemon --start --exec $DAEMON -- $ASTARGS
>=20
> iptables with dynamic modules (Craig recently accept a patch I sent to =

> build iptables with static modules only, so it doesn't apply if you do =
a=20
> fresh build) may also need such a trick.
>=20
> 2) To try booting with kernel parameter cachepolicy=3Dwritethrough. I=20
> didn't try this one. It'll have a serious impact on performance, plus=20
> people reported on the past that this could lead the system to bad=20
> behaviour, since that cache policy is less tested on pxa and there coul=
d=20
> be another kernel bugs triggered by it, although, by design, a=20
> writethrough cache is a simpler mechanism which shouldn't be subject to=
=20
> aliasing issues (which seems to be the cause of the problem we're=20
> discussing) or other smart-ass cache poisoning effects.

Or I could just use 2.6.17 :) Everything I need works and I don't have
to apply any strange hax. Thanks for the info tho.

>=20
> The above are exclusive, if you choose one you don't need the other. If=
=20
> neither works then that's sad but funny.
>=20
> Sorry for pointing that out after you have the trouble of downgrading=20
> and compiling the whole thing, but I just get to this point today.
>=20
> As for the official downgrade thing, 2.6.19 is more or less on the go=20
> (It's on release candidate 5) and the arm port maintainer is having a=20
> hard time understanding the memory management changes that went on=20
> 2.6.18 and their implications.  It's a real possibility that we only se=
e=20
> that bug fixed at 2.6.20. But it would also be a worthwhile experience =

> (is this valid English?) to try to compile 2.6.19-rcx and see if perhap=
s=20
> there isn't a fix already.

I do think however, that it'd be prudent to downgrade to 2.6.17 since it
"just works" as opposed to two "maybe" fixes for 2.6.18. I cannot see
any huge benefit over 2.6.17 that 2.6.18 has. Perhaps the wifi or the
bluetooth, as I don't have either of those, but the netCF hardware works
just fine.

I've gotta move forward with what I was doing with the gumstix, setting
asterisk up and moving on with it, so unfortuantely I can no longer test
with the hardware. I've found a solution that works, and I've got to
move forward. However, if I acquire a second gumstix and do have the
time to test on it, I most certainly will :)

>=20
> I have to agree with the maintainer guy that the mmu aspects of Linux=20
> became quite complicated, I always get lost when I try to understand=20
> even a bit of it. On the 2.0.x days I could cite parts of the code=20
> without looking at it (that's more like a figure of speech).

I was never that familiar with the linux kernel, you have my gratitude
for all the work you've done on this :)

--=20
David Kowis

ISO Team Lead - www.sourcemage.org
SourceMage GNU/Linux

Progress isn't made by early risers. It's made by lazy men trying to
find easier ways to do something.
  - Robert Heinlein