SliTaz Forum
You are not logged in.
it's just a guess - and it is really just a guess, but all the strange errors on older computers especially non intel ones, like amd geode, via... they have something together - evrything works fine with 3.0 and cooking march iso, but not with cooking may iso - so it happened just in the period between march and june iso and not between 3.0 and cooking- errors are something like
illegal instruction
probe of 0000:00:0e.0 failed with error -11
Illegal instruction at address 0xb763f32a
then michaelbishofs nv errors
I think it would be a pitty, if all these older computers will not work proper with slitaz 4.0 - they are working in Crunchbang, CTKArch, Lubuntu - but you cannot work. The only OS which is looking good and still quick is SliTaz
Offline
Do you have a whatever unprecise idea of the ,,culprit"? What might it be?
And: how to handle this problem in the near future, before 4.0 comes up? Use only the march iso - what consequences would that have?
Offline
you cannot use march cooking, because there is no toolchain etc, etc ....
but you can use gokhlayehs slizaz-libre-cooking version - see on the end of this thread
http://forum.slitaz.org/topic/slitaz-wireless-some-tips-if-you-have-troubles - yeh- I am writing now from the Alix 1c with geode cpu.
gokhlayehs version has evrything you need, but its very specific with with hardware - libre of course - and you have to compile quite a lot of drivers yoursef. I have noticed that before, that ath5k is working without any problems on his iso - but I tested only the base version without X
I already told in this thread, what could be the reason http://forum.slitaz.org/topic/troubles-with-geode-video-driver, but I do not think this is the reason, because goklayeh tried to bring back all his patches to slitaz cooking - I have no more odea, but I think there are others hwo have to think about it
Offline
this "bug???" effects following cpus: Via C3, Via Eden, Via Nehemia, AMD Geode LX, Transmeta Crusoe
it could ?????? be an issue with "long NOPs" or just the change in glibc
http://hg.slitaz.org/wok/rev/0fc448aca6fe
or just something else - its quite a common issue and I found these threads:
https://bbs.archlinux.org/viewtopic.php?pid=775414
http://news.techeye.net/software/patch-turns-transmeta-crusoe-into-a-full-i686
https://bugzilla.redhat.com/show_bug.cgi?id=579838
http://en.gentoo-wiki.com/wiki/Safe_Cflags/AMD
Offline
Have you checked to see if any caps failed visibly?
Those older PCs had a problem with capacitors going bad, cheap caps lucky to get 3 years before bulging and oozing electrolyte.
Offline
Hey,
I don't think this commit on glibc is the cause; libre uses same flags except fomit-frame-pointer, that I don't except this to be the source of our problem. If it works well in SliTaz libre, you could install it and then progressively install packages from SliTaz cooking and reboot until you hit the bug. I would start with glibc to make sure it's not from it, then linux kernel & modules - who know what theses blobs can bring - then maybe go by 5 or 10 packages at the same time.
Can you confirm that this bug still appears using last SliTaz RC, and doesn't using SliTaz libre?
yes - I tryed with RC2
Offline
ok it is localized - it is glibc-base
as a result of yesterdays IRC chat and todays tests its clear:
SliTaz-libre works - changing the kernel to RC2 - reboot works
--------------------------------------------------------------------------------------
SliTaz-libre installing glibc-base from RC2: X crashes with the same error as in RC2
[ 1027.346]
Backtrace:
[ 1027.347] 0: Xorg (xorg_backtrace+0x30) [0x80e4590]
[ 1027.347] 1: Xorg (AccessXComputeCurveFactor+0x5d) [0x813686d]
[ 1027.347] 2: Xorg (AccessXComputeCurveFactor+0xeb098) [0x82218a8]
[ 1027.347] Illegal instruction at address 0xb75a832a
[ 1027.348]
Fatal server error:
[ 1027.348] Caught signal 4 (Illegal instruction). Server aborting
[ 1027.348]
[ 1027.348]
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
-------------------------------------------------------------------------
SliTaz-RC2 installing glibc-base from SliTaz-libre X works, but I have no mouse and keyboard
there are no errors in Xorg.0.log - only the end lines are strange:
the first difference is I have us keyboard identified and the there are those lines, where there is normally nothing
[ 1284.091] (II) Power Button: Close
[ 1284.091] (II) UnloadModule: "evdev"
[ 1284.091] (II) Power Button: Close
[ 1284.092] (II) UnloadModule: "evdev"
[ 1284.092] (II) Sleep Button: Close
[ 1284.092] (II) UnloadModule: "evdev"
[ 1284.092] (II) AT Translated Set 2 keyboard: Close
[ 1284.092] (II) UnloadModule: "evdev"
[ 1284.092] (II) ImPS/2 Generic Wheel Mouse: Close
[ 1284.092] (II) UnloadModule: "evdev"
[ 1284.093] (II) Logitech Optical USB Mouse: Close
[ 1284.093] (II) UnloadModule: "evdev"
so its clear, that I have no mouse and keyboard
EDIT: and in addition, glibc-base is also installed when wireless-tools are installed and confirms here the error with iwconfig and iwlist
one more EDIT: glibc-base is also in the base.iso.....
Offline
and for Christophe
did you see the attachment of the redhat bug
https://bugzilla.redhat.com/attachment.cgi?id=425520&action=diff
Offline
nice catch, kultex!
Hope this will work with the new package.
yep - I just think it has to do with the i686, godane found yesterday - where is it I still cannot find
Offline
A rolling with pankso glibc fix have just been built:
http://mirror.slitaz.org/iso/rolling/slitaz-core-4in1.iso
Please test.
Offline
I will try, but I dont think, that it will be solved, because glibc is not included in 4in1.iso - only glibc-base
maybe it is also necessary to set the cflags in glibc-base?
Offline
The package glibc is empty, it's a splitted package. We put base libs used by ALL binaries on slitaz into glibc-base, glibc-dev have developement files and glibc-locale all the supported locale that are not in slitaz by default.
But about Godane found yesterday, -mtune=i686 is also present in libre glibc logs...
Offline
as I thought - nothing changed
Offline
so Christophe, for me remains only the discussion you had with Antoine about "-O2" and "-Os"
- next time I will save the IRC chat....
just as idea one more time - http://en.gentoo-wiki.com/wiki/Safe_Cflags
Offline
sorry I have no idea, what this means - is it possible to try this on a local machine... - like godanes tank iso?
Offline
It means rebuilding all packages = ~72H of compile on Tank and one night to sync mirror... Yes you can rebuild packages from tank-dvd but will take some time :-)
Rebuild all slitaz with -O2 means quiet a few more Mb on core, since -Os generate smaller binaries. Before to take the decision to rebuild everything, I'm compiling Xorg with -O2 on my machine, will do an iso and let you test it.
xorg with -Os = 1 Mb compressed
xorg with -O2 = 1,2 Mb compressed
Offline
So here is an ISO with Glibc and Xorg build with -02. I did a gtkonly flavor since it's smaller and faster to download and works like core but without any installed GTK applications.
http://people.slitaz.org/~pankso/iso/slitaz-xorg-O2.iso
Offline
sorry - same error...
and just a thought.... would it be a possibility, when Slitaz goes really i686 and the libre branch keeps compatibility with the rest? But there must be a isos with working repository....
Gokhlayeh how far are you? - the problem in libre is wireless, but compat-wireless compiles fine..... and I think, those people, who work with this ancient boxes are able to deal with.
And I can build two different SliTaz-Ola versions
Offline
I dont know why you say "when Slitaz goes really i686"... it's hours an hours I try to fix your bug, did many iso... And as we said many time libre use same ARCH and value to compile = i486. The -mtune=i686 optimisation is also in libre. SliTaz will not go i686 because we want to work on old hardware and be generic.
I also booted SliTaz on an old K6 today and no problem so it's not with all old machines.
Anyway, I did a last iso with Xorg and only the fbdev driver since vesa and geode crash. Also one more test you could do is boot a core with the option screen=text to see if it boot until the end. I realy would like to fix that Tom!
http://people.slitaz.org/~pankso/iso/slitaz-xorg-fbdev.iso
Offline
Hi Christophe,
sorry it did not change anything
let me first answer, why I wrote this - because I feel responsible for your time. I mean this bug was eating a lot of my time, and I do not want, that it eats a lot of your time. Sometime its necessary to step back and think different.
I have the problem, that I am very back with my work - I have to cut my radio-play, I have to prepare some tourneys and I will not be home from Friday morning for 2 weeks. So I cannot test anything.
And xorg is not the problem - because it would not work, when I just change glibc-base. And its also proved by the fact, that I get exactly this error in SliTaz-Libre, when I just install glibc-base from RC2. So there is no problem in xorg.
All I was reading about this error is described, that it creates these "Illegal instruction" errors. And these errors makes different programs to crash. And all I was reading points somehow to libc and the problem seemed to start with the update from glibc to glibc 2.12.2.
This would also explain, why we have this problem since cooking from Mai, because in march cooking glibc-base is still 2.11.2.
So I dont know, how to continue - perhaps one thing would be to add NOPL Patch to the kernel
http://marc.info/?l=linux-kernel&m=126748102722641&w=2
the other possibility seem to be rebuild evrything with -O2, because this seem to be the secret of SliTAz-Libre
Offline
Obviously you haven't been paying attention... That version pankso gave you that you CONFIRMED didn't work used -O2 compiling with Xorg and Glibc - pretty much the base that everything needs to work. Compiling with -O2 isn't a magic cheat code that makes everything magically work and I'm pretty sure it's not the secret to SliTaz Libre. Obsessively trying to force pankso to compile everything with -02 JUST so he can prove to you it doesn't work is just waste of his time. It's also delaying the release of SliTaz 4 and not allowing us to solve your problem because you refuse to consider other causes. Just accept that you have the wrong end of the stick and move on.
I think the reason Libre works is because it uses a completely Libre kernel rather than Linux kernel itself. It lacks certain code that is present in the main branch of the kernel and that's why it works. As simple as that. All we need to do is figure out what was removed from the Libre Kernel to make it work.
Offline
[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.59 MiB (Peak: 1.77 MiB) ]