SliTaz Forum
You are not logged in.
T@rixar_za I do not want to force anybody to to anything. I would like to find a solution, that eats as less time as possible.
Offline
and Trixar its not the kernel, because I described, that I could replace the libre-kernel with the kernel form RC2 and it still worked without any problems
Offline
Boys and girls!
Whatever your final decision will be: a Distro without an Xserver, which immediately greets the user after booting is something ridiculous.
Now, today, it is like this:
I boot from a fresh cooking, come into the text mode. Startx fails, lsmod shows that nouveau is up. So ,,tazx" => some minutes, I opt for ,,nv", some seconds. Then
#/etc/init.d/slim start
startx
, nice, looks good - but for me. No way to recommend such a thing to any non-linuxer.
Ach, I forgot: this functions only with Internet-access. With a CD-boot and no connection yet and no idea how to get it running no help.
Ok, for cooking this may work for some time. But for a real thing it is bizarre. With all respect for matching bleeding edge technology - a functioning Xscreen must be there.
Similar with networking - this functions easy out of the box (except with unusual very old hardware) or we are members of a minoritary sect.
Offline
Eh, it works fine on my old PIII.
Also, am I missing something here? You replaced the kernel with the libre-kernel and it works. Yet the kernel is not the problem? oO
Offline
and what is a PIII? its i686 and I said it effects only non i686 CPUs - sorry please read carfully.
and what are you missing? Why should I replace RC2 kernel with libre kernel , when I get the error, when I just change glibc-base in libre and on the other hand dont get the error any more, when I change glibc-base in RC2
Offline
Hi,
I might have a little information on this issue.
I have been trying to get Slitaz cooking to boot from CF card on several PC104 based computers, I would like to use the same image and have been trying to use Xorg with fbdev and Xfbdev.
When I try it on the Geode LX 800 cpu, i get the Invalid Instruction error.
I booted the newest rolling 4in1 iso into vmware, installed it to a CF card, and now it gets the kernel panic error when booted on the Geode.
After a lot of searching I'm now convinced the error lies in the gcc assembler gas.
http://fixunix.com/kernel/544418-binutils-bug-not-using-nopl-i686-needs-persuasive-arguments.html
https://bugzilla.redhat.com/show_bug.cgi?id=579838
And the fix:
http://sourceware.org/bugzilla/show_bug.cgi?id=6957
Is this fix included in the current gas used to build Slitaz?
I'm not so convinced anymore, just confused. I tried to disassemble the Xorg (version 1.9.5) file to find the illegal instruction.
I have never done anything like this before so please tell me if I'm totally off track here.
The error from my Xorg.0.log:
[c]
86.549] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
[ 86.549] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 86.792]
Backtrace:
[ 86.793] 0: Xorg (xorg_backtrace+0x30) [0x80c7004]
[ 86.794] 1: Xorg (AccessXComputeCurveFactor+0x51) [0x810f50e]
[ 86.794] Illegal instruction at address 0xb770132a
[ 86.794]
Fatal server error:
[ 86.794] Caught signal 4 (Illegal instruction). Server aborting
[ 86.794]
[/c]
From xkbAccessX.c:
[c]
void
AccessXComputeCurveFactor(XkbSrvInfoPtr xkbi,XkbControlsPtr ctrls)
{
xkbi->mouseKeysCurve= 1.0+(((double)ctrls->mk_curve)*0.001);
xkbi->mouseKeysCurveFactor= ( ((double)ctrls->mk_max_speed)/
pow((double)ctrls->mk_time_to_max,xkbi->mouseKeysCurve));
return;
}
[/c]
The disassembly:
[c]
objdump -drg Xorg |grep -n30 810f50e
...
229229-0810f4bd <AccessXComputeCurveFactor>:
229230- 810f4bd: 56 push %esi
229231- 810f4be: 53 push %ebx
229232- 810f4bf: 83 ec 24 sub $0x24,%esp
229233- 810f4c2: e8 00 00 00 00 call 810f4c7 <AccessXComputeCurveFactor+0xa>
229234- 810f4c7: 5b pop %ebx
229235- 810f4c8: 81 c3 c5 fd 07 00 add $0x7fdc5,%ebx
229236- 810f4ce: 8b 74 24 30 mov 0x30(%esp),%esi
229237- 810f4d2: 8b 44 24 34 mov 0x34(%esp),%eax
229238- 810f4d6: dd 83 0c 72 fe ff fldl -0x18df4(%ebx)
229239- 810f4dc: de 48 20 fimul 0x20(%eax)
229240- 810f4df: d9 e8 fld1
229241- 810f4e1: de c1 faddp %st,%st(1)
229242- 810f4e3: dd 56 3c fstl 0x3c(%esi)
229243- 810f4e6: 0f b7 50 1e movzwl 0x1e(%eax),%edx
229244- 810f4ea: 89 54 24 1c mov %edx,0x1c(%esp)
229245- 810f4ee: db 44 24 1c fildl 0x1c(%esp)
229246- 810f4f2: dd 5c 24 10 fstpl 0x10(%esp)
229247- 810f4f6: dd 5c 24 08 fstpl 0x8(%esp)
229248- 810f4fa: 0f b7 40 1c movzwl 0x1c(%eax),%eax
229249- 810f4fe: 89 44 24 1c mov %eax,0x1c(%esp)
229250- 810f502: db 44 24 1c fildl 0x1c(%esp)
229251- 810f506: dd 1c 24 fstpl (%esp)
229252- 810f509: e8 ba 24 f5 ff call 80619c8 <pow@plt>
229253: 810f50e: dc 7c 24 10 fdivrl 0x10(%esp) <---- Error should be here
229254- 810f512: dd 5e 44 fstpl 0x44(%esi)
229255- 810f515: 83 c4 24 add $0x24,%esp
229256- 810f518: 5b pop %ebx
229257- 810f519: 5e pop %esi
229258- 810f51a: c3 ret
...
[/c]
The Geode LX databook:
http://wiki.laptop.org/images/a/a1/Lx_databook.pdf
If fdivrl is the same as one of the fdivr mentioned in the geode lx databook, then I can't see why it signals the Illegal instruction.
Could anyone with more knowledge than me please comment on this?
You can try the other isos pankso made to localize the bug and you will see, that it catches the error on a differnt plosition - so it has nothing to do with Xorg
its only glibc - I think.....
here its quite good dokumented...
https://bbs.archlinux.de/viewtopic.php?id=16739
Offline
Hi kultex,
I read you link and I am aware of the missing instructions in the "alternative" CPU's. I have an old Mini-ITX with a VIA C3 Ezra running now for 10+ years as a small home server. Originally bought to be used as a media center, but the missing CMOV and MMX instructions cut multimedia performance greatly.
Right now I have two embedded PC104 systems, identical except for the cpu modules: A VIA Nehemia and the AMD Geode LX 800.
The VIA systems boots my slitaz cooking with both the Xorg Savage driver and the fbdev driver.
The Geode fails with both the fbdev as well as the Xorg Geode driver.
Here are the important parts from /proc/cpuinfo on all three systems:
[c]
vendor_id : CentaurHauls
cpu family : 6
model : 8
model name : VIA C3 Ezra
flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow up
vendor_id : CentaurHauls
cpu family : 6
model : 9
model name : VIA Nehemiah
flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en
vendor_id : AuthenticAMD
cpu family : 5
model : 10
model name : Geode(TM) Integrated Processor by AMD PCS
flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow up
[/c]
The C3 Ezra wrongly claimed to be of family 6, but it did not have the cmov instruction, really causing me a headache 10 years ago.
The Redhat bugzilla link I posted above have an indepth discussion on the problem (nopl) being in glibc, but following it through it ends up being a problem in gcc gas.
That is why I started with my question about the patch for gas.
Running [c]objdump -dr /lib/libc-2.13.so |grep nopl[/c] on my slitaz cooking returns nothing.
Which is correct.
The same command on my Ubuntu Maverick desktop gives a single nopl instruction, which actually is wrong. Ubuntu dropped support for i586 and less with the Maverick release, but the nopl instruction was NOT part of the i686 instruction set, all Intel cpu's supported it though.
I will try to put the slitaz-xorg-fbdev.iso on my CF card and test it.
I am still confused why/how the error in Xorg can say a specific address has the invalid instruction, and I cant see it with the objdump approach.
Is it a stupid way trying to find the illegal instruction?
Some of the discussion I link to above show concerns about the default gas instructions used if no no arch info is given. In that case it could even be an sse instruction.
You seem to be more experienced than me, but here I have the Xorg.0.log from a rolling iso - here it catches the error one line later...
[ 164.512] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 164.516] (II) GEODE(0): Setting screen physical size to 423 x 317
[ 164.782]
Backtrace:
[ 164.783] 0: Xorg (xorg_backtrace+0x30) [0x80c700c]
[ 164.783] 1: Xorg (AccessXComputeCurveFactor+0x51) [0x810f516]
[ 164.783] Illegal instruction at address 0xb756732a
[ 164.783]
Fatal server error:
[ 164.783] Caught signal 4 (Illegal instruction). Server aborting
[ 164.783]
the bad thing - slitaz-libre is no more available - but it was the clearest hint:
after booting the SliTaz-libre.iso I changed glibc-base from libre to RC2 and I catched the same error, which was not here, when I just booted the libre iso
Offline
I get a kernel panic with the slitaz-xorg-fbdev.iso, same as with the rolling 4in1.
did you enter the correct vga mode in the boot line? like mine is vga=334 - if you dont know your vga number you just can enter vga=966, which does not exist - then you get a message, that it does not exist and you have to press enter to select the correct one.
and you also have to enter screen=text in the boot line and then startx
with this options I have no problem to boot slitaz-xorg-fbdev.iso
Offline
I should read the error more carefully.
Fixed the root parameter on the boot line and added vga=785, then it booted fine.
Tried both the rolling and fbdev iso's, and both still give the Illegal Instruction when starting X.
Allthough it is different addresses, the function offset is the same, so are you sure the error is not in the AccessXComputeCurveFactor function?
A change somewhere else in the Xorg source or a different optimization at compile time would give different addresses for the same error.
Could someone show me to a guide or howto on building (cooking) the Xorg on my own?
first I uploaded the libre iso to my server - so you just can try this:
www.kult-ex.org/download/slitaz-libre-develop-core-4in1.iso
boot to promt, then start X - you will see, that it works, then you download http://mirror.slitaz.org/packages/cooking/glibc-base-2.13.tazpkg
install it with tazpkg install glibc-base-2.13.tazpkg --force then log out and you will see, that you have exactly the same error
Offline
Thank you. I tried it and got the same errors.
Xorg libre was build: 08 December 2011
Xorg cooking was build: 18 March 2012
Libraries from glibc-base used by Xorg, that can generate the error:
libdl, libc, libm, librt, libpthread
I searched all libraries from cooking used by Xorg for the nopl instruction. None found.
An objdump on the AccessXComputeCurveFactor function from cooking differs from libre.
There is no change in the source code for the AccessXComputeCurveFactor function in the Xorg 1.9 branch, so the source must have been built with other compiler settings for optimization, architecture and/or instruction set.
I have no idea of what to do next, but a few questions I would like answered:
I think I read somewhere about Slitaz compiler settings was changed from from i386 to i486 is that correct? If so, when?
Is it possible to let the kernel log the opcode for the illegal instruction?
Mercurial log for Slitaz build tools configuration file:
Cookutils=> http://hg.slitaz.org/cookutils/log/14458aa844e2/cook.conf
Tazwok=> http://hg.slitaz.org/tazwok/log/50581bf79fd4/examples/tazwok.conf
Offline
Hi,
@steffen You can browse all cook logs on http://cook.slitaz.org/ and Kernel config is in the wok as well as /proc/config.gz
@kultext "with this options I have no problem to boot slitaz-xorg-fbdev.iso" I guess I'm missing something... you are saying the slitaz-xorg-fbdev.iso I build for you is working ?
Offline
@pankso
this working is only related to steffens kernel panik with the slitaz-xorg-fbdev.iso, because he could not boot to promt - no the error is still the same.....
Offline
@pankso
Thank you for the link.
Looking at the slitaz-toolchain -> GCC compiler information, I notice the [c]--with-tune=i486 --build=i486-slitaz-linux --host=i486-slitaz-linux[/c], I found the optimization -Os in cook.conf.
According to the mercurial mojo linked to, the switch to i486 was done on 20 May 2011, so it must be the same on the libre build. Was the optimization changed on that build?
The Xorg source is the same, at least for the AccessXComputeCurveFactor function, but the assembler differs, can it be anything else than optimization and arch/tune settings causing that?
slitaz-xorg-fbdev.iso: I got the kernel panic because I overlooked a wrong root= parameter in the kernel line. It boots correctly, but with the Illegal Instruction error in Xorg.
libre was build with -O2
Offline
I tried to take the cooking image I have working on the VIA Nehemia and upgraded to newest from archive. As far as I understand it should be the same packages that is on the 4in1 iso, right?
Then I tried to cook the glibc-base on my own, but it seems not to be able to get the sources.
Can anyone confirm this?
I changed my /etc/slitaz/cook.conf to -O2 and took the [c]tazpkg list[/c] from my running image and fed it to the cooker.
If it succeeds I will try to force install the single packages into my running image, hopefully making it run on the Geode too.
Toolchain documentation: http://doc.slitaz.org/en:cookbook:toolchain
Start by cooking the slitaz-toolchain :
#cook slitaz-toolchain
slitaz-toolchain receipt : http://cook.slitaz.org/cooker.cgi?receipt=slitaz-toolchain
Cook log for slitaz-toolchain: http://cook.slitaz.org/cooker.cgi?pkg=slitaz-toolchain
I would do this with : tazdev gen-chroot
Once completed you should be able to cook the other packages.
Offline
Please provide your experience once you have done, steffen. I don't believe that -O2 will be the fix all that some believe it will be.
Offline
@trixar
I am not sure, if -02 will fix the problem since pankso built an ISO with Glibc and Xorg with -02
I think, it just have to be done to exclude it - the problem is, I am not so familiar with the build process and have no time at the moment - I cannot do it befor May
Offline
Sorry for the long delay, I was held up on another project.
I started from scratch with a new vmware client installation of the new Slitaz 4 release.
Installed also Slitaz 4 on my CF card.
Read the cookutils documentation again, so fast I forget stuff these days ;-)
Installed the developer tools, setup a chroot environment as mojo described above.
Installed developer tools in the chroot.
Changed the cook.conf -Os to -O2 in the chroot environment.
[c]cook glibc-base[/c]
Moved new glibc-base-2.13.tazpkg to CF card.
Booted on Geode, started X, got the illegal instruction.
[c]tazpkg install glibc-base-2.13.tazpkg --forced[/c]
Rebooted, started X and viola, no illegal instruction.
I get an error message about some clear screen command not working in fbdev, but graphic works.
Executed my program, made in Ultimate++ for the embedded client and it showed as it should.
@kultex
Could you please try this -O2 build of glibc-base package and let me know if it helps you also:
http://www.kernelguy.dk/slitaz/glibc-base-2.13.tazpkg
[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.59 MiB (Peak: 1.77 MiB) ]